[Nagiosplug-devel] RFC: New threshold syntax

[Vonnahme, Nathan]

> Max wrote:
> > On Thu, Mar 20, 2008 at 5:07 PM, Ton Voon <ton.voon at altinity.com>
wrote:
> >>  On 20 Mar 2008, at 19:39, Vonnahme, Nathan wrote:
> >>
> >>  >       1. we start by defining "normal" (OK), and assume
everything
> >>  > 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
nice.

*blush* gee, thanks.  


> > I am not sold on the value of having ranges have to state negative
or
> > positive infinity explicitly.  I think that should be optional but
not
> > required.   I understand from an implementation standpoint that
having
> > it manditory makes parsing arguments easier, though only slightly.
> >>From a readability standpoint, I think fewer people are used to
seeing
> > 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
marker:
load=ok(2,1.5,1.2)        # ok but the (implicitly -inf) lower limit is
ambiguous
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
she
> > 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?

--time=ok/0:3/seconds
--freespace=ok/300:inf/KB,warn/100:300/KB     
--load=ok/0:2,0:1.5,0:1.2/

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

--time=ok/0..3/seconds
--freespace=ok/300..inf/KB,warn/100..300/KB
--load=ok/0..2,0..1.5,0..1.2/

I like 
    --metric=ok/min..max/unit,warn/min..max/unit,critical/min..max/unit

the best so far.  It seems readable, writable and is pretty isomorphic
with the data structure, it's simple for the simple cases:
    --time=ok/0..2/
 and capable of the complex ones:
    --load=ok/0.7..2,0.7..1.5,0.7..1.2/,warn/0..0.7,0..0.7,0..0.7/

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:
    --metric=critical/outside,min..max/units


OTOH, biting the bullet and quoting the argument would allow a lot more
flexibility...
    --metric='critical(outside,min..max)units, warning(min..max)units'
    --metric='critical outside (min:max) units, warning (min:max) units'
    --metric=ok(min:max)
    --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.

-n