[Nagiosplug-devel] RFC: New threshold syntax

[Ton Voon]

On 19 Mar 2008, at 09:56, Thomas Guyot-Sionnest wrote:

> So I just got a totally different idea: what if we make the  
> thresholds a
> set of parameters that can be processes by getsubopt?
>
> I haven't developed much this idea, but I'm thinking something like:
>
> check_stuff --metric  
> min=2,warn_max=5,crit_max=7,outside,uom_prefix=Ki,uom=b

One way of looking at this problem is this: how can I fill in the data  
structure?

Currently ranges and thresholds are defined as such (lib/utils_base.h):

typedef struct range_struct {
         double  start;
         int     start_infinity;
         double  end;
         int     end_infinity;
         int     alert_on;               /* OUTSIDE (default) or  
INSIDE */
         } range;

typedef struct thresholds_struct {
         range           *warning;
         range           *critical;
} thresholds;

We'd need to add in a uom into the thresholds struct. Maybe add a char  
*name to thresholds as well. Range might need an "include_endpoints"  
field.

With a slight amendment to your idea, we get:

check_stuff --threshold name=time,warn=5:,crit=10:,uom=b

So --threshold is the "standard" option to set thresholds. The name=  
sets which threshold.

However, I can't see a simpler way of defining the range. Your example  
of 'outside' doesn't specify for warning or critical (I guess you  
could do outside=warn, but then that doesn't scale with the (future)  
list of ranges idea).

In other words, we still need a concise way of specifying range.

So this problem can be broken down into:
   - how to specify ranges
   - how to specify thresholds

I'd argue that the range is best done as [^][start]:[end] (with maybe  
a change of the "outside" character, maybe a character to signify  
inclusion of endpoints).

The other option for ranges is Max's mathematical notation:

(I'm assuming the following rules:
   - the following operators are fine: <, <=, >, >=
   - the following syntax is fine (where Z is some number): {operator}Z
   - if you are defining a range of values (where Y and Z are  
numbers): Y{operator}x{operator}Z
   - a comma acts as a list in an AND fashion
)

So:
   <=5 equates to :5
   1<=x<=3 equates to 1:3
   1<x<3 doesn't have an equivalent (because of endpoints)
   <=1,3<= equates to ^1:3
   <1,3< doesn't have an equivalent (because of endpoints)
   >=10 equates to 10:

My feeling is that whatever is chosen, (1) there's an education issue  
that needs to happen, (2) someone is going to hate it. I actually  
think we might be able to support both these syntaxes, because as long  
as the parser breaks it down into the range struct, code at the plugin  
level should just work.

Then the options for defining threshold are (ignoring uom for the  
moment):

   1) --threshold-time=crit_range/warn_range
   2) --threshold name=time,warn=range,crit=range
   3) --threshold=time -w range -c range

I like (1) and (2) because it is all stored in "the same place" - ie,  
one parameter defines 1 threshold. (1) is a bit more consise than (2),  
but (2) has benefit of extensibility. However, I actually like the  
look of (3), though it is harder to parse in the options handling code.

Is it voting time yet?

Ton

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