Search Exchange
Search All Sites
Nagios Live Webinars
Let our experts show you how Nagios can help your organization.Login
New ListingsDirectory Tree
snmp_remote_time_utc
Current Version
1.0
Last Release Date
2013-10-01
Compatible With
- Nagios 3.x
- Nagios XI
Owner
License
GPL
Hits
33006
Files:
| File | Description |
|---|---|
| snmp_remote_time_utc | snmp_remote_time_utc |
Meet The New Nagios Core Services Platform
Built on over 25 years of monitoring experience, the Nagios Core Services Platform provides insightful monitoring dashboards, time-saving monitoring wizards, and unmatched ease of use. Use it for free indefinitely.
Monitoring Made Magically Better
- Nagios Core on Overdrive
- Powerful Monitoring Dashboards
- Time-Saving Configuration Wizards
- Open Source Powered Monitoring On Steroids
- And So Much More!
The script needs a Linux current version of the date command to do all the time cleverness. Don't expect it to work with ancient Solaris, etc, date commands!
It runs on the nagios server and does an snmp get to a remote server to get the date and time, and compares against the date and time on the nagios server.
$ /usr/local/nagios/libexec/snmp_remote_time_utc -H zrhnora04a1 -C public -w 30 -c 60
TIME OK - Time difference = -5s|diff=-5
Here our UK nagios server is checking the time on a server in Zurich. It reports the Zurich server is 5 seconds slower than the nagios server. Since its below the warning threshold of 30 seconds its ok.
$ /usr/local/nagios/libexec/snmp_remote_time_utc -H zrhnora04a1 -C public -w 30 -c 60
TIME OK - Time difference = -5s|diff=-5
Here our UK nagios server is checking the time on a server in Zurich. It reports the Zurich server is 5 seconds slower than the nagios server. Since its below the warning threshold of 30 seconds its ok.
Reviews (1)
Thanks for the plugin, this is the best one!
Here are two remarks:
1. It doesn't work for Windows and ESXi as they don't provide zone information by SNMP.
2. Timeout should be changed from 60 seconds and 5 retries to 30 second and single retry in order not to get CRITICAL instead of WARNING:
--- snmp_remote_time_utc.orig 2014-11-14 11:56:09.000000000 +0100
+++ snmp_remote_time_utc 2014-11-14 15:01:55.360771200 +0100
@@ -53,7 +53,7 @@
getandprintresults() {
# Get local and remote time at the same time, so we can do a diff later. Local in utc.
- rdatestring=$( snmpget -v $version -t 60 -c $community $host HOST-RESOURCES-MIB::hrSystemDate.0 2> /dev/null | gawk '{print $NF}' )
+ rdatestring=$( snmpget -v $version -t 30 -r 1 -c $community $host HOST-RESOURCES-MIB::hrSystemDate.0 2> /dev/null | gawk '{print $NF}' )
ldate=$(date -u)
[ ! "$rdatestring" ] && exit_unknown
Here are two remarks:
1. It doesn't work for Windows and ESXi as they don't provide zone information by SNMP.
2. Timeout should be changed from 60 seconds and 5 retries to 30 second and single retry in order not to get CRITICAL instead of WARNING:
--- snmp_remote_time_utc.orig 2014-11-14 11:56:09.000000000 +0100
+++ snmp_remote_time_utc 2014-11-14 15:01:55.360771200 +0100
@@ -53,7 +53,7 @@
getandprintresults() {
# Get local and remote time at the same time, so we can do a diff later. Local in utc.
- rdatestring=$( snmpget -v $version -t 60 -c $community $host HOST-RESOURCES-MIB::hrSystemDate.0 2> /dev/null | gawk '{print $NF}' )
+ rdatestring=$( snmpget -v $version -t 30 -r 1 -c $community $host HOST-RESOURCES-MIB::hrSystemDate.0 2> /dev/null | gawk '{print $NF}' )
ldate=$(date -u)
[ ! "$rdatestring" ] && exit_unknown
