scheduling active checks against common resources

[Paul M. Dubuc]

Aamer Akhter wrote:
> Hello,
>
> Is there a way to get nagios to intelligently schedule checks where
> there is a dependency on a common resource to do the active check.
>
> For example:
>
>   service A, B, C cannot be done at the same time
>
>   service A on host X, cannot be done at same time as service B on host X
>
> Or are these better handled via passive checks?
>

This would be a very nice feature to have.  The only way I could see doing 
this with active checks is to have the plugins use a lock file.  But it's an 
unsatisfactory solution if you have several services in contention for the 
same resource.  If the plugin waits to get the lock, it may error on timeout 
and its scheduled check time relative to the other services probably won't 
change so some check gets locked out every time they are run increasing the 
execution time.  If instead the plugin exits with UNKNOWN when it's locked 
out, it will run again at the retry interval.  That will offset the next 
scheduled time so it might not get locked out again.  But, if it repeatedly 
gets locked out through all retries, it ends up in a hard state where a 
notification will be sent and it will only be checked again at the regular 
check interval.  This is probably not what you want to happen in this case.

------------------------------------------------------------------------------
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