Switching to passive checks instead of active ones?

[Ivan Fetch]

HI Holger, thanks for your reply,

On Fri, 5 Oct 2007, Holger Weiss wrote:

> * Andreas Ericsson <ae at op5.se> [2007-10-05 10:42]:
>> Ivan Fetch wrote:
>>>     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?
>
> We use NSCA for a large number of service checks (we don't use NRPE) and
> it works just fine for us.
>
>> 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.
>
> You do get that logic, you can specify max_check_attempts just as for
> active checks.  You just don't get a retry_check_interval different from
> the normal_check_interval unless you implement it yourself.  For us,
> that's not a problem, as we don't want a different retry_check_interval
> anyway (for most checks, we submit check results once a minute).  But if
> you rely on this Nagios feature, that's a real drawback of NSCA, yes.

    Good point.  We do use retry_check_interval in some cases, but it's not 
strictly necessary.  If a "it's fixed" state and notification are 
important enough, and desired before the next natural check, an admin 
could always run the passive check manually.


Thanks again,

Ivan.


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