[Nagiosplug-devel] New Threshold Formats

[Thomas Guyot-Sionnest]

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

On 02/10/08 12:11 PM, Richard Edward Horner wrote:
> After my asking about the proposed new threshold formats, Thomas was
> kind enough to link me the latest available version of the RFC which
> is here:
> 
> http://nagiosplugins.org/rfc/new_threshold_syntax
> 
> Here are some quick thoughts. Some of these are just semantics but
> there are a couple things that appear to me to be errors but maybe I'm
> just not reading them correctly or maybe I need more sleep.
> 
> First range format is defined as:
> 
> "
> Simple ranges are of the format:
> 
> start..end
> 
> Where:
> 
>     * start and end must be defined
>     * start and end match the regular expression
> /^[+-]?[0-9]+\.?[0-9]*$|^inf$/ (ie, a numeric or "inf")
> ...
>     * alert is raised if value is inside start and end range
> "
> 
> And then examples are given like:
> 
> check_procs -C httpd --vsize ok=0..8096,warn=8097..16182
> 
> So, the regular expression appears to not match the examples and it
> also appears that it would match some things that do not fit the
> requirements. All the examples have two dots separating the boundary
> points and require both a start and end. The regular expression
> appears to make the end optional through making the dot (singular, not
> dual in the given examples) optional and then the second [0-9] is
> starred making it optional by allowing for zero characters there.

In the current syntax, thresholds default to exclusive and omitting the
end makes range start from 0 up to the defined end.

Since the new thresholds specify inclusive ranges, I believe the default
if we allow omitting the end is that the end becomes infinite. The most
common type of threshold is response time, so specifying i.e. "10" for
response time would be equivalent of saying "warn between 10 and inf.".
Does that makes sense?

I'll double-check other posts and clarify the RFC.

> Additionally, this regex does not allow for ranges that end with a
> negative value. It is conceivable that you might need to check
> something like:
> 
> -9..-4
> 
> Or perhaps more likely:
> 
> -inf..-100

This has likely been overlooked. The rexexp is just a standard way of
specifying what's allowed. I'll fix it.

> The other thing is semantic. It says "alert is raised if value is
> inside start and end range" but these range specifications are general
> including for OK so in the case of that match, an alert would not be
> raised. I think it should say, "range is matched/satisfied if the
> value is inside the start and end".

I'm not 100% sure what was the consensus on this (I'll verify in old
emails)... The idea of ok thresholds if fair - provide a way to only
specify which values are good. IIRC it should resume to this:

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.

As soon as I have time to verify old emails regarding this I'll clarify
the RFC.

Thomas

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

iD8DBQFI5/Tu6dZ+Kt5BchYRAgd2AJ4kdvi5NBKVJq1D+hL68UW5POrppwCdG3C9
jicfgatFnuOATfP7FzvAI2Q=
=fh9a
-----END PGP SIGNATURE-----