[Nagiosplug-devel] RFC: New threshold syntax

Vonnahme, Nathan nathan.vonnahme at bannerhealth.com
Fri Mar 21 19:48:36 CET 2008

> Max wrote:
> > On Thu, Mar 20, 2008 at 5:07 PM, Ton Voon <ton.voon at altinity.com>
> >>  On 20 Mar 2008, at 19:39, Vonnahme, Nathan wrote:
> >>
> >>  >       1. we start by defining "normal" (OK), and assume
> >>  > else is CRITICAL
> >>
> >>  I'm still digesting what you've written, but I just had to say:
> >>  brilliant.
> >>
> >>  Defining OK ranges is going to be the biggest thing to aid
> >>  comprehension
> >
> > I agree with the usefulness of this and readability of this, very

*blush* gee, thanks.  

> > I am not sold on the value of having ranges have to state negative
> > positive infinity explicitly.  I think that should be optional but
> > required.   I understand from an implementation standpoint that
> > it manditory makes parsing arguments easier, though only slightly.
> >>From a readability standpoint, I think fewer people are used to
> > infinity explicitly stated and represented as a token than they are
> > having it be assumed by an expression.

I think in most cases 0 will be the obvious lower limit, rather than
negative infinity.  I was not really thinking of ease of parsing though,
but of mapping what the user assumes to the way the plugin actually uses
the value.  I think x:y looks like a range at first (and 100th) glance,
even when it's surrounded by other stuff, but (ignoring the
shell-breaking parentheses for the moment), compare the readability:

ok(10,bytes)      ok(10:10, bytes)
# the first only makes sense for a range of 1 value, which is almost
never what we want, so it wouldn't hurt to require the explicit 10:10

ok(10:,bytes)    ok(10:inf,bytes)    
ok(:10,bytes)    ok(0:10,bytes)

when it gets more complex, having both sides of the range also reminds
you what's happening, rather than looking like some sort of operator or
load=ok(2,1.5,1.2)        # ok but the (implicitly -inf) lower limit is
load=ok(:2,:1.5,:1.2)     # better (implicit minimums)
load=ok(0:2,0:1.5,0:1.2)  # best (explicit max and min)

> >
> > I do really like the readability of warn(), ok(), critical() and I
> > like having UOM as a suffix; I would not see any developer or plugin
> > writer, regardless of skill, getting confused about whether he or
> > has to put a UOM on infinity :).
> >
> > I would also make ok() optional as there are plenty of use cases for
> > plugins where just defining exceptions and having what is normal
> > implied by the exceptions is more intuitive.
> >
> > Your suggestion does use characters that would be interpreted by the
> > shell if not quoted.  How about using '-' instead and using UOM
> > suffixes?
> >
> > --result_size=ok-300:500b,warn-:300,critical-500:
> >
> > --free_space=warn-inf:300KB,critical-inf:100KB
> >
> For negative infinity, this would be "warn--inf:300KB" which looks
> kinda ugly and is hard to debug.

You could leave off the minus sign and assume that "inf" means negative
infinity if it's on the left side of the colon.

But, as you said, Max, the parentheses are a shell problem.  It's too
bad all the nice matching tokens you'd normally use to express a set--
()[]{}<> -- would require escaping or quoting.

> I'd go with equal-sign and recommend disjointed parameter/argument
> in all docs, like this
> --freespace warn=inf:300KB,critical=inf:100KB

  --metric warn=min:maxunit
since you don't have a separator between the range and the unit, it
still runs into the infinity units thing, which I don't like:
  --usedspace warn=300:infGB

what about //, which is used for grouping regexps?


but in those I feel the colon and slash visually compete when you're
trying to divide up the units, so what if we used .. instead of : for


I like 

the best so far.  It seems readable, writable and is pretty isomorphic
with the data structure, it's simple for the simple cases:
 and capable of the complex ones:

and for the rare case where you'd need to invert the range (rather than
specifying the OK range), you could add 'outside' inside the range
defining slashes:

OTOH, biting the bullet and quoting the argument would allow a lot more
    --metric='critical(outside,min..max)units, warning(min..max)units'
    --metric='critical outside (min:max) units, warning (min:max) units'
    --metric='ok outside min..max units, warning min..max units'      #
especially good for haters of the shift key

> And let "warn", "critical" and "ok" be specified by their shortest
> non-ambiguous string, for brevity, so that really long command-lines
> can be shortened to
> --freespace w=inf:2GB,c=inf:200MB
> uom must be specifiable along with the numerical option, otherwise
> the above thresholds would feel unnatural to specify. Note that

I think allowing uom on every ok/warn/critical definition is good, but I
don't think abbreviating them gains much-- in most cases if you use
'ok', you wouldn't need 'critical', and you're only saving 1 and 3 chars
on 'ok' and 'warn'.

BTW, I'll be on vacation next week so won't be able to answer.  I hope
your discussion (and/or coding) is fruitful though.


More information about the Devel mailing list