[Nagiosplug-devel] RFC: New threshold syntax

[Thomas Guyot-Sionnest]

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

On 19/03/08 05:10 AM, Ton Voon wrote:
> On 18 Mar 2008, at 13:30, Thomas Guyot-Sionnest wrote:
>> Can it be missed out when we're not specifying thresholds too?
> 
> Good point. Added.
> 
>> 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.).
> 
> We are already passing scientific notation in N::P (see separate  
> thread subject "Nagios::Plugin with scientific notation"), and that is  
> not in the spec.
> 
> But I agree that this is not the time to consider this, so I'll remove  
> the part about the perf data based on uom in the threshold.

Hi Ton,

It's not that I want to add fire on the subject, but given Andreas's
input and a discussion between Matthias and Holger on IRC, is seems like
you proposal is far from reaching consensus...

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

p.s.: here I'm thinking max/min alone would set both warn and crit
thresholds

(Hey, BTW there's also the binary prefixes:
http://physics.nist.gov/cuu/Units/binary.html)

To address Angreas's concern that people may want to alert critical if
the number of triggered warnings exceed something, we could even add
global (probably needs a better name, whatever) parameters:

check_stuff --metric1 warn_min=2,warn_max=5 --metric2
warn_max=8,warn_min=1 --metric3 warn_max=1500,warn_min=inf,outside
- --global max_warn=1

the global settings could also be used to set defaults for all other
metrics. So for example if I want all metrics to have min=0,outside I
just set them once and can optionally override them in individual metrics.

With this scheme we're not limited by the number of parameters either
because it doesn't really add complexity. We can even add new parameters
in the future without breaking backward-compatibility...


On a side note, maybe we could recruit users from the mailing lists and
make them test our thresholds using different methods. We prepare a
full, final specification for each method we want to test, give them
real-world situation (i.e. service x - needs to send an email (warning)
if metrix x goes higher than x, etc...) and ask them to write the
correct thresholds.

Then we can look which error they made, what they missed out and get
their comments about the complexity and clearness if the specifications.


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

iD8DBQFH4ONb6dZ+Kt5BchYRAt+/AJ9Q8Y2noguqsl3vNR+Okivv8QEnMQCgvXBL
hkXiXGniDlj4y5v1Lst3gx0=
=xOmb
-----END PGP SIGNATURE-----