[Nagiosplug-devel] New threshold syntax - changes

Thomas Guyot-Sionnest dermoth at aei.ca
Tue Oct 13 08:35:13 CEST 2009


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

I talked about all these changes in the threads a while ago but I
received no comments on them. If you have anything against them please
speak now!

1. --th=metric={metric} instead of --{metric}:

Ok, this makes it a bit longer, but I believe it's a much clearer
separation between thresholds and other command-line arguments. Both
"--threshold" and "--th" would be equally valid. The list of metrics
could be printed in a table after the argument list, and could include
dynamic metrics for some plugins (i.e. based on the data being checked)
using a common prefix. Additionally it allow setting default parameters
by omitting the metric.

2. Making the "end" optional in range?

At one point it was suggested making the end parameter optional. The
current spec says the range must have bots start and end, which means
most threshold ranges will have to be like this (ex. for a 10 second
delay warning/critical):

10..inf

instead of just "10".


3. Clarification of the ok= level

Is is unclear how levels interact regarding the OK level. Here's what I
proposed (by "check" I mean to also return the value if within range):

1. Without OK range:
  a. check for critical range if specified
  b. check for warning range if specified
  c. return OK

2: With OK range:
  a. check for OK range
  b. check for critical range if specified
  c. check for warning range if specified
  d. return CRITICAL.



4. Separation of uom and prefix

In the RFC the "uom" parameter specify both the unit and its prefix.
This parameter has to be separated to prevent a parsing nightmare.
Therefore there should be:

  a. unit: unit of the data, useful (and valid) only when the plugin
doesn't knwo what is it (ex. check_snmp)

  b. prefix: this is the SI prefix for using the range values and
usually printing on the normal output as well (performance data should
be a double value and therefore shouldn't be affected by this as
precision is retained anyway). Should be valid everywhere with a default
value provided by the plugin where applicable. Ex.: M, K, m, KiB, etc..


Please let me know if you see any issue here...

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

iD8DBQFK1B+g6dZ+Kt5BchYRAtK5AJkBKhWWohyT7yc+Z+n910W39v8SvACg1D8r
O5IQn1S2h14yHpCAAFPD994=
=krRz
-----END PGP SIGNATURE-----




More information about the Devel mailing list