Status not changed for SNMP monitor
Status not changed for SNMP monitor
Hi,
I have a SNMP trap monitor which status is still showing OK even though there was a trap received that is of warning status:
https://photos.app.goo.gl/JocDwDJWTT2PfFbY8
snippet of the mib from snmptt.conf:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Normal
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "System configuration reload resulted in unexpected errors or warnings which $*"
SDESC
System configuration reload resulted in unexpected errors or warnings which
may impact system functionality. The specific reason of the last error or
warning is identified by svServiceLastReloadDetailsDescription.
Variables:
1: svClusterConfigName
2: sysName
3: svSeverity
4: svServiceLastReloadDetailsId
5: svServiceLastReloadDetailsDescription
6: svServiceLastReloadDetailsTrapEnabled
EDESC
From snmptt.log:
Fri Sep 28 07:53:32 2018 .1.3.6.1.4.1.11610.6799.3.4.0.17 Normal "Status Events" 57.190.9.34 - System configuration reload resulted in unexpected errors or warnings which PTS_SITA_LAB opn-pts-001.opn.sitaonair.com minor policyError SandScript policy true
Looking at /usr/local/bin/snmptraphandling.py a minor should reflect as a WARNING in Nagios but there was no status change. Any advise?
I have a SNMP trap monitor which status is still showing OK even though there was a trap received that is of warning status:
https://photos.app.goo.gl/JocDwDJWTT2PfFbY8
snippet of the mib from snmptt.conf:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Normal
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "System configuration reload resulted in unexpected errors or warnings which $*"
SDESC
System configuration reload resulted in unexpected errors or warnings which
may impact system functionality. The specific reason of the last error or
warning is identified by svServiceLastReloadDetailsDescription.
Variables:
1: svClusterConfigName
2: sysName
3: svSeverity
4: svServiceLastReloadDetailsId
5: svServiceLastReloadDetailsDescription
6: svServiceLastReloadDetailsTrapEnabled
EDESC
From snmptt.log:
Fri Sep 28 07:53:32 2018 .1.3.6.1.4.1.11610.6799.3.4.0.17 Normal "Status Events" 57.190.9.34 - System configuration reload resulted in unexpected errors or warnings which PTS_SITA_LAB opn-pts-001.opn.sitaonair.com minor policyError SandScript policy true
Looking at /usr/local/bin/snmptraphandling.py a minor should reflect as a WARNING in Nagios but there was no status change. Any advise?
Re: Status not changed for SNMP monitor
The event line controls the status that is displayed when a trap matches. Try:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Critical
or
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Warning
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Critical
or
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Warning
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Status not changed for SNMP monitor
The EVENT line is generated when I load the mib into Nagios, would that mean i have to manually edit all the relevant entries for the device and reload the snmptt?
Re: Status not changed for SNMP monitor
That is correct, you will need to adjust the traps that you want from Normal to Critical or Warning in the /etc/snmp/snmptt.conf and then restart the SNMPTT service:
Code: Select all
service snmptt restartRe: Status not changed for SNMP monitor
I adjusted the traps and Nagios is displaying WARNING/CRITICAL as expected.
One further question with reference to the below:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Normal
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "System configuration reload resulted in unexpected errors or warnings which $*"
Am I able to display the EVENT "svSysLastReloadFailedNotification" in the Nagios status information? I believe that would be editing the EXEC part, but what variable should I be using?
One further question with reference to the below:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Normal
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "System configuration reload resulted in unexpected errors or warnings which $*"
Am I able to display the EVENT "svSysLastReloadFailedNotification" in the Nagios status information? I believe that would be editing the EXEC part, but what variable should I be using?
Re: Status not changed for SNMP monitor
Based on the documentation here:
http://snmptt.sourceforge.net/docs/snmp ... ONF-FORMAT
You should be able to use the $N variable:
So it would look like this:
http://snmptt.sourceforge.net/docs/snmp ... ONF-FORMAT
You should be able to use the $N variable:
Code: Select all
$N - Event name defined in .conf file of matched entryCode: Select all
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Normal
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$N - System configuration reload resulted in unexpected errors or warnings which $*"Re: Status not changed for SNMP monitor
Thanks, that works!!
So an extension to the current setup, I have 1 snmp trap for multiple faults, so question is that if I have multiple faults happening and some of them are recovered, the Nagios probe will only display the latest snmp trap message received right? Correct me if I am wrong but the device will only send a new snmp message when there is a status change?
For eg. the following are received in order, Nagios probe will display "recover 2" and "fault 1" and "fault 3" might be overlooked
fault 1
fault 2
fault 3
recover 2
So an extension to the current setup, I have 1 snmp trap for multiple faults, so question is that if I have multiple faults happening and some of them are recovered, the Nagios probe will only display the latest snmp trap message received right? Correct me if I am wrong but the device will only send a new snmp message when there is a status change?
For eg. the following are received in order, Nagios probe will display "recover 2" and "fault 1" and "fault 3" might be overlooked
fault 1
fault 2
fault 3
recover 2
Re: Status not changed for SNMP monitor
You are correct, the key for SNMP trap services is under the Check Settings tab you will see that it uses Is Volatile, you can read more about volatile services here:
https://assets.nagios.com/downloads/nag ... vices.html
So when you run the SNMP Trap wizard it will apply the xiwizard_snmptrap_service service template which resets the check back to OK automatically:
And it has is volatile set to On:
Please read through this document for a great SNMP trap tutorial:
https://support.nagios.com/kb/article.php?id=77
https://assets.nagios.com/downloads/nag ... vices.html
So when you run the SNMP Trap wizard it will apply the xiwizard_snmptrap_service service template which resets the check back to OK automatically:
And it has is volatile set to On:
Please read through this document for a great SNMP trap tutorial:
https://support.nagios.com/kb/article.php?id=77
You do not have the required permissions to view the files attached to this post.
Re: Status not changed for SNMP monitor
Thanks, that was very helpful tutorial.
I was looking at this page (https://www.systemcodegeeks.com/monitor ... ring-snmp/) and trying to configure a single probe for a selected fault on the device, but have some questions based on my oid for "System Config" as follows:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Warning
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$N $s - System configuration reload resulted in unexpected errors or warnings which $*"
SDESC
System configuration reload resulted in unexpected errors or warnings which
may impact system functionality. The specific reason of the last error or
warning is identified by svServiceLastReloadDetailsDescription.
Variables:
1: svClusterConfigName
2: sysName
3: svSeverity
4: svServiceLastReloadDetailsId
5: svServiceLastReloadDetailsDescription
6: svServiceLastReloadDetailsTrapEnabled
EDESC
#
#
#
EVENT svSysLastReloadSucceededNotification .1.3.6.1.4.1.11610.6799.3.4.0.18 "Status Events" Normal
FORMAT System configuration reloaded successfully. $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$N $s - System configuration reloaded successfully. $*"
SDESC
System configuration reloaded successfully.
Variables:
1: svClusterConfigName
2: sysName
3: svSeverity
4: svServiceLastReloadDetailsId
5: svServiceLastReloadDetailsDescription
6: svServiceLastReloadDetailsTrapEnabled
EDESC
- following the page I can configure a check command to capture the oid ending with 4.0.17, however the recovery oid is 4.0.18, how can it be configured in a single probe?
I was looking at this page (https://www.systemcodegeeks.com/monitor ... ring-snmp/) and trying to configure a single probe for a selected fault on the device, but have some questions based on my oid for "System Config" as follows:
EVENT svSysLastReloadFailedNotification .1.3.6.1.4.1.11610.6799.3.4.0.17 "Status Events" Warning
FORMAT System configuration reload resulted in unexpected errors or warnings which $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$N $s - System configuration reload resulted in unexpected errors or warnings which $*"
SDESC
System configuration reload resulted in unexpected errors or warnings which
may impact system functionality. The specific reason of the last error or
warning is identified by svServiceLastReloadDetailsDescription.
Variables:
1: svClusterConfigName
2: sysName
3: svSeverity
4: svServiceLastReloadDetailsId
5: svServiceLastReloadDetailsDescription
6: svServiceLastReloadDetailsTrapEnabled
EDESC
#
#
#
EVENT svSysLastReloadSucceededNotification .1.3.6.1.4.1.11610.6799.3.4.0.18 "Status Events" Normal
FORMAT System configuration reloaded successfully. $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$N $s - System configuration reloaded successfully. $*"
SDESC
System configuration reloaded successfully.
Variables:
1: svClusterConfigName
2: sysName
3: svSeverity
4: svServiceLastReloadDetailsId
5: svServiceLastReloadDetailsDescription
6: svServiceLastReloadDetailsTrapEnabled
EDESC
- following the page I can configure a check command to capture the oid ending with 4.0.17, however the recovery oid is 4.0.18, how can it be configured in a single probe?
Re: Status not changed for SNMP monitor
I am guessing what you mean by a single probe is a single Service Check in Nagios XI, is that correct?
If so, the name of the Service check is controlled by the command on the EXEC line. In your example, the Service check will be called "SNMP Traps".
So, it a remote host send a trap to both of those OID's, it will send the trap data to the same service "SNMP Traps".
As long as that option in the same for all of the entries, it will forward the trap to the same service.
If this is not what you mean, can you provide more details on what you are looking for?
If so, the name of the Service check is controlled by the command on the EXEC line. In your example, the Service check will be called "SNMP Traps".
So, it a remote host send a trap to both of those OID's, it will send the trap data to the same service "SNMP Traps".
As long as that option in the same for all of the entries, it will forward the trap to the same service.
If this is not what you mean, can you provide more details on what you are looking for?
Be sure to check out our Knowledgebase for helpful articles and solutions!