Nagios Send SNMP Traps

We hope this small guide can help you quickly setup your SNMP traps out to a remote management host.
First thing do ensure that your Nagios box has the snmptrap binary and perhaps all other associated SNMP binaries installed. If you haven’t a good start would be to use the following lines:
This guide was made using Nagios 3.2.0, Debian 5
Debians..

apt-get install snmp snmpd libsnmp-dev

Redhats..

yum install net-snmp net-snmp-utils net-snmp-devel –y

In Nagios, we setup to have SNMP traps to send out to a HP OpenView box in our customer’s corporate network. These traps are sent as Event Handlers in Nagios. You may try doing them as normal notifications (i guess, haven’t tested).
So, each time there’s a state change (e.g. from OK to Warning), you will get, beside the standard notifications, an event that triggers a snmp trap to a remote management host.
To make things simple, we use existing config definitions such as the original commands.cfg and the linux-services.cfg. The following guide attempt to send a trap when there’s more than 2 or 3 users logging onto the nagios (localhost) box.
First, edit the commands.cfg file and add the following lines. I will explain what these lines mean.

define command{
   command_name send_snmptrap
   command_line /usr/bin/snmptrap -v 2c -c public 192.168.2.22 ” NAGIOS-NOTIFY-MIB::nSvcEvent nSvcHostname s “$HOSTNAME$” nSvcDesc s “$SERVICEDESC$” nSvcStateID i $SERVICESTATEID$ nSvcOutput s “$SERVICEOUTPUT$”
}

Simply copy paste everything and it should actually be single lines something like below;
image
The command name can be anything you wish, just as long it’s mentioned correctly in the _x_services.cfg files.
/usr/bin/snmptrap –v 2c –c public 192.168.2.22…
This is quite straightforward, here, we attempt to send SNMPv2 with the community string of public to the remote server 192.168.2.22.
…” NAGIOS-NOTIFY-MIB::nSvcEvent nSvcHostname s “$HOSTNAME$” nSvcDesc s “$SERVICEDESC$” nSvcStateID i $SERVICESTATEID$ nSvcOutput s “$SERVICEOUTPUT$”
This part above firstly, feeds the Nagios MIBs so that we can use easy readable words such as NSvcDesc instead of OID numbers. It would be a good idea to give the Nagios MIBs to the 3rd party remote monitoring host as well.
[EDIT: UPDATE: – The Nagios MIB has a wrong definition or its actually meant for V2 of Nagios. Use this MIB which should work for V3]
The next few fields are completely up to you and what you wish Nagios to output to the trap receiver. In my case, $HOSTNAME$ – The monitored host, $SERVICEDESC$ – service description, $SERVICESTATEID$ – the Nagios state id like 0 for OK, 1 – for warning etc…and $SERVICEOUTPUT$ – The additional info field from the plug-in is sufficient. You may add more if you like where you deem necessary.
The Macros ($name$) are defined well in Nagios documentation. The n(typeID) are found in the MIB files, so do match them well. Some fields have been changed from Integer (i) to octect string (s) and this may cause your traps to fail. Whatever the case is, you can simulate the trap at the CLI such as
snmptrap -v 2c -c public 192.168.2.22 ” NAGIOS-NOTIFY-MIB::nSvcEvent nSvcStateID s “$SERVICESTATEID$”.
This will give errors as nSvcStateID in the MIB is expecting an Integer value, so changing to
nSvcStateID i $SERVICESTATEID$
Will then work. Etc..
Now, the command to execute and send traps out is ready. Now we tell which service/host is to execute this command in a state change (triggering the event handler).
Here’s a sample of my linux-services.cfg

define service{
  use                         debian5-linuxservice
  host_name                   Nagios-Server
  service_description         Current Users
  event_handler               send_snmptrap
  event_handler_enabled       1
  check_command               check_local_users!2!3
  }

NOTE: Check local users thresholds are normally much higher but for testing, i just made it warn at 2 users and critical at 3.
The only two parts i added from the normal service definition are;
event_handler            send_snmptrap
event_handler_enabled    1
That’s all is needed for hosts or services to send traps out with the configured output as above when a state change happens.
send_snmptrap is the logical name i created for that command in commands.cfg. Well, that’s about it. Simple right? Now, just restart your nagios to enable the above configs.
/etc/init.d/nagios restart
And test the traps by sending a passive check in Nagios WEB UI to for example, Warning or Critical.
image
Also, if you would like to test receiving traps, i can recommend you the free iReasoning SNMP toolset. There’s a paid one if you like the rich features of this tool but the free one has limited functions.
Now, for iReasoning, launch the MIB Browser tool. Do load the Nagios MIB to make things much prettier. File >> Load MIBs and select Nagios-Notify-MIB. Now, click on Tools >> Trap Receiver.
In the remote management host value (in my case was 192.168.2.22) enter the IP where iReasoning is running. Ensure your windows firewall enables incoming port UDP 162 for snmptraps if you enable WF.
Trigger something and see it work. See sample from iReasoning below.
NOTE: Whenever you change something in the config files, remember to restart Nagios.
image
image
Please do comment and give further suggestions.

7 Comments

  1. Thats really useful, thanks for writing up. Just gone though and set it up on my server.

    Never knew Nagios could do SNMP traps 🙂

    Thanks

  2. It was exactly what I was searching for, it saved me lots of time !!!

    But it looks like the link for the new MIB isn't working .. :s

    Thank you!

  3. Hi,

    This was a very helpful post, thanks very much. You probably saved me at least a day. I ran into a couple of minor hurdles while following your instructions, so I thought I'd post a couple of notes. I hope you don't mind.

    1. The links to the MIBs didn't work for me. I found what I believe to be the same MIB definitions at http://www.pastebin.com.

    2. The example command lines for snmptrap didn't work for me exactly as posted either. I'm guessing it's a configuration problem on my box (not sure what, exactly). I fixed it by using the paamayim nekudotayim notation on *all* the MIB-derived command line arguments, not just nSvcEvent. So, like:

    snmptrap -v 2c -c public 192.168.2.128 '' NAGIOS-NOTIFY-MIB::nSvcEvent NAGIOS-NOTIFY-MIB::nSvcHostname s some_host NAGIOS-NOTIFY-MIB::nSvcDesc s some_service NAGIOS-NOTIFY-MIB::nSvcStateID i 0

    instead of

    snmptrap -v 2c -c public 192.168.2.128 '' nSvcEvent nSvcHostname s some_host nSvcDesc s some_service nSvcStateID i 0

    Anyway, hope the above saves somebody somewhere a minute or two. Thanks again for a very useful post.

    –J. Random Internet Dude

  4. Thanks so much for posting these instructions. They are most invaluable.

    I'm new to Nagios and I've been looking into using event-handlers to forward alerts via SNMP to another NMS.

    Is this a more efficient method than the one I'm investigating?

    Thanks,

    K.

  5. Sanjay et al,

    Can you please elaborate on the actually event handler .sh or .pl script that calls this 'send_snmptrap' command?

    I'm under the impression that a script is required in order to make full use of the commands as described in commands.config.

    Please correct me if I'm wrong.

    Thank You.

    KL

  6. Sanjay et al,

    Can you please elaborate on the actually event handler .sh or .pl script that calls this 'send_snmptrap' command?

    I'm under the impression that a script is required in order to make full use of the commands as described in commands.config.

    Please correct me if I'm wrong.

    Thank You.

    KL

Comments are closed.