SNMP Trap Monitoring in Nagios XI

[tgriep]

The screen capture looks OK.
Can you post the following file so I can see if there are duplicate TRAPS?

Code: Select all

/etc/snmp/snmptt.conf.nxti

[emartine]

### AUTO-GENERATED BY NXTI. DO NOT HAND-EDIT THIS FILE. ###
EVENT oplGenericV2Trap_Ok .1.3.6.1.4.1.4184.2.0.2 "Status Events" Normal
FORMAT Received trap "$N" with variables "$+*"
EXEC php /usr/local/nagiosxi/scripts/nxti.php --event_name="$N" --event_oid="$i" --numeric_oid="$o" --symbolic_oid="$O" --community="$C" --trap_hostname="$R" --trap_ip="$aR" --agent_hostname="$A" --agent_ip="$aA" --category="$c" --severity="$s" --uptime="$T" --datetime="$x $X" --unixtime="$@" --bindings="$+*"
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "" "The SMS OPENLink Alert process has issued an alert condition. The variables are: $*"
MATCH $6: 1
SDESC
The SMS OPENLink Alert process has issued an alert condition. The variables are:oplServiceName - The display name of the NT service on which the alert was issued.oplServiceState - Current state of the NT service.oplDesignName - The ODBC name of the design reporting the alert.oplInterfaceName - The name of the interface associated with the alert (optional).oplConnectionName - The name of the connection associated with the alert (optional).oplAlertName - The alert identifier code.oplAlertSeverity - The severity of the alert.oplAlertDescription - A textual description that elaborates on the condition being reported.oplAlertDescription2 - A continuation of the textual description that elaborates on the condition being reported.oplAlertTime - A textual description that indicates the time when the condition occured.oplAlertExtendedSeverity - Severity, as inidated by the Platform (optional).oplAlertMachine - Machine that initiated this event (optional).oplAlertEntityType - Entity Type the machine belongs to (optional).oplAlertPrimaryStatus - The primary status of the alert.oplAlertSecondaryStatus - The secondary status of the alert.oplAlertURL - The Universal Resource Locator (URL) associated with this alert (optional).oplAlertURL2 - A continuation of the URL associated with this alert (optional).The frequency of this event is determined by two criteria, if the alert is issued as a resultof a situation within the SMS OPENLink server, the individual characteristics of each alertas defined in the OPENLink design database control the frequency. If the event was triggered by an alert request issued through the SMS OPENLink API the frequency is unknownVariables: 1: oplServiceName 2: oplServiceState 3: oplDesignName 4: oplInterfaceName 5: oplConnectionName 6: oplAlertName 7: oplAlertSeverity 8: oplAlertDescription 9: oplAlertDescription2 10: oplAlertTime 11: oplAlertExtendedSeverity 12: oplAlertMachineName 13: oplAlertEntityType 14: oplAlertPrimaryStatus 15: oplAlertSecondaryStatus 16: oplAlertURL 17: oplAlertURL2
EDESC


EVENT oplGenericV2Trap .1.3.6.1.4.1.4184.2.0.2 "Fatal" Critical
FORMAT Received trap "$N" with variables "$+*"
EXEC php /usr/local/nagiosxi/scripts/nxti.php --event_name="$N" --event_oid="$i" --numeric_oid="$o" --symbolic_oid="$O" --community="$C" --trap_hostname="$R" --trap_ip="$aR" --agent_hostname="$A" --agent_ip="$aA" --category="$c" --severity="$s" --uptime="$T" --datetime="$x $X" --unixtime="$@" --bindings="$+*"
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "" "$7"
MATCH $6: > 2
SDESC
DOWN, Interface is not operational- ERROR status for Connection.
EDESC

[tgriep]

I need to get the full file so I can verify all of the trap settings.

[emartine]

Sent via PM.

[tgriep]

Thanks for the file. It only has 2 traps like you posted so there is not another trap settings the critical in XI.
Can you provide a screen capture of the Critical status in XI?

[tgriep]

Also, get the following file and upload it to the post.

Code: Select all

/var/log/snmptt/snmptt.log

Make sure is shows the received trap for the Critical, if not, I will need to see an older log file in that folder.

[emartine]

Sent via PM. I have until 5:00 today to get this configured and working... after that all of this will have been for nothing.

[tgriep]

Thanks for the log file. As far as I see, the critical was generated on the 28th but today, it is generating the OK status with a number 1 in the status field so it looks good now.
If you were still editing the traps on the 28th, one of the match statements was probably wrong and since then, has been fixed.

[emartine]

I am not editing them at this point but I am still getting a different output for the critical messages.




Wed Sep 30 16:41:09 2020 .1.3.6.1.4.1.4184.2.0.2 Critical "Fatal" <server IP> - Received trap "oplGenericV2Trap" with variables "enterprises.4184.2.1.2.1.2.23.67.101.114.110.101.114.95.79.80.69.78.76.105.110.107.95.50.52.46.49.45.48.53:Cerner OPENLink 24.1-05 enterprises.4184.2.1.2.1.5.23.67.101.114.110.101.114.95.79.80.69.78.76.105.110.107.95.50.52.46.49.45.48.53:1
enterprises.4184.2.2.2.1.1.13.73.67.79.80.50.52.49.53.72.48.65.72.70:ICOP2415H0AHF
enterprises.4184.2.5.1.0:EN92
enterprises.4184.2.5.2.0:1
enterprises.4184.2.5.3.0:RELOAD - Alert process reload by user request.
enterprises.4184.2.5.4.0:2020-09-30 16:41:09 enterprises.4184.2.5.8.0:0 enterprises.4184.2.5.9.0:0"



This should be an ok state but showing as critical

[tgriep]

Take a look at this file /etc/snmp/snmptt.conf file to see if there is a Critical Trap defined in it. If so, remove it.

Also, restart the snmptt daemon to reload the files in case it was not restarted when you were doing the edits.


One of the traps from the log file for yesterday showing a Normal "OK" status trap when a 1 was received.

Code: Select all

Wed Sep 30 10:59:10 2020 .1.3.6.1.4.1.4184.2.0.2 Normal "Status Events" xxx.xxx.xxx.xxx - Received trap "oplGenericV2Trap_Ok" with variables enterprises.4184.2.1.2.1.2.23.67.101.114.110.101.114.95.79.80.69.78.76.105.110.107.95.50.52.46.49.45.48.53:Cerner OPENLink 24.1-05 enterprises.4184.2.1.2.1.5.23.67.101.114.110.101.114.95.79.80.69.78.76.105.110.107.95.50.52.46.49.45.48.53:1
enterprises.4184.2.2.2.1.1.12.73.67.79.80.50.52.49.53.72.48.65.72:ICOP2415H0AH
enterprises.4184.2.3.2.1.1.12.73.67.79.80.50.52.49.53.72.48.65.72.10.83.79.65.82.83.95.80.79.76.89:SOARS_POLY
enterprises.4184.2.5.1.0:IN07
enterprises.4184.2.5.2.0:1
enterprises.4184.2.5.3.0:ACTIVE and the Alert process is monitoring this interface.
enterprises.4184.2.5.4.0:2020-09-30 10:59:05 
enterprises.4184.2.5.8.0:0 
enterprises.4184.2.5.9.0:0

Do you see it in the nagios logs as an OK status?