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
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.
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.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community.
More than 150,000 members are here to solve problems, share technology and best practices, and directly
contribute to our product development process.