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

[Ton Voon]

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

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.

> The plugin --help output would print a table of all supported metrics,
> descriptions, etc.

+1. I can see that there would be some library functions to "register"  
that a fixed list of metrics are available from a 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.

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.

Ton

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