Last time we looked at how to get SNMPtraps received into Nagios. This time we'll show how Opsview handles the configuration of it.
Recall that the new design is:
- SNMP packet received by snmptrapd
- snmptrapd's traphandle calls snmptrap2nagios
- snmptrap2nagios, if applicable, will write to the Nagios command file
In Opsview, we use a web interface to configure the traps we are interested in. On this screen, we define the traps we expect to receive.
Each trap has an alert level and a message. The message can use macros which are supported by our perl module SNMP::Trapinfo. You define them on this screen.
If desired, you can deny this trap, so when the trap gets to snmptrap2nagios, it will be discarded. It is possible to deny the trap at snmptrapd, but we haven't done that (as you normally have to be root to change snmptrapd's configuration file. However, this is a worthwhile enhancement if there are lots of traps received).
But that's not all! If a trap is allowed, you can then select to process it or ignore it at the host level. Here's the configuration screen you get for defining your service check. This service check is then associated with a host.
What is the defer option? Well, we thought there are 3 possible actions when a trap is received:
- You want to process it
- You want to ignore it
- You weren't expecting it!
So defer means you haven't said either way. This is the default for any new traps.
When this servicecheck has been linked to a host, Opsview will then configure Nagios with a service check called Interface which will accept traps linkUp and linkDown. The state of this servicecheck in Nagios will change dependant on the alert level defined for these traps.
So we have 2 levels of filtering:
- globally deny a trap
- ignore a trap on a host basis
What if, say, a Security trap arrives for a host that does not have the service associated with it? This is an exception, which needs manually intervention. Opsview has a table called snmptrapexceptions which stores all the traps that snmptrap2nagios hasn't been told what to do with. When we thought about it, there were 5 distinct error conditions:
- A trap was received with no valid trapname
- A trap was received where the trapname was not fully translated - this usually means a MIB file has not been loaded
- A trap was not recognised - it has not been defined
- A trap was received, but it was not expected for this host (defer)
- A trap was received for a host that is not defined to Nagios
We have a screen which shows all the exceptions and then gives operational options on what actions to take next.
Notice there is a Promote Mib button. When we distribute Opsview, we put all our known MIBs into /usr/local/nagios/snmp/all. However, there is a penalty with loading unnecessary MIBs. So we configure snmpd to only load mibs in the default area and /usr/local/nagios/snmp/load.
When you click Promote Mib, we use a perl module called Net::Dev::MIBLoadOrder, which can tell you which MIB a specific OID belongs to. We then copy that MIB file into /usr/local/nagios/snmp/load and restart snmpd. This is one major administrative headache reduced!
Once you've redefined the actions you want, we tell Opsview to reprocess all the snmptrap exceptions based on the new rules (but no passive checks are submitted to Nagios). This will reduce the exceptions table so then an administrator would continue to set new rules until there are no exceptions left.
Astute readers may be wondering: "what happens if I receive a trap which is bad (linkDown) and then a good trap (linkUp) on the same service check"? The answer is that the bad trap will make the service go CRITICAL/WARNING, but the good trap will make the service OK. This means it may potentially get lost. We've made a decision to take this limitation, rather than use the is_volatile or stalking_options. However, we're in discussions with Ethan to see if we can enhance Nagios to cope with this types of event.
Our aim is to make Opsview as easy to use, while we continue to improve Nagios and the general open source universe, through software or knowledge sharing. We hope this gives you an insight how you can get SNMPtraps working with Nagios.
Recent Comments