[Nagiosplug-devel] RFC: New threshold syntax

[Ton Voon]

On 18 Mar 2008, at 06:13, Thomas Guyot-Sionnest wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17/03/08 05:15 PM, Ton Voon wrote:
>> Hi!
>>
>> I tried to get this through last year, but I don't think a conclusion
>> was reached so I'm going to try again now!
>>
>> This is a proposal for a new threshold syntax. My motivation is  
>> that I
>> have to update check_procs based on a customer's requested use for  
>> it.
>> I'd like a generally applicable syntax, so that there is maximum code
>> reuse and consistency.
>>
>> The proposal is here: http://nagiosplugins.org/rfc/new_threshold_syntax
>>
>> I've decided to use the website as this can be the master document. I
>> plan on updating it based on people's comments. Hopefully it will not
>> require too many alterations!
>
> Thanks Ton,
>
> It looks great, but I have a few comments:
>
> 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.

> *** 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.


> 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).

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

> It would be nice to have another prefix (that goes before, after or
> without the caret) to specify whenever the specified values should be
> alerted on or not (inclusive vs exclusive)... Maybe a pound (#).  
> Just I
> suggestion - I'd personally use that sometimes.

That screams "next phase" to me!

> I dislike the choice of inf or colons to denote infinity. I'd prefer  
> we
> stick on either one of them.

There was a need in the current range definition to have infinity  
because ":5" was assumed to be "0:5". However, since we are now  
defining the range "all the way to the left" and "all the way to the  
right", we can drop +-inf. I'm keen on delivering something based on  
this, so I'll remove with a note.

Ton

http://www.altinity.com
UK: +44 (0)870 787 9243
US: +1 866 879 9184
Fax: +44 (0)845 280 1725
Skype: tonvoon