Switching to passive checks instead of active ones?

[Andreas Ericsson]

Ivan Fetch wrote:
> Hello,
> 
> 
>     I'm wondering whether anyone has used send_nsca as a primary 
> "transport" for service checks, and has any experience and 
> recommendations?
> 

I'm sure they have, as that's what it's primarily intended for.

> 
>     The plan is to
> 
>     1. Run a script from cron, which iterates through a list of 
> checks (plugins to run, with parameters), and runs each check.  There 
> would need to be a timeout mechanism, to reap checks which hang - does 
> anyone have something they use for this with send_nsca (not all plugins 
> have builtin timeouts)?
> 

I should think not. Besides, running checks from cron will lose you the
fine ability to do re-checks on temporary errors.

>     2. Each plugin is run via a wrapper script (nsca_wrapper) which runs 
> the plugin and passes the results to send_nsca.  IF send_nsca returns an 
> error, the wrapper script logs to the local syslog.  I'm starting with a 
> wrapper script from here: 
> http://www.nagiosexchange.org/Check_Plugins.21.0.html?&tx_netnagext_pi1%5Bp_view%5D=980
> 

Make it a wrapper C-program and you'll have excellent control over checks
that time out.

>     3. Nagios' freshness checking will alert us if Nagios stops hearing 
> from any of these passive checks.
> 

Yup.

> 
>     Some of the motivations for switching to this method for running checks 
> are:
> 
>     * System logs are not cluttered with frequent SSH logins by Nagios
> 

You can disable that, I think. Or perhaps it was some patch I made for a
customer who didn't want that either. I'll do some research.


>     * Thresholds for checks (disk space percentages, mail queue volume) are 
> moved to the client, not defined in Nagios checks - some
> admins like the ability to adjust these locally
> 

That option is still available though, provided you either compiled nrpe
without support for accepting arguments, or if you disable them in nrpe.conf.

> 
>     I'm looking for folks doing something like this, or reasons why this 
> might be a particularly bad idea.  Perhaps Nagios triggering checks 
> has so much sanity built in, that moving checks to the 
> push-to-Nagios model is a bad idea?
> 

It's not a particularly bad idea, but you'll have to accept that you don't
get nagios' "check max_check_attempts times before sending alerts" logic,
unless you implement it yourself. In other words, the number of false
positives will most likely go up.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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