Possible bug in Nagios 2.12?

eponymous alias eponymousalias at yahoo.com
Wed Apr 8 08:20:38 CEST 2009


> > I'm not seeing anywhere that
> > (event_list_low = event_list_low->next)
> > unless the event actually runs.
> 
> That's correct, although the loop is broken out of if:
> * The check shouldn't be run right now due to global
> options
> * The check shouldn't be run right now due to temporary
> setting
> 
> However, if the check can't be run immediately > due to too many checks running at that moment,
> or due to the check not being parallelizable
> and *any* other check is running, the only
> sensible thing to do is to sleep 1 second
> and then try again. This is what Nagios does.

Ah, no.  The really sensible thing to do would
be to wait only until all the blocking checks
are done (either just one of "too many", or
all other checks in the parallelization case).
Sleeping for a full second regardless of when
the blocking checks complete can waste time
between when the next plugin could run and
when it actually does.  And with enough checks
introducing these extra arbitrary delays, the
overall latency for the full set of checks can
easily creep up.

Whether it would be simple to make that happen
in a particular software architecture is a
separate discussion; I'm just pointing out
the design issue here.



      

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com




More information about the Developers mailing list