Page 1 of 1
Traps with same ID, different message
Posted: Fri Jul 15, 2016 11:10 am
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
Re: Traps with same ID, different message
Posted: Fri Jul 15, 2016 12:15 pm
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:
Re: Traps with same ID, different message
Posted: Fri Jul 15, 2016 12:28 pm
by vmesquita
Thanks! That's exactly what I needed.
Re: Traps with same ID, different message
Posted: Fri Jul 15, 2016 12:41 pm
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?
Re: Traps with same ID, different message
Posted: Fri Jul 15, 2016 2:30 pm
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?
Re: Traps with same ID, different message
Posted: Sun Jul 17, 2016 8:22 pm
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).
Does any of this help?
Re: Traps with same ID, different message
Posted: Wed Aug 17, 2016 4:06 pm
by vmesquita
Sorry for the late reply. It's now working with the last syntax.
Re: Traps with same ID, different message
Posted: Wed Aug 17, 2016 4:14 pm
by ssax
That's great to hear, are we okay to mark this as resolved and lock the topic?
Re: Traps with same ID, different message
Posted: Mon Aug 22, 2016 4:40 pm
by vmesquita
Yes, you can lock it.