[Nagiosplug-devel] RFC: New threshold syntax

Vonnahme, Nathan nathan.vonnahme at bannerhealth.com
Wed Apr 2 19:46:46 CEST 2008


> -----Original Message-----
> From: nagiosplug-devel-bounces at lists.sourceforge.net
[mailto:nagiosplug-
> devel-bounces at lists.sourceforge.net] On Behalf Of Max


> >  > check_tcp_states --finwait2 ok=0..50 --synreceived ok=0..100
> >  --or-conditions
> >  >
> >  > check_tcp_states --established ok=30...500 --timewait ok=0..200
--and-
> >  > conditions
> >
> >  I think it's intuitive when checking multiple values in one plugin
that
> >  the "worst" failure gets reported.  A mixed result of 9 OK, 1
warning
> >  and 1 critical should return CRITICAL.  If someone wants other
behavior
> >  I think it should be split into multiple plugin invocations.
> 
> I think I didn't explain myself clearly :).  Yes, the worst state
> always bubbles up as the plugin status, that is intuitive, I agree.
> 
> My point was that with the "OR" case either finwait or synreceived (in
> the example above) would trigger an alert if either went out of ok()
> range whereas with an 'and' they would both have to be out of range to
> trigger an alert.
> 

I guess I can't imagine why you would ever really want "AND"... if any
of the metrics are outside of the OK range you should get an alert.  But
I'm not really familiar with check_tcp_states so maybe I'm missing the
point of your example.

There's no reason a particular plugin couldn't implement an option to
AND things (or XOR) instead of OR them, but I don't think that's a
normal requirement so it wouldn't need to go in the default
arg/threshold handling routines or syntax definition.

-n








More information about the Devel mailing list