Nagios Check Time Issue

Rus Hughes russell.hughes at gmail.com
Thu Feb 24 12:24:06 CET 2011


Hi,

I've been investigating an issue we have with Nagios Core 3.2.0 that
we're running on Redhat 5.4. We're being a bit ruthless and have
configured retry_check_interval and normal_check_interval to both be 1
on all hosts and services (20 hosts and 293 services).

We're seeing massive delays between checks getting run for services
flagged as DOWN, even though the box has little load (0.2)

Looking at the extended information page for a service that was DOWN
we're seeing events like this occur :

At 10:40 a service that was DOWN had a check that was scheduled to run
at 10:25 but still hadn't run
At 11:02 I refreshed the page for the Nagios check
Nagios had run the check and changed the service state to UP
The last check time was set to be 10:25 though
Even though the check actually ran between 10:40 and 11:02

Does anyone know why

1) Nagios is being 'lazy' when rechecking services marked as DOWN ?
We've configured retry_check_interval to 1 for all checks and theres
little load on the box and at most only about 4 Nagios processes
running at a time, so there are resources free to be used ..

2) Why Nagios is marking the Last Check Time to be the predicted Next
Scheduled Check time, even though the real time the check one is way
after? (Bug in Nagios?)

Thanks,

Rus

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
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