[Nagiosplug-devel] New threshold syntax - changes

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max wrote:
> After working with a living larger system with 10-12 Nagios
> configuration users / developers, I am coming around to Richard's view
> as well.
> 
> We have made very memory efficient and process efficient APIs /
> frameworks to use with nagios for writing remote checks in perl using
> Net-SNMP or a custom perl agent I wrote, but in the end what our users
> want and use that most is what is 1) easy to use 2) quick to implement
> and 3) minimizes the amount of hard-coded configuration work in the
> shared nagios configuration tree.
> 
> At our company, one of our teams' jobs is to make our nagios instance
> as self service as possible; many of our users are experienced SAs who
> have not used Nagios before, so we try to make our thresholds easy to
> read and use; I would not want them to have to use this very succinct
> but hard to remember notation.
> 
> We have moved forward with a bash like notation:
> 
> -w metric1,gt,10:metric1,lt,20:metric2,eq,14
> 
> we default to 'or' logic but would be easy enough to add and if it is
> requested .. has not been yet so i am not going to implement that
> until it is wanted.
> 
> I know my notation was slammed on list for a number of reasons and
> that is fine :), I am not suggesting it as a Nagios standard,  but it
> is easy for our users to pick up and remember, it is implemented in
> the module Nenm::Utils which is available online.
> 
> So I am all for having guidelines but after working with a larger
> group of nagios users / developers I have changed my point of view ..
> easy to learn and remember and use with more typing is better than
> succinct and short to type as far as maintainability, accessibility,
> and wide acceptance.

I wouldn't mind allowing this kind of ranges definition (RPN-like
syntax); it's very easy to add other range specifications using
different label tags. You could have wrpn= and crpn= for example
however in the current spec you can't bundle multiple metrics together
like you did above.

If people want bundling, we could allow something like this... I don't
like that much though, and I don't believe it's really needed since in
most case a single metric is sufficient (it's not like we'te really
saving speed here - it takes much more time to get the thresholds right
than to write them down anyway):

- --th=metric=metric1;metric2;metric3,warn=range1;range2;range3,crit=...

Don't forget getsubopt() don't allow equal signs and spaces so your
RPN's will require a non-standard syntax


That reminds me, I believe the spec talks about possibly using commas to
 specify multiple ranges. Besides the fact that it conflicts with
getsubopt, I personally believe a much better approach is to allow
repeated statements, i.e.:
warn=3..3,warn=5..5
Would define values 3 and 5 as warning.


Thanks for your feedback

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrUv7sACgkQ6dZ+Kt5BchapSwCfeHUJqJapICtoCoc3N2QgaZEb
bWoAnRJpvBVjdQXdmr6pSpF49WVb/hEC
=DXQb
-----END PGP SIGNATURE-----