[Nagiosplug-devel] RFC: New threshold syntax

[Thomas Guyot-Sionnest]

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

On 18/03/08 05:39 AM, Ton Voon wrote:
> On 18 Mar 2008, at 06:13, Thomas Guyot-Sionnest wrote:
> 
>> The threshold format should possibly include a separator (I vote for  
>> the
>> comma, ",", the usual separator for arguments) since some plugins
>> expects multiple successive thresholds (like check_snmp). Those  
>> would be
>> only accepted by a 2nd function that would return an array of  
>> thresholds
>> struct. Omitting thresholds would be allowed the usual way (if I get  
>> it
>> properly) with a slash and optional uom (ex: "/,20:/30:k,/M"). If the
>> regular function is used the thresholds would be rejected.
> 
> I agree about the use of a comma separator. I was deliberately not  
> trying to overcomplicate this, but I've added a note in for future.

Thanks. I believe it shouldn't be in the actual specs (or maybe just a
note about it), but we should provide that facility to plugins and it
would be documented in their --help output.

>> *** Added after reading some more ***
>> I thought the / was always required. Your check_http example isn't  
>> very
>> clear if you specify warning or critical thresholds.
> 
> Good point. I've added a sentence that says that the / can be missed  
> out if you are specifying criticals only.

Can it be missed out when we're not specifying thresholds too?

>> I believe uom/prefix for controlling the unit used for printing is a
>> good idea but:
>>
>> 1. we should define what is allowed. Should probably be a subset of  
>> this:
>> http://physics.nist.gov/cuu/Units/prefixes.html
>> 2. Do we allow base8 units (Ki, Mi, etc)?
>> 3. Do we allow a unit after the prefix? I think it's metric- 
>> specific, so
>> I wouldn't think so (despite your examples). If yes and 2, how do we
>> specify a 'i' unit? what if the unit you want is a valid prefix?
>> 4. I believe uom should only affect the plugin output. The performance
>> data should be as precise as possible, ideally in scientific  
>> notation. I
>> also think it shouldn't change, because parsers would then need to  
>> find
>> the uom to properly  See my check_memory plugin in nagiosexchange for
>> example.
> 
> I thought about the uom late yesterday, so I guess it could be half- 
> baked :)
> 
> I'm thinking that there would a strict list of uoms for conversion.  
> The physics link looks like a decent list. I think there's something  
> in the gnulib too for "human readable" values. I don't think this  
> needs to be nailed at the moment.
> 
> However, whether the perf data is altered or not does need to be  
> agreed. I guess you are saying that the perfdata should always be in a  
> specific unit (say, bytes for disk space), whereas I was thinking that  
> the units could change to what a person thought was more readable  
> (though changing would affect existing data stores).

Moving to scientific notation would require making sure everyone will be
able to cope with that, so even if we want that I'd say 2.0, and even
then possibly a compile-time option. OTOH the advantage is that you get
consistent output; if could likely fix some problems we've had so far...
So I think we should keep them like they are for now (ms, bytes, etc.).

Arguably, with scientific notation you don't loose precision when you
change units, but why should the perfdata unit change? Let's say I have
disk ckecks showing space in megs. One day I decide to print them in
Gigs for clarity, will I have to reset all my graph that stored data in
megs so far? On the graphing side the conversion is done automatically
so it doesn't matter what units they're in.

BTW check_disk is a counter-example of what we should do. It rounds the
result to megs, so when you look at your graph it's very ugly: flat
lines and big jumps.

> So what do you think the guideline should be? A plugin should have a  
> base unit for all its perfdata? (bytes? seconds?)

The base-unit should be provided by the plugin istelf. There could be
some exceptions like check_snmp and check_nt but I think it's best to
let individual plugins deal with that.

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

iD8DBQFH38QA6dZ+Kt5BchYRApnRAJ9BUQXDKBfHaCWwbspHpB+a2+ucJgCggYQT
gTDGyc5eGRcZ1dKVTh108Bc=
=WZi0
-----END PGP SIGNATURE-----