Concurrent Service Check Execution

[Marc Powell]

> -----Original Message-----
> From: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-
> bounces at lists.sourceforge.net] On Behalf Of David Knecht
> Sent: Saturday, September 08, 2007 2:21 PM
> To: nagios-users at lists.sourceforge.net
> Subject: [Nagios-users] Concurrent Service Check Execution
> 
> I'd like to force Nagios 2.9 to execute all service checks on a given
> monitored system *concurrently* (both in hard OK states as well as in
> hard non-OK states). My goal is to see how my services behave on a
> particular monitored system *at one single point in time*.
> 
> Having mentioned all this I assume that concurrent service checks as
> outlined above cannot be configured in both Nagios 2.9 and 3.0. Do I
> miss anything here? Is there any circumvention?
> 

My $0.02... The nagios scheduler attempts to monitor things as close to
their scheduled interval as possible no matter what's happening and
that's about all it promises. As you've noted, you have limited control
over when checks occur and that's only for initial scheduling. There are
no real workarounds other than having a single plugin execute multiple
checks and aggregate the results or using external scripts, executed
from (f)cron or other specific timing mechanism to submit passive
results.

> --> As a circumvention, it might be acceptable if service check A2
gets
> executed ~2-5 seconds after A1. Is it possible to enforce such a
> behaviour?

No, there is no built-in way to control the order in which checks occur
in any way whatsoever.

--
Marc

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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