SNMP Traps best practices

This support forum board is for support questions relating to Nagios XI, our flagship commercial network monitoring solution.
User avatar
BanditBBS
Posts: 2474
Joined: Tue May 31, 2011 12:57 pm
Location: Scio, OH
Contact:

SNMP Traps best practices

Post by BanditBBS »

Ok, so I have had traps up and working for a while now. I would love to be using NSTI(trying to get help in NSTI forums) but even with or without that I have a question or two. What is the best practices setup for the trap service?

1.) Should it be set to volatile? Will this make it alert on every subsequent trap received regardless of if the state changed or not?
2.) How can I make it alert even on Normal/Ok traps?

Thanks
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
sreinhardt
-fno-stack-protector
Posts: 4366
Joined: Mon Nov 19, 2012 12:10 pm

Re: SNMP Traps best practices

Post by sreinhardt »

It really depends on what you wish to see and be notified for. In your case it seems that volatile would be a good option if you wish to have every message even repeats sent, or in the case of an already critical alert and another comes in to have that sent. However this can get overwhelming. As for OK states, you could likely do it one of two ways. Either change the snmptrapd severity and force it to be a warning or critical. Otherwise I would think alerting on recovery "should" alert on an OK state as well, volatile may help too.

Note I have not tested these settings, just how I would expect it to work. My thinking may certainly be flawed!
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
User avatar
BanditBBS
Posts: 2474
Joined: Tue May 31, 2011 12:57 pm
Location: Scio, OH
Contact:

Re: SNMP Traps best practices

Post by BanditBBS »

sreinhardt wrote:Note I have not tested these settings, just how I would expect it to work. My thinking may certainly be flawed!
I'll test and will report back.
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
sreinhardt
-fno-stack-protector
Posts: 4366
Joined: Mon Nov 19, 2012 12:10 pm

Re: SNMP Traps best practices

Post by sreinhardt »

Sounds great, I'm kind of excited to see how this works!.... hmm is that a bad thing that I'm excited about snmp traps?
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
User avatar
BanditBBS
Posts: 2474
Joined: Tue May 31, 2011 12:57 pm
Location: Scio, OH
Contact:

Re: SNMP Traps best practices

Post by BanditBBS »

sreinhardt wrote:Sounds great, I'm kind of excited to see how this works!.... hmm is that a bad thing that I'm excited about snmp traps?
No, glad someone else is :)

Back on topic, I set the service to volatile, checked all notification options and even set it to stalk. None of the OK or Normal traps are being alerted and none are being logged either, which I thought would happen at least with the stalking on.
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
sreinhardt
-fno-stack-protector
Posts: 4366
Joined: Mon Nov 19, 2012 12:10 pm

Re: SNMP Traps best practices

Post by sreinhardt »

Talking with our good buddy nscott. He confirmed that the basic idea should work. Setting notify on recovery(among other things), volatile, and 0 notification delay.... However if you are not seeing them get logged into XI it is more likely an issue with snmptt. Have you verified that there is nothing new in the unknown log and that the snmptt configuration has the correct oid? Essentially anything that it knows about ok, normal, warning, or critical should get logged in xi without any exceptions.
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
User avatar
BanditBBS
Posts: 2474
Joined: Tue May 31, 2011 12:57 pm
Location: Scio, OH
Contact:

Re: SNMP Traps best practices

Post by BanditBBS »

They are all appearing in the event log. I don't know what I was talking about in my last post. However, with the settings discussed, none are alerting the assigned contacts. The only time an OK gets alerted is if the service was in a warning or critical state before receiving the OK.
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
abrist
Red Shirt
Posts: 8334
Joined: Thu Nov 15, 2012 1:20 pm

Re: SNMP Traps best practices

Post by abrist »

Are you set to be notified about "recovery" states? If the service is set to volatile, my understanding is that every check is treated as a state change. Alternatively, you could set the service to volatile and create an event handler that notifies the relevant contacts. As event handlers run at every state change, volatile will force the event handler every time a trap is received.
Former Nagios employee
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.
User avatar
BanditBBS
Posts: 2474
Joined: Tue May 31, 2011 12:57 pm
Location: Scio, OH
Contact:

Re: SNMP Traps best practices

Post by BanditBBS »

abrist wrote:Are you set to be notified about "recovery" states? If the service is set to volatile, my understanding is that every check is treated as a state change. Alternatively, you could set the service to volatile and create an event handler that notifies the relevant contacts. As event handlers run at every state change, volatile will force the event handler every time a trap is received.
Yep, my account has all alerts enabled except downtime alerts. Here is the service configuration file:

Code: Select all

define service {
        host_name                       10.250.254.112
        service_description             SNMP Traps
        use                             xiwizard_snmptrap_service
        is_volatile                     1
        max_check_attempts              1
        check_interval                  1
        retry_interval                  1
        check_period                    xi_timeperiod_24x7
        notification_interval           1
        first_notification_delay        0
        notification_period             xi_timeperiod_24x7
        notification_options            w,c,u,r,f,s,
        notifications_enabled           1
        contacts                        clarkj
        stalking_options                o,w,c,u,
        icon_image                      snmptrap.png
        _xiwizard                       snmp_trap
        register                        1
        }
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
sreinhardt
-fno-stack-protector
Posts: 4366
Joined: Mon Nov 19, 2012 12:10 pm

Re: SNMP Traps best practices

Post by sreinhardt »

You generally have a good handle on whats going on around here, so I'm just going to throw this out there on the off chance it was overlooked. While your service has notify for everything, does your contact also? Could be that its just getting restricted there.. but again I would think you covered that already.
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Locked