Best use of check_ntp_time plugin

Andreas Ericsson ae at op5.se
Wed May 19 15:43:37 CEST 2010


On 05/19/2010 03:01 PM, Deborah Martin wrote:
> Folks,
> 
> We've had a problem recently where the timestamp has been drifting
> hours ahead on the VM box running nagios. (v3.2.0 with SLES 10 SP2)
> 

Don't run any kind of scheduling engine inside a VM. It's like
begging for Mr Murphy to come kick you in the nuts.

> As a consequence I'm setting up the plugin check_ntp_time to ensure
> that the clock on the nagios monitoring box doesn't drift too far
> ahead (or behind.) without telling us so that we can do something
> about it.
> 
> For the threshold for warning and critical, I was thinking of -w 30
> and -c 60 - would this seem sensible ?
> 

5 and 10 seem far more sensible to me.

> And also, if the alert did become critical because the drift was
> greater than 60 seconds what would be a sensible way of fixing this
> without human intervention. I thought that an event handler might be
> the way to go here that would restart the ntpd daemon.
> 

You'd be better off with a cron'ed script setting the clock with
ntpdate every 5 minutes or so. That's usually not long enough time
for there to be a major clockskew. The problem with ntpd on vmware
is that the host system largely ignores the clock-tick speedup and
slowdowns that ntpd issues, so ntpd has no effect what so ever.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------

_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list