[Nagiosplug-devel] New threshold syntax (New thread)

[Thomas Guyot-Sionnest]

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

On 28/04/08 06:00 PM, Ton Voon wrote:
> On 5 Apr 2008, at 09:45, Thomas Guyot-Sionnest wrote:
>> Issue #1:
>>
>> The current specification of thresholds says the new system will use
>> "--{metric} {definition}" to define new thresholds. The definition  
>> is a
>> getsubopt(3) list . In regard to this method the new specification  
>> will
>> cause conflicts because some plugins already us similar longopt names
>> for thresholds that will be converted to the new format.
>>
>> Instead, I suggest using "--threshold" (or the shorter "--thresh" if
>> it's too long) to specify the threshold string, and add the suboption
>> "metric" to define which metric we're setting the threshold against.
>>
>> For example, to check the SSL certificate using check_tcp (that  
>> already
>> has "--certificate") I could use:
>>
>> check_tcp -H myhst -S --thresh  
>> metric=certificate,warn=<...>,crit=<...>
>>
> 
> Yes, I can see this would be less likely to conflict with existing  
> options. Can we say that the first getsubopt() can be assumed to be  
> metric= ? So your example would be
> 
>    --threshold certificate,warn=...,crit=...

Well, I don't this it would play well with getsubopt the *exact* way you
explain it but I see two ways we can make this work:

1. We pass a list of possible thresholds to the function and make them
act as a flag.
2. We allow one unparsed parameter (the metric) and return it as a char*.

I don't really like #1 (I just put it up before reading getsubopt man
page and finding the other alternative). Also do we want to allow
"default" metric when this isn't set? If we do then we won't be able to
set default options for other metrics like I once suggested.

Using either of these methods will make it valid no mater where it
appears in the line. i.e this would be valid as well:
    --threshold crit=[...],warn=[...],certificate

> The only thing complaint I have is that if "--threshold certificate"  
> is set without any levels, I wanted that to be a way of defining that  
> perf data for the certificate age was to be provided. This isn't  
> really a "threshold". But if no one objects loudly, I guess we can  
> consider that's an education thing.

Yes. I'd go for it. Also with --threshold if any other threshold
normally-displayed threshold isn't specified shoult is go away? (except
possibly when there's only one possible threshold in the plugin).

>> Issue #2:
>>
>> The specs should clearly state what uom is and also add uom_prefix (or
>> just prefix if it's preferred). The current meaning of uom should
>> actually be uom_prefix. Both would be optionnal.
> 
> 
> I don't really have any firm opinions about this at the moment, so I'm  
> happy to go with the majority.

I don't have strong opinions about the presence of unit/uprefix at all,
but if it's there I strongly believe that:

1. We should have separate unit and uprefix - trying to "be smart" and
parse a bundled unit/prefix will likely cause errors and problems.

2. There must be a way to specify the type (decimal or binary). If
people don't like using SI representations (KiB, Kib, etc) then we could
also go away with a "binary" and "decimal" getsubopt flag to force one
or the other. Also I guess the default should be plugin-specific...

> Thomas, can I suggest that you update the RFC at http://nagiosplugins.org/rfc/new_threshold_syntax 
>   and then we can close this shortly and proceed to the next stage. I  
> think the public discussion has been incredibly helpful, but I'm also  
> keen to draw a line under the talking and move onto the implementing.

Ok. I'll see if anything follow this email first...

Thomas






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

iD8DBQFIFoQE6dZ+Kt5BchYRApOzAJ9dTX3/SKPOiFiebrHyprT2A++zpACg1PzH
QXQJ32fOMMQZ2bmSlCG2S/I=
=8fJq
-----END PGP SIGNATURE-----