I’m trying to understand how to manage traps generated by syslog events.
Is it possible to receive X number of syslog traps and generate a single incident based on traps per a given time frame or simply on the number of traps without creating incidents for all the traps or retaining all the traps?
I thought that dampening would be the way to do that but I appear to be simply creating an additional incident with Dampening.
“The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.” ― Albert Einstein
Demped is mainly use to suppress (delay) certain Incident from appearing to the console till as may be another incident in a certain time appear and disable it,
Interface goes down and get back up in 3 minutes, so you may want not to recieve this event for this interface, so you delay the down incident till node up apear and close it without annoying the administrator.
Rate (track incident frequancy) is used to evaluate (not to suppress) the trend for certain incident, if it got repeated many times in certain period it will alert the administrator about this occurance.
Configuring syslog trap messages is a tedious process within NNMi for it's not suitable equipped to do this in an easy way. When you want to unravel all the different syslog messages you'll have to define "Custom Correlation" "Causal Rules" and generate a new incident for each syslog message you would like to see as a unique root-cause or fault incident. Filters on your child incident (your syslog trap) must be defined to determine which kind of syslog message you have received.
My advise would be to use the SNMP traps where ever you can because NNMi uses certain traps as hints. For instance interface down traps are used as hints and when received NNMi takes certain actions. But when this message is sent within a syslog trap NNMi is not aware for this event for it doesn't use syslog traps as hints.
The thing with NNMi incident handling is that incidents in the process of correlation are not deleted (deduplication is an exception) unless you as a user explicitly delete incidents (within actions or by hand). Regards,
I would avoid sending syslog messages as SNMP traps. In some cases, the rate of syslogs can be very high, and if you send them as SNMP traps to an NNMi server, they can cause unnecessary trap processing load and CPU consumption.
Moreover, AFAIK NNMi can not utilize any information from the majority of syslog messages, if at all.
I suggest setting up a syslog server (syslog-ng, rsyslog, or whichever you like), and running logcheck periodically, and sending the log summaries of the important messages as custom SNMP traps to the NNMi server.
Or if you need immediate alert for specific syslog messages (like an ASA failover condition for instance), then you can set up specific patterns and script actions in the syslog config to send custom SNMP traps immediately.