Nagios Support Forum

I restarted the service manually.
Below is what I see in the /etc/snmp/snmptt.conf
None of them end with the 202 oid.


#
EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
FORMAT Device reinitialized (coldStart)
#EXEC qpage -f TRAP notifygroup1 "Device reinitialized (coldStart)"
SDESC
A coldStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself and that its
configuration may have been altered.
EDESC
#
#
#
EVENT warmStart .1.3.6.1.6.3.1.1.5.2 "Status Events" Normal
FORMAT Device reinitialized (warmStart)
#EXEC qpage -f TRAP notifygroup1 "Device reinitialized (warmStart)"
SDESC
A warmStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself such that its
configuration is unaltered.
EDESC
#
#
#
EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" Normal
FORMAT Link down on interface $1. Admin state: $2. Operational state: $3
#EXEC qpage -f TRAP notifygroup1 "Link down on interface $1. Admin state: $2. Operational state: $3"
SDESC
A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus.
EDESC
#
#
#
EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Status Events" Normal
FORMAT Link up on interface $1. Admin state: $2. Operational state: $3
#EXEC qpage -f TRAP notifygroup1 "Link up on interface $1. Admin state: $2. Operational state: $3"
SDESC
A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus.
EDESC
#
#
#
EVENT authenticationFailure .1.3.6.1.6.3.1.1.5.5 "Status Events" Normal
FORMAT SNMP athentication failure
#EXEC qpage -f TRAP notifygroup1 "SNMP authentication failure"
SDESC
An authenticationFailure trap signifies that the SNMPv2
entity, acting in an agent role, has received a protocol
message that is not properly authenticated. While all
implementations of the SNMPv2 must be capable of generating
this trap, the snmpEnableAuthenTraps object indicates
whether this trap will be generated.
EDESC
~



Regarding the logs I do see that they are coming in as normal in


Wed Sep 30 16:46:09 2020 .1.3.6.1.4.1.4184.2.0.2 Normal "Status Events" <server ip> - 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.13.73.67.79.80.50.52.49.53.72.48.65.72.70:ICOP2415H0AHF enterprises.4184.2.3.2.1.1.13.73.67.79.80.50.52.49.53.72.48.65.72.70.12.51.77.95.83.79.65.82.70.95.68.70.84:3M_SOARF_DFT 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 16:46:09 enterprises.4184.2.5.8.0:0 enterprises.4184.2.5.9.0:0"

Wed Sep 30 16:46:09 2020 .1.3.6.1.4.1.4184.2.0.2 Normal "Status Events" <server ip> - 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.13.73.67.79.80.50.52.49.53.72.48.65.72.70:ICOP2415H0AHF enterprises.4184.2.3.2.1.1.13.73.67.79.80.50.52.49.53.72.48.65.72.70.7.73.78.71.95.68.83.83:ING_DSS 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 16:46:09 enterprises.4184.2.5.8.0:0 enterprises.4184.2.5.9.0:0"

Wed Sep 30 16:46:09 2020 .1.3.6.1.4.1.4184.2.0.2 Normal "Status Events" <server ip>- 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.13.73.67.79.80.50.52.49.53.72.48.65.72.70:ICOP2415H0AHF enterprises.4184.2.3.2.1.1.13.73.67.79.80.50.52.49.53.72.48.65.72.70.13.83.73.83.95.83.79.65.82.70.95.68.70.84:SIS_SOARF_DFT 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 16:46:09 enterprises.4184.2.5.8.0:0 enterprises.4184.2.5.9.0:0"

and criticals are coming in as criticals.

Wed Sep 30 16:52:43 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:52:43 enterprises.4184.2.5.8.0:0 enterprises.4184.2.5.9.0:0"


Wed Sep 30 16:55:13 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.84.50.52.49.53.72.48.65.72.70:ICOT2415H0AHF enterprises.4184.2.3.2.1.1.13.73.67.79.84.50.52.49.53.72.48.65.72.70.11.80.82.69.67.89.83.69.95.51.77.50:PRECYSE_3M2 enterprises.4184.2.5.1.0:IN13 enterprises.4184.2.5.2.0:4 enterprises.4184.2.5.3.0:DOWN, Interface is not operational- ERROR status for Connection. enterprises.4184.2.5.4.0:2020-09-30 16:55:12 enterprises.4184.2.5.8.0:0 enterprises.4184.2.5.9.0:0"

But the notifications log doesn't show the OK logs and also doesn't appear to be consistant regarding the information being received.

Verify that the SNMP Traps service has notification enabled for the OK and Critical status. If it is not setup for OK notifications, they will not show up in the Notification log.


Let's turn on external command logging and passive check logging on the Nagios server.

Edit the main nagios configuration file at /usr/local/nagios/etc/nagios.cfg and turn on the following options.
Save and restart nagios.

Wait for an OK trap and a Critical to be received and then get the /usr/local/nagios/var/nagios.log file and PM it to me.

Also, PM me the System Profile from the server.
To get your system profile. Login to the Nagios xi GUI using a web browser.
Click the "Admin" > "System Profile" Menu
Click the "Download Profile" button
Save the profile.zip file and PM it to me.

I can't have the service send an ok notification out since it would generate a ticket if that occurs. It is only configured for critical. Profile sent. logging commands were already configured.

Since the services do not generate Recovery notifications, you will not see them in the Notification logs and that is normal.

You should see them in the event log and the state history report.

Can you provide more details on what you mean by this?
"also doesn't appear to be consistent regarding the information being received."

I apparently have it working now. But the ticketing system team tells me they are not receiving notifications from Nagios. From my understanding I do see that notifications are being sent out to the three contacts. I tried to send the notification out manually and they received that. Any idea what might be going on? I am pretty sure I have the contact configured properly.

You can enable logging for the PHPMailer to see if you wind any errors.
https://support.nagios.com/kb/article/p ... g-820.html

Also, check the server you are relaying the emails through to see if it receives them and sends them to the users.

Lastly, check the email clients to and Spam filters.

Ok notifications are working. I recreated the contact as an account and all is working fine. Now the issue that I am seeing is that we were just alerted for an OK state this morning.



Mon Oct 5 08:16:10 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.12.73.67.79.80.50.52.49.53.72.48.65.72:ICOP2415H0AH
enterprises.4184.2.5.1.0:SR03
enterprises.4184.2.5.2.0:1
enterprises.4184.2.5.3.0:INIT - Server process loading definitions.
enterprises.4184.2.5.4.0:2020-10-05 08:16:10
enterprises.4184.2.5.8.0:7929857
enterprises.4184.2.5.9.0:7929857"


Screenshots of defined traps coming soon

Current Defined traps screenshot attached.

Lets enabling debugging in the snmptt daemon by editing the /etc/snmp/snmptt.ini file and changing the following from
to
Save the file and restart snmptt by running Make sure the debug file is created Then wait for a trap to be received by the xi server that should should be an OK and not a critical.

Then get the following files from the server and upload them to the post.

Ok. I have enabled debugging. Just gotta wait for the messages to come through.