I think I track with what you are saying. I at least added the probe type to the notifier string so that we can discern between a dead box and a dead BGP peer. Now which BGP peer went down exactly is another story - but at least the sky isn't falling when we see a simple "device: down" message. I don't see yet how you can bring out the label of the member device/probe.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Graziano Sent: Thursday, April 09, 2009 11:51 AM To: InterMapper Discussion Subject: Re: [IM-Talk] InterMapper 5.1b5 (3 RFEs) The workaround in #2 may help you out a bit (with the notification behavior in the last beta if you set alerts on the member probes rather than the group & fiddle to make the names helpful you'll get meaningful messages), but answering the "Which Child triggered this alarm?" question is cleaner from an end-user perspective. Re: Groups & Notifiers (and speaking a bit to #1 below), I'm still puzzling out the notification semantics for probe groups since I didn't really get to play much until yesterday. It seems to be "Group then Member Probe" independently, so if a notifier is configured for both you get two messages (haven't installed the final release yet but this was the behavior I saw in the last beta). I'm not sure if that's a bug or not (should it be "Group || Member Probe", "Group && Member Probe", or is the independent double- notification behavior desirable in certain situations?). Also if the "or" behavior is right how do you handle a notifier on a member probe that's not also on the group? My gut says the "or" behavior is correct (with notifiers on the group implying every member probe) and it should always send the notifier as if it came from the group device (with an indication of which member triggered the alarm), but I'm not ready to say that with any level of conviction yet... I suspect this all ties back to how groups/member probes are implemented: Looks like the contents of a group are first-class devices as far as notifiers know, and all the prettying-up I can think of comes down to making the Notifier logic to do special things if the triggering probe is in a probe group which is potentially ugly from a coding standpoint... -MG On Apr 9, 2009, at 11:34 AM, Tony Mumm wrote: > After having now put more of this into production, I have to agree > that your > RFE #3 below is essential for probe groups to be usable. We didn't > run into > that scenario on our test devices as we didn't see many outages. > > Our NOC gets disproportionately concern when the relatively low > priority > member probes are triggered. In our case, the NOC thinks the > entire router > is down when its not - just a single BGP session. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Michael > Graziano > Sent: Tuesday, April 07, 2009 4:29 PM > To: InterMapper Discussion > Subject: [IM-Talk] InterMapper 5.1b5 (3 RFEs) > > Loving the new probe groups -- only a couple of minor issues popping > up with them and they're all just annoyances. (I'm a bit late to the > party so apologies if these are already known/logged) -- > > 1) > Adding a new probe to a probe group inherits the map's default > notifiers (which may not match the probe group's notifiers). > > This isn't an issue in my setup because my notification lists are dead > simple, but I think the sane behavior for more complex environments > would be to inherit the notifiers from the probe group rather than the > map. > Related: Updating notifiers on a probe group doesn't affect the > notifier values for contained probes, but a good case can be made for > that behavior being sensible. > > > 2) > You can't change the label of a probe contained in a probe group > (there's no "Format..." menu option for member probes in the group's > info window), and the automatic name is usually less than helpful (eg. > named with an IP address). Ungrouping, renaming & re-grouping seems > to be a workaround for now. > > > 3) > Notifiers can say which probe group you're a member of, but not which > of your members triggered the notifier. (This can sometimes be > inferred by the Condition field, but having an explicit item would be > helpful). > > Ideally I'd like to be able to have notifiers of the form "<Device > Name> (<Group Member>) - <Device Status>" (e.g. "ldap.ny (LDAPS) - > Alarm") which gets me all the info I need in one quick scan. > > > -MG > > > On Apr 1, 2009, at 9:52 AM, Janice Losgar wrote: > >> Folks: >> >> A new beta-test version of InterMapper 5.1b5 ("False Pony") is now >> available. We would be delighted to have you use it and send us >> comments and >> bug reports. It contains some minor enhancements and a few bug >> fixes. Please >> see the Release Notes for a complete list. >> >> - Condition strings set for okay thresholds in the <snmp-device- >> thresholds> >> section of SNMP probes are now displayed in the status window. >> - Fixed an overflow bug in computing percent errors on an interface. >> - Fixed potential crash when ungrouping items from a probe group on a >> duplicated map. >> - Double-click in a chart will automatically attempt to get the edit >> lock if >> needed. >> - Fixed a problem where the InterMapper DataCenter installer would >> stall at >> 100% complete, on some systems. >> >> >> New Features in InterMapper 5.1: >> >> - Probe Groups: Group a number of probes for an IP address into a >> single >> icon. >> - SMS notifiers allow you to send SMS notifications directly to a >> cell phone >> using a cellular (GSM or CDMA) modem, rather than relying on TAP or >> email >> gateways. >> - Google Earth integration: InterMapper can supply device >> information as a >> layer to Google Earth. >> - Grid Layout: There's an Arrange -> Grid layout option that lets >> you place >> icons into an m x n grid. >> - Command-line import and export of maps through the RemoteAccess GUI >> - Insert Icon places a non-probed icon or image on the map >> - Server Log preferences that controls the number of lines in the >> scrollback >> - Global Device List Actions: More actions are available in for >> devices in >> the global device list. >> >> The major feature of InterMapper 5.1 is Probe Groups. A Probe Group >> allows >> you to: >> >> - Group a number of probes for an IP address into a single icon. >> - Add new probes to an existing Probe Group. >> - Ungroup the icons (individually, or all the members). >> - Poll each member probe at its own rate, with its own settings. >> - Reflect the most serious condition of all the member probes in the >> icon's >> color. >> - Get notifications when the entire group has a problem. >> - Get (separate) notifications when a member probe has a problem. >> - Handle dependencies - if the "Control Probe" is down, no >> notifications >> will be sent for any other member probes. >> - Show SNMP device and interface information based on the choice of >> the >> Control Probe. >> >> >> For a complete list of new features, please visit the "What's New" >> page and >> read the Probe Groups tech note. You'll find links to both further >> in this >> message. >> >> >> OTHER NOTES: >> >> Warning: Since 5.1b5 is still beta-test software, it is not >> recommended that >> you use it in a production environment. In addition, InterMapper 5.1 >> uses a >> new file format which is not backwards compatible with InterMapper >> 5.0. For >> this reason, we recommend that you do not install InterMapper 5.1 >> beta >> releases on your primary InterMapper server; install it on a >> secondary >> machine and work with a copy of your InterMapper Settings folder. We >> have >> provided a test serial number on the download page that you can use >> for an >> entirely separate installation. If you do wish to install it on your >> production server, please backup your InterMapper Settings folder >> prior to >> upgrading to 5.1b5. >> >> >> Having said all that, we deeply appreciate your willingness to try >> out these >> beta versions. Your feedback gives us a lot of insight into the >> problems of >> people who manage real networks. Thanks again. >> >> >> The InterMapper Team >> >> >> PS. Why "False Pony"? Well, all of our customers love the traffic >> "ants". >> With over 1,500 species of ants in Australia, we figure that we'll >> never run >> out of code names... http://www.ento.csiro.au/aicn/name_c/a_1487.htm >> >> LINKS: >> >> Download: >> >> http://dartware.com/downloads/binaries/?release=beta >> >> Release Notes: >> >> http://dartware.com/downloads/binaries/intermapperbetarelnotes.html >> >> What's New: >> >> http://dartware.com/network_monitoring_products/whatsnew51.html >> >> Probe Groups Tech Note: >> >> http://dartware.com/support/tech_notes/assortedtopics/ >> probegroups.html >> >> >> >> >> >> >> ____________________________________________________________________ >> List archives: >> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >> To unsubscribe: send email to: [email protected] >> > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [email protected] > > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [email protected] > ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [email protected] ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [email protected]
