randomize a service's check interval

Jaden Bentley jaden.bentley at gmail.com
Fri Jul 2 01:56:25 CEST 2010


Hello,

One of the services we monitor is a web server which we've installed bot
detection on.  The bot detection works by looking at the standard deviation
of requests from a specific host.  We don't want our own monitoring to get
blocked by our bot detection script, and for a variety of reasons, we don't
want to deal with putting in exceptions in our bot detection system.

We used to monitor with a manually written script.  It was easy then: it ran
in a loop, and after each check, it would sleep for 5 minutes plus another
0-300 seconds, with the specific number of seconds chosen at random.

We're having trouble porting this into our shiny new nagios monitoring
system.

The only idea I've had so far involves changing the service check interval
to something large (say 60 minutes), as a 'fallback' in case of failure, and
then having the service check itself re-schedule itself by sending nagios a
command.  I'm not sure that would work and it seems pretty ugly and I'm not
sure if it would be that easy to implement (mostly because I haven't worked
with manual nagios commands before).

Can anyone think of a better way?

Thanks in advance,

Jaden

-- 
Jaden Bentley
jaden.bentley at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20100701/c6204f8b/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
-------------- next part --------------
_______________________________________________
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