![nagios snmp trap receiver nagios snmp trap receiver](http://www.bic.mni.mcgill.ca/uploads/PersonalMalouinjeanfrancois/nagios-service-status-details-for-hostgroup-tripplite-pdus.png)
Now we create the configuration file for the 'snmptrapd' daemon. Startproc $SNMPTRAPD $OPTIONS -c /etc/snmp/nf -Lf /var/log/ OPTIONS="-On -p /var/run/snmptrapd.pid -M /usr/share/snmp/mibs -m ALL" # cp /usr/share/doc/packages/net-snmp/rc.snmptrapd /etc/init.d/snmptrapd Fortunately, there is a template in /usr/share/doc/packages/net-snmp. Although the daemon comes with the SNMP daemon package and is installed in /usr/sbin, no startup script has been put into /etc/init.d. Next, we configure the 'snmptrapd' daemon. Listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:31: Let's check what traps were send and if they are received on our trap sink server, using tcpdump:
#Nagios snmp trap receiver windows
Stopping and starting the Windows SNMP service will generate some. Now we can start sending our first test traps. Following good practise we configure a dedicated trap community (different from public) and add the SNMP trap server destination IP there. So, currently we are only interested in SNMP traps. I assume SNMP read access is already set up. Once installed, we go to "Start->Settings>Control Panel->Administrative Tools->Services-> SNMP Service->Properties". It is available in the normal Windows package (Add/Remove Windows Components) under Management and Monitoring tools.
![nagios snmp trap receiver nagios snmp trap receiver](https://nagios.fm4dd.com/howto/images/windows-reboot-monitoring-nagios-schema.gif)
On the Windows server, we need to have the SNMP service installed. The 'Sending' part: Generating SNMP traps from Windows This path is used in all examples below, please adjust it to your. Nagios had been installed into /srv/app/nagios. The following examples have been developed and verified unter Nagios 3.0.6 running on SuSE Linux Enterprise Server 10, receiving traps from Windows 2003 Server and Windows XP clients. Now, at least we will know for sure when they come back up. With the 'ping' being set to re-test after one minute for 2 more times to avoid sending false alerts, it was just recording one fail but did not send the necessary notification.Ĭlearly, passive 'ping' monitoring is not perfect, so a better way to monitor these pesky 'secret' Windows reboots is to make them send SNMP traps. It is a quite rare case, only one single Nagios 'ping' check failed. Only it happened so darn fast that it fell exactly in between the five minute intervals when Nagios sends its 'ping' checks to verify the system is up. One of the Windows servers (what else) rebooted due to a unknown cause (what else). One fine day it happened: Nagios missed to alarm us for a server going down.