Forum Discussion
I completely agree with this. Different vendors use TRAPs differently and from my experience may send the same trap multiple times, sometimes several times a minute or more even. The TRAP functionality in LogicMonitor will not be useable in these cases because the noise it will create will be a huge distraction for any NOC to be able to handle. It takes their eyes off of other possibly critical events because of multiple duplicate alerts for the same issue.
Let's take Barracuda for instance. Their NextGen Firewalls have a TRAP for HA Partner Unreachable. We received a trap every 5 minutes for about 2 hours while this situation was occurring. From Barracuda's standpoint, this was a single event with notifications that go out every 5 minutes until the error goes away. They don't have a pollable "GET" MIB to track this scenario either.
I would propose the logic this way: LM receives a trap that matches an EventSource criteria and triggers the configured alert. That eventsource is configured with a timeout value (let's say 60 minutes). If another Trap from the same device with the same content comes in before the timeout value, don't create a new alert, but rather increase a "count" counter on that alert AND RESET THE TIMER. As long as no new traps come in within the configured timeout (60 minutes in this example), the alert will clear like normal. If a new trap comes in after the timer, a new alert is generated. You may need to provide an interface to view all the Trap data associated with that one Event Alert since there will now be multiple.
This issue is plaguing our company right now and we are a very large MSP. We are at the mercy of vendors who don't provide polling MIBs for some critical actions like this, hence why SNMP Traps become more of a necessity.
Related Content
- 2 years ago