Dependencies

Question

Dependencies don't always seem to suppress alerts. For example, we have servers with 20+ SNMP-based monitors and we have PING and SNMP as the dependencies. If the server goes down we get down alerts for all monitors that are due to be polled before the dependencies are next polled, and when the server comes back up we get up alerts for all those same monitors.

Perhaps what's needed is for ipMonitor to reevalute the dependencies in realtime when a monitor goes down and before sending an alert. This would be a bit more overhead but would prevent a lot of unnecessary alerts.

Is this possible within the current version or being considered for a future version?

Thanks - Simon

Peter.Cooper · Accepted Answer

Your post will go into a feature request for more intelligent alert suppression & correlation.

In the meantime, what are the polling frequencies for your SNMP monitors and your ping monitors?

- Also keep in mind "the number of failures to trigger an Alert" on the ping monitor.

ipMonitor wants the dependency to go 'down' before the other monitors. We don't want to suppress alerts if the dependency is slightly intermittent, or has a false-negative! Also, once we send an alert [to an administrator] about a Monitor, we don't want to suppress that communication channel should we find out more information about the dependency... ipMonitor will see it through until the Monitor comes back up. (Very important should dependency alerting for core switches get sent to somebody other than the 'email guys').

So to recap: Get that ping monitor to go down before the other ones. That means increasing how often you poll, or dropping the number of failures to alert. That will do the trick! The Mass Monitor editor can be really handy in this regard to change the timing and alerting behavior on these dependency monitors.