Service scheduling

[Giles Coochey]

> 
> I have a checkstring service that kicks off every 10 minutes.  After
> failure it will retry every minute.  We're trying to track
> availability on some of our servers so this is its purpose.  However I
> noticed this morning that a host went down, I received a PING 100%
> packet loss alert, and shortly after within the same minute an alert
> that it couldn't find the HTTP string.  However, by 7:50 PING was ok,
> and HTTP didn't return ok until 8:00 AM.  If it's retrying every
> minute (or should be), why is there such a large gap?
> 

Normal Behaviour:

Scheduling During Problems 

So what happens when there are problems with a service? Well, one of the
things that happens is the service check scheduling changes. If you've
configured the max_attempts option of the service definition to be
something greater than 1, Nagios will recheck the service before
deciding that a real problem exists. While the service is being
rechecked (up to max_attempts times) it is considered to be in a "soft"
state (as described here) and the service checks are rescheduled at a
frequency determined by the retry_interval option. 

If Nagios rechecks the service max_attempts times and it is still in a
non-OK state, Nagios will put the service into a "hard" state, send out
notifications to contacts (if applicable), and start rescheduling future
checks of the service at a frequency determined by the check_interval
option.

http://nagios.sourceforge.net/docs/2_0/checkscheduling.html


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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