[Nagiosplug-devel] RFC: New threshold syntax

[Thomas Guyot-Sionnest]

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

On 20/03/08 08:31 AM, Max wrote:
>>  Well, if you want something like that why not making it like my
>>  suggestion which:
>>
>>  1. is a bit clearer: just like your example but using name=value pairs
>>  instead of values alone
>>  2. Is a standard way of specifying parameters, and is parseable using
>>  standard libraries.
> 
>>  Well, if you want something like that why not making it like my
>>  suggestion which:
>>
>>  1. is a bit clearer: just like your example but using name=value pairs
>>  instead of values alone
>>  2. Is a standard way of specifying parameters, and is parseable using
>>  standard libraries.
> 
> --threshold name=cpu,type=warn,min=0,max=80,inside
> 
> uom_prefix=Ki,uom=b
> 
> This certainly is very readable, is there a need for uom or
> uom_prefix?  Isn't it as maintainable to use suffixes on min and max
> to ask for types and a little less typing
> 
> Instead of
> 
> --threshold name=cpu,type=warn,min=0,max=80,oum_prefix=Ki,uom=b
> 
> We get
> 
> --threshold name=cpu,type=warn,min=0KB,max=80,gt

The former is easier to parse. uom shouldn't be needed in most cases
because the plugin knows what it gets, and uom_prefix is optional,
letting the plugin choose what prefix is best. Also mixing uom and
uom_prefix it risky because you could end up with corner cases where
there's no way to determine what is uom and what is uom_prefix (this is
especially true with 2-byte prefixes like Ki (kibibytes) and the fact
that uom_prefix is optionnal).

> If min or max specifies a suffix, that becomes the type .. if both
> specify suffixes that don't match, throw an error
> 
> The thing I like about using --warning and --critical still is that
> the focus of a threshold is what kind of alert it will trigger as that
> is the focus of a threshold, yes? :)  using that and integrating your
> style we would get
> 
> --warning name=system,max=90 --warning name=nice,max=99 --critical
> name=system,max=100
> 
> and if we use the threshold type as the argument then we can eliminate
> the name= part and get
> 
> --warning system,max=90 --critical user,max=95
> 
> which can then lead to complex conditionals if needed, still easy to parse
> 
> --warning system,max=80,min=0,range=inside,AND,user,max=80 --critical
> system,max=98,OR,user,max=98

I agree that would be great, but there's no easy way to keep backwards
compatibility if we re-use -w and -c. Ideally in two different big
release we should first add support for the new thresholds format so
that people could change their config to the new format, then remove
support for the old one.

Considering that the transitional release will fill in the same
threshold structs, we could possibly write a "reverse thresholds"
function that allow printing thresholds in verbose mode, so that users
could just run their plugin in verbose mode to find the new argument format.

> If UOM is assumed to be at the end of a min or max (if both are
> specified and do not match, the library would throw an error) then we
> reduce the fields needed.
> 
> and this way the only time a condition type has to be specified is
> when a min and max are present
> 
> this is all still much more verbose than just using RPN :), parsing
> RPN is a simple matter and there are lots of libraries available to do
> that
> 
> --warning system,90,gt,nice,90,gt,AND
> 
> To me the RPN style is easy to read and minimizes typing and the
> specification is simple

I came across this format with RRDTools, but I don't know many people
who actually know it. Even after having built a few RPNs I'm still
confused when I come across complex ones.

IMHO using RPNs will only increase the gap between "power-users" and
normal users. I believe there's many people that are very comfortable
with RPN because they learned it at school, while for all the others
it's something they'll likely never fully understand.

> SPEC = THRESHOLD1,THRESHOLDN,boolean
> THRESHOLD = metric,number[uom],[number[uom]],conditional
> 
> Another idea is to not use RPN but a similar style
> 
> --warning system,gt,90
> 
> --warning system,gt,90,AND,user,gt,90
> 
> Similar style and gets rid of the RPN while avoiding special
> characters that could be misinterpreted by shells, including spaces

Then again you miss out the point of using RPNs or option-strings. I
believe a better approach would be the obviousness threshold ranges. Any
range can trigger an alert and multiple non-overlapping ranges can be made.

An alternative to the min and max could be a simple range too. I.e.:

name=cpu,warn=0:90,outside

or(since cpu % can't be under 0 anyways):

name=cpu,warn=:90,outside

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

iD8DBQFH4mrc6dZ+Kt5BchYRAob7AJ45oxuaZFnE998v1F+BTcDq61MoZQCgtSh3
I3QDZKSuGKXkSdSvqWJpemU=
=3odp
-----END PGP SIGNATURE-----