Re: SNMP Traps coming in as experimental
Posted: Thu Jan 15, 2015 5:20 pm
I've played around with SNMP Traps not too long ago and it does get kind of complicated ... until you understand it's workings.
The most important thing I learnt is that SNMPTT is extremely powerful. Once you master this power you'll have the solution you are after.
I have a solution which may work for you.
In your snmptt.conf file you have an EVENT:
The SDESC section is a description section and is completely ignored by SNMP. So let's remove it:
The FORMAT line is what is logged in /var/log/snmp/snmptt.log.
Next is the EVENT line. This is what matches this EVENT to the incoming trap.
Specifically Normal is what is called the severity and commonly the values used are: Informational, Minor, Major, Severe, Normal, Critical, Warning.
Then when the EXEC line is being constructed, it takes that value ($s) and sends it to snmptraphandling.py.
snmptraphandling.py Then converts Normal to a status code of "0" (OK) for Nagios.
So by default, the traps coming in will always have an OK status. Not so great when something actually goes wrong.
This is where the power of SNMPTT comes in.
What you can do it have multiple EVENTS in the snmptt.conf file for the SAME trap, however each EVENT can use a MATCH expression.
A MATCH expression must be evaluated to true for the trap to be considered a match to this EVENT definition.
So what are we going to match it against and why? We know the following possible values are going to be received in this trap are:
These values will be in the variable $1
So we can create three separate events:
Normal
This will match the value 3
Warning
This will match the value 4
Critical
This will match the value 1, 2 or 5 (snmptraphandling.py does not process unknown so we will lump all the others into the critical category).
This is how you snmptt.conf file will look:
Additionally, you may want a dedicated service for these traps, because any incoming trap will overwrite the last one and all traps for this host go to one service object in Nagios called "SNMP Traps".
Simply change "SNMP Traps" in the EXEC lines above to be "SNMP Trap - Temperature Sensor".
NOTE: The first trap that comes through will appear under Unconfigured Objects in XI and must be turned into a service.
I hope all of this makes sense. I do have a guide on SNMP Traps which is nearly completed, it goes into much more detail than this.
SNMPTT documentation is exceptional:
http://snmptt.sourceforge.net/docs/snmptt.shtml
The most important thing I learnt is that SNMPTT is extremely powerful. Once you master this power you'll have the solution you are after.
I have a solution which may work for you.
In your snmptt.conf file you have an EVENT:
Code: Select all
EVENT connUnitSensorStatusChange .1.3.6.1.3.94.0.5 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The overall status of the connectivity unit has
changed.
Recommended severity level (for filtering): alert
Variables:
1: connUnitSensorStatus
EDESCCode: Select all
EVENT connUnitSensorStatusChange .1.3.6.1.3.94.0.5 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"Next is the EVENT line. This is what matches this EVENT to the incoming trap.
Specifically Normal is what is called the severity and commonly the values used are: Informational, Minor, Major, Severe, Normal, Critical, Warning.
Then when the EXEC line is being constructed, it takes that value ($s) and sends it to snmptraphandling.py.
snmptraphandling.py Then converts Normal to a status code of "0" (OK) for Nagios.
So by default, the traps coming in will always have an OK status. Not so great when something actually goes wrong.
This is where the power of SNMPTT comes in.
What you can do it have multiple EVENTS in the snmptt.conf file for the SAME trap, however each EVENT can use a MATCH expression.
A MATCH expression must be evaluated to true for the trap to be considered a match to this EVENT definition.
So what are we going to match it against and why? We know the following possible values are going to be received in this trap are:
Code: Select all
unknown(1),
other(2),
ok(3), -- the sensor indicates ok
warning(4), -- the sensor indicates a warning
failed(5) -- the sensor indicates failureSo we can create three separate events:
Normal
This will match the value 3
Warning
This will match the value 4
Critical
This will match the value 1, 2 or 5 (snmptraphandling.py does not process unknown so we will lump all the others into the critical category).
This is how you snmptt.conf file will look:
Code: Select all
EVENT connUnitSensorStatusChange .1.3.6.1.3.94.0.5 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$1" "The sensor indicates OK"
MATCH $1: 3Code: Select all
EVENT connUnitSensorStatusChange .1.3.6.1.3.94.0.5 "Status Events" Warning
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$1" "The sensor indicates a WARNING"
MATCH $1: 4Code: Select all
EVENT connUnitSensorStatusChange .1.3.6.1.3.94.0.5 "Status Events" Critical
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$1" "The sensor indicates a FAILURE"
MATCH $1: 1
MATCH $1: 2
MATCH $1: 5Simply change "SNMP Traps" in the EXEC lines above to be "SNMP Trap - Temperature Sensor".
NOTE: The first trap that comes through will appear under Unconfigured Objects in XI and must be turned into a service.
I hope all of this makes sense. I do have a guide on SNMP Traps which is nearly completed, it goes into much more detail than this.
SNMPTT documentation is exceptional:
http://snmptt.sourceforge.net/docs/snmptt.shtml