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

[Thomas Guyot-Sionnest]

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

I haven't had a single reply to this. Any objections or comments?

During a chat in IRC it was suggested that unit would make a better
replacement to uom. Also uprefix could be used instead of uom_prefix.

Additionally, in regard to those who prefer the --<metric> <threshold>
syntax, we could make that as a second pass; so we would do:
1st minor release with --metric support
2nd minor (or 1st major) release removing legacy thresholds support (-w,
- -c, etc)

NB: To be clear, by minor I mean 2nd number like 1.5, 1.6.

Thomas

On 05/04/08 04:45 AM, Thomas Guyot-Sionnest wrote:
> Hi,
> 
> My intent is to provide my suggestion on the latest RFC specification
> (modified on 4 Apr 2008 - 5:26pm) so to make thing clear I'm starting a new
> thread. These suggestion have been discussed a bit on the #nagios-devel
> irc channel and this email will formalize them.
> 
> Everithing in thes imail relates to the "Thresholds" section, although
> the proposed changes will reflect in many of the subsequent sections.
> 
> http://nagiosplugins.org/rfc/new_threshold_syntax#thresholds
> 
> 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=<...>
> 
> The plugin --help output would print a table of all supported metrics,
> descriptions, etc.
> 
> 
> 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.
> 
> uom shouldn't be needed in almost all plugins because the plugin already
> know that the thresholds is. It would be useful for checks that are more
> generic like check_snmp and check_nt as they can retrieve value they
> have no knowledge about. uom is generally a single character (although
> it can be more than one) that defines the type of value. It is used in
> printing the plugin output _and_ the performance data.
> 
> Some example of uom units:
> http://physics.nist.gov/cuu/Units/units.html
> http://physics.nist.gov/cuu/Units/outside.html
> 
> 
> uom_prefix (or prefix) defined a multiplier for:
>   a. defining the threshold level (the value are multiplied/divided by
> the prefix)
>   b. printing the retrived value in the _plugin_ output.
> No matter what prefix is used the performance data should remain the same.
> Plugins may define a default prefix fro any threshold. Prefixes are
> strictly defined by the prefix tables found on these pages:
> http://physics.nist.gov/cuu/Units/prefixes.html
> http://physics.nist.gov/cuu/Units/binary.html
> One cannot "invent" new prefixes as the plugin needs to know what the
> multiplier/divider is.
> 
> For example, to send a warning when a page size isn't between 60KiB and
> 80KiB with check_http, one could use:
> 
> --threshold metric=size,ok=60..80,warn=inf..inf,uom_prefix=Ki
> 
> Note that uom is not defined - check_http know it's in bytes (B)
> 
> The plugin would return the data in KiB. ex.:
> HTTP OK HTTP/1.1 - 70.99KiB in 0.018 seconds
> 
> However the perfdata will stay in bytes:
> time=0.18082s;;;0.000000 size=72694B;61440;81920;0
> 
> 
> 
> This new specs seems very good to me and outside the aforementioned
> issues I fully support the latest RFC.
> 
> I also wish to give special thanks to everyone who participated in the
> discussion and helped make the new syntax better and simpler.
> 
> 
> Thomas

- -------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________________
Nagios Plugin Development Mailing List
Nagiosplug-devel at lists.sourceforge.net
Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null



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

iD8DBQFIDnPL6dZ+Kt5BchYRAoMMAJ9MSNadOOkhpo/jnbTg/YGGc/PnrACbBeXH
C0O3TY1nMb29h6eF6x7Q+ac=
=HUNy
-----END PGP SIGNATURE-----