Open for Voting
over 2 years ago

Log Analyzer - Out-of-Box Rules and Integration with NPM Alerts


Solarwinds does a fantastic job of alerting with polling, but sometimes you need to know that something is down before the next poll. Because of this, each customer has to create various rules for SNMP traps in Log Analyzer.

Examples of things many customers will want to alert on with traps:

Routing Neighbor Down / Up

Interface Down / Up

Interface Flapping

Power Supply Down / Up

Radius Server Dead / Alive

Every single customer needs to create the same rules for the same things. They need to do this in Log Analyzer, and then they need to do it again in NPM for the alerts.  Additionally, this causes double alerting. First the SNMP trap alert fires, and then the polling alert fires if the problem still exists through the next polling cycle.

There is an additional problem in that Log Analyzer does not differentiate between instances of things (bgp peers, power supplies, etc), and so only one alert can be fired by Log Analyzer even if multiple instances of a problem occur. I discussed this in another feature request.

Potential Solution:

Include more out-of-the-box rules for common SNMP traps and syslogs with Log Analyzer.

More importantly, allow the status of interfaces, nodes, routing neighbors, etc. to be set by Log Analyzer. This would allow the alerts the customer has already built in NPM to be used. A second rule that pertains to SNMP traps or syslogs would not be needed, and double alerting would not occur. I did not use it, but I believe this was possible in the previous snmp trap product.

  • Potential Solution to Instances:

    Allow a node to have an alert for each instance identified by for example:

    alarmActiveResourceId in the case of of the ALARM-MIB:alarmActiveState or alarmClearState;

    ifIndex in the case of the IF-MIB:linkDown or IF-MIB:linkUp

    Possibly allow the administrator to configure the variable binding that designates instance in the rule.