Traps with same ID, different message

This support forum board is for support questions relating to Nagios XI, our flagship commercial network monitoring solution.
Locked
vmesquita
Posts: 315
Joined: Fri Aug 10, 2012 12:52 pm

Traps with same ID, different message

Post by vmesquita »

Hello!

I am trying to track Switch Power supplys using Nagios SNMP interface. But the problem I came across is that the switch used the same trap ID to report Power supply failure and power supply recovery, just varying the description. Is there any way I could associate this to different states? Below there's the corresponding part from snmpttunknown.log:

Code: Select all

Thu Jul 14 17:55:18 2016: Unknown trap (.1.3.6.1.4.1.9.9.13.3.0.5) received from 172.27.22.1 at:
Value 0: 172.27.22.1
Value 1: 172.27.22.1
Value 2: 242:10:19:10.77
Value 3: .1.3.6.1.4.1.9.9.13.3.0.5
Value 4: 172.27.22.1
Value 5: public
Value 6: .1.3.6.1.4.1.9.9.13.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.9.9.13.1.5.1.2.2058=Sw2, PS1 Faulty, RPS NotExist
Ent Value 1: .1.3.6.1.4.1.9.9.13.1.5.1.3.2058=6


Thu Jul 14 17:55:21 2016: Unknown trap (.1.3.6.1.4.1.9.9.13.3.0.5) received from 172.27.22.1 at:
Value 0: 172.27.22.1
Value 1: 172.27.22.1
Value 2: 242:10:19:13.79
Value 3: .1.3.6.1.4.1.9.9.13.3.0.5
Value 4: 172.27.22.1
Value 5: public
Value 6: .1.3.6.1.4.1.9.9.13.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.9.9.13.1.5.1.2.2058=Sw2, PS1 Normal, RPS NotExist
Ent Value 1: .1.3.6.1.4.1.9.9.13.1.5.1.3.2058=1
ssax
Dreams In Code
Posts: 7682
Joined: Wed Feb 11, 2015 12:54 pm

Re: Traps with same ID, different message

Post by ssax »

Yes, using the MATCH statement:

http://snmptt.sourceforge.net/docs/snmp ... CONF-MATCH

Here's they are:

Code: Select all

EVENT ciscoEnvMonRedundantSupplyNotification .1.3.6.1.4.1.9.9.13.3.0.5 "Status Events" Normal
FORMAT A ciscoEnvMonRedundantSupplyNotification is sent if $*
MATCH $2: (Normal)
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "A ciscoEnvMonRedundantSupplyNotification is sent if $*"
SDESC
A ciscoEnvMonRedundantSupplyNotification is sent if
the redundant power supply (where extant) fails.
Since such a notification is usually generated before
the shutdown state is reached, it can convey more
data and has a better chance of being sent
than does the ciscoEnvMonShutdownNotification.
This notification is deprecated in favour of
ciscoEnvMonSuppStatusChangeNotif.
Variables:
  1: ciscoEnvMonSupplyStatusDescr
  2: ciscoEnvMonSupplyState
EDESC

Code: Select all

EVENT ciscoEnvMonRedundantSupplyNotification .1.3.6.1.4.1.9.9.13.3.0.5 "Status Events" Critical
FORMAT A ciscoEnvMonRedundantSupplyNotification is sent if $*
MATCH $2: (Faulty)
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "A ciscoEnvMonRedundantSupplyNotification is sent if $*"
SDESC
A ciscoEnvMonRedundantSupplyNotification is sent if
the redundant power supply (where extant) fails.
Since such a notification is usually generated before
the shutdown state is reached, it can convey more
data and has a better chance of being sent
than does the ciscoEnvMonShutdownNotification.
This notification is deprecated in favour of
ciscoEnvMonSuppStatusChangeNotif.
Variables:
  1: ciscoEnvMonSupplyStatusDescr
  2: ciscoEnvMonSupplyState
EDESC
Put those in your /etc/snmp/snmptt.conf and restart the snmptt service:

Code: Select all

service snmptt restart
vmesquita
Posts: 315
Joined: Fri Aug 10, 2012 12:52 pm

Re: Traps with same ID, different message

Post by vmesquita »

Thanks! That's exactly what I needed.
ssax
Dreams In Code
Posts: 7682
Joined: Wed Feb 11, 2015 12:54 pm

Re: Traps with same ID, different message

Post by ssax »

No problem, we're here to help, did you test it out and it works for you? If so, can we mark this as resolved and lock the topic?
vmesquita
Posts: 315
Joined: Fri Aug 10, 2012 12:52 pm

Re: Traps with same ID, different message

Post by vmesquita »

I added the line you suggested to the config file and restarted the service, however for some strange reason the trap is still being logged at snmpttunknown.log

snmptt.conf:

Code: Select all

#
#
#
# Traps para detectar falha na fonte secundaria de switch
EVENT ciscoEnvMonRedundantSupplyNotification .1.3.6.1.4.1.9.9.13.3.0.5 "Status Events" Normal
FORMAT A ciscoEnvMonRedundantSupplyNotification is sent if $*
MATCH $2: (Normal)
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "A ciscoEnvMonRedundantSupplyNotification is sent if $*"
SDESC
A ciscoEnvMonRedundantSupplyNotification is sent if
the redundant power supply (where extant) fails.
Since such a notification is usually generated before
the shutdown state is reached, it can convey more
data and has a better chance of being sent
than does the ciscoEnvMonShutdownNotification.
This notification is deprecated in favour of
ciscoEnvMonSuppStatusChangeNotif.
Variables:
  1: ciscoEnvMonSupplyStatusDescr
  2: ciscoEnvMonSupplyState
EDESC
#
#
#
EVENT ciscoEnvMonRedundantSupplyNotification .1.3.6.1.4.1.9.9.13.3.0.5 "Status Events" Critical
FORMAT A ciscoEnvMonRedundantSupplyNotification is sent if $*
MATCH $2: (Faulty)
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "A ciscoEnvMonRedundantSupplyNotification is sent if $*"
SDESC
A ciscoEnvMonRedundantSupplyNotification is sent if
the redundant power supply (where extant) fails.
Since such a notification is usually generated before
the shutdown state is reached, it can convey more
data and has a better chance of being sent
than does the ciscoEnvMonShutdownNotification.
This notification is deprecated in favour of
ciscoEnvMonSuppStatusChangeNotif.
Variables:
  1: ciscoEnvMonSupplyStatusDescr
  2: ciscoEnvMonSupplyState
EDESC
snmpttunknown.log

Code: Select all

Fri Jul 15 16:23:21 2016: Unknown trap (.1.3.6.1.4.1.9.9.13.3.0.5) received from 172.27.22.1 at:
Value 0: 172.27.22.1
Value 1: 172.27.22.1
Value 2: 243:8:47:13.38
Value 3: .1.3.6.1.4.1.9.9.13.3.0.5
Value 4: 172.27.22.1
Value 5: public
Value 6: .1.3.6.1.4.1.9.9.13.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.9.9.13.1.5.1.2.1061=Sw1, PS1 Faulty, RPS NotExist
Ent Value 1: .1.3.6.1.4.1.9.9.13.1.5.1.3.1061=6


Fri Jul 15 16:23:23 2016: Unknown trap (.1.3.6.1.4.1.9.9.13.3.0.5) received from 172.27.22.1 at:
Value 0: 172.27.22.1
Value 1: 172.27.22.1
Value 2: 243:8:47:15.39
Value 3: .1.3.6.1.4.1.9.9.13.3.0.5
Value 4: 172.27.22.1
Value 5: public
Value 6: .1.3.6.1.4.1.9.9.13.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.9.9.13.1.5.1.2.1061=Sw1, PS1 Normal, RPS NotExist
Ent Value 1: .1.3.6.1.4.1.9.9.13.1.5.1.3.1061=1
Any idea on how we could fix the issue?
User avatar
Box293
Too Basu
Posts: 5126
Joined: Sun Feb 07, 2010 10:55 pm
Location: Deniliquin, Australia
Contact:

Re: Traps with same ID, different message

Post by Box293 »

It's hitting snmpttunknown.log because the MATCH statements are not "matching".

I think we need to change the MATCH lines as I suspect we're looking at the wrong variable, try:

Code: Select all

MATCH $1: (Normal)
MATCH $1: (Faulty)
If they don't work, try:

Code: Select all

MATCH $+1: (Normal)
MATCH $+1: (Faulty)
I would also be inclined to change the faulty "match" to be anything that isn't normal (a catch-all).

Code: Select all

MATCH $1: !(Normal)
Does any of this help?
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
vmesquita
Posts: 315
Joined: Fri Aug 10, 2012 12:52 pm

Re: Traps with same ID, different message

Post by vmesquita »

Sorry for the late reply. It's now working with the last syntax.
ssax
Dreams In Code
Posts: 7682
Joined: Wed Feb 11, 2015 12:54 pm

Re: Traps with same ID, different message

Post by ssax »

That's great to hear, are we okay to mark this as resolved and lock the topic?
vmesquita
Posts: 315
Joined: Fri Aug 10, 2012 12:52 pm

Re: Traps with same ID, different message

Post by vmesquita »

Yes, you can lock it.
Locked