scheduling active checks against common resources
Paul M. Dubuc
work at paul.dubuc.org
Tue Mar 1 16:58:06 CET 2011
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
More information about the Users
mailing list