New Module IDEA

[jeff vier]

On Mon, 2004-03-22 at 19:17, Josh wrote:
>   I love the work-around idea you've got going there. Can we do that?

Here is the new version of the plugin.
A few little bug fixes, and now, you can append a -A or --checkall
argument and it will parse all URLs (not stopping on bad ones) and write
any bad urls to a log file defined by -B/--bad-url-file (defaults to
/usr/local/nagios/var/bad_url_log, which you can change in the script
via the DEFAULT_BAD_URL_FILE variable)

Now you just have to have an event handler email you the contents of the
BAD_URL_FILE (note that it won't exist if there was only one bad URL!)
upon w/c/u states and you're good to go.  I'm sorry it's forced to do a
double-emailing, but I can't see a better way to do it and not have to
email on every check failure (thus ignoring max_check_attempts,
notifications_enabled, etc).

You might experiment with making its service's notifications_enabled set
to 0, and ONLY sending out the the email via the event handler, then
you'll get all the bad URLs in an email only.  In theory.  I think. :)

Something to consider:
If you're going to run multiple 'check_http_many' services, you will
probably want to unique-ify your BAD_URL_FILE variable that so they
don't fight.  Maybe in your command definition set it to, for instance, 

command_line	$USER1$/check_http_many /path/$ARG1$ -A -B
/path/bad_url_log.$ARG2$ -H someserver.domain.com

and pass something unique in each service def's ARG2


Let me know if you need help with the event handler.

> On 22-Mar-04, at 10:45 AM, jeff vier wrote:
> > That doesn't help us, though.  I can't have the plugin email you on its
> > own and still adhere to the notification_interval - it's either one or
> > the other (and thus either it emails you on every check (except all-OK
> > ones) OR it nagios handles it and you only get the one line of info).
> > There's no way the plugin knows the states of the service it is being
> > called to watch, so there's no way it can only email you only when
> > nagios would have emailed you (does that make sense?)
> >
> > A good work around option might be something like this:
> > - The check runs through *all* URLs
> > - The first baddie is returned in email with a note like '+3 more' or
> > something (if there is more than one)
> > - the plugin writes the extras to a log file
> > - configure an event handler to send the log file to you separately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_http_many
Type: text/x-sh
Size: 7237 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/users/attachments/20040323/3c9828cf/attachment.sh>