[Nagiosplug-devel] New Threshold Syntax

[Páll Guðjón Sigurðsson]

Hey William,

Cool project you have going on! My humble two cents to follow.

We implemented same RFC in pynag (python modules for nagios related stuff). We also hit some walls and wanted to make modifications. Unfortunately, it's been a long time since it was written and author of the proposal is not answering my emails on the topic.

I am not sure if there is a lot of motivation among the nagios-plugins folks to implement this RFC, so i wonder if third party libraries like you and should coordinate on it anyway ?


On the topic of multiple thresholds with different suffix (i.e. adding -rate to a threshold) i say, the RFC should NOT cover that situation and its up to the plugin developer to create multiple differently named metrics for this (my two cents)

Mathematical syntax is already an established standard, but i agree that easy shell expansion is more important.



Cheers,
Palli



----- Original Message -----
From: "William Leibzon" <william at leibzon.org>
To: "Nagios Plugin Development Mailing List" <nagiosplug-devel at lists.sourceforge.net>
Sent: Monday, July 1, 2013 10:13:49 PM
Subject: Re: [Nagiosplug-devel] New Threshold Syntax

Hi,

I appreciate the comments, my replies to them are further below.

And seeing as there is some interest in this and it should be better
documented, I've decided to extend existing doc and put into wiki
which is open to pubic editing. The wiki is on my github copy of
nagios-plugins main repository:

  https://github.com/willixix/nagios-plugins/wiki/New-Threshold-Syntax

Please check it out and tell me what you think.

Above in addition to extensions I mentioned in my first email (using
':' in addition to '=', adding 'perf' and 'absent' keywords), I also
added several additional keywords:

name:{name}  - this is used to specify threshold that would apply to
specific named attribute, this could be specific process name in case
of check_procs or it could be specific partition for check_disk, etc.
Note - I should extend set of symbols allowed there, somebody please
comment what it should be.
label:{label} - this is used to re-label named attribute for purpose
of displaying it in status line or in perf
awarn:{range], acrit:{range} - these add capability to specify that
multiple warn (or critial) threshold levels must all match i.e. its
logical AND rather than logical OR which is default if multiple warn
and crit appear. I need this for combining multiple types of checks on
same metric.

This spec is what I intend to implement in my perl library (and most
of this functionality is already there now) and what will eventually
be used by majority of my plugins. And hopefully other plugin library
writers who were willing to implement proposed format would follow
with these extensions as well - overall it is still same as original
proposal. And I'd be willing to create ABNF and more formal spec doc
(similar to RFC, and I have participated in IETF and written drafts)
if people want to go that way.

On Sun, Jun 30, 2013 at 10:08 AM, Jochen Bern <Jochen.Bern at linworks.de> wrote:

>>> Why not use the "mathematical syntax"? For this we need [] instead of ()

() and [] are in fact correct mathematical notation for open an close
interval which also allows for mix of those brackets

>>> Examples:
>>> [1..5] means 1 ≤ x ≤ 5
>>> [1..5[ means 1 ≤ x < 5
>>> ]1..5] means 1 < x ≤ 5
>>> ]1..5[ means 1 < x < 5

I agree that you can do things by redefining ] bracket at start to
mean (. But to me this looks less natural, perhaps because I have a
graduate math degree :) Anyway I don't see strong reasons to not use
both types of brackets and its easier for the parsers too.

> Folks, you're spending a lot of mental effort over something that won't
> get you noticeable appreciation. The thing that will win users and other
> plugin authors over to a new syntax is not that it looks nicer or more
> similar to existing notation conventions in whatever field, it's that it
> allows them to do the things they need to do now and in the upcoming
> years and that they had to *hack* with the former standard. In other
> words, *functionality* (that the syntax is bound to have to adapt to to
> a certain degree, anyway).

I agree. My starting premise to work on this was to develop better
format to express complex thresholds that I could not do with existing
including being able to specify complex consisting of multiple types
of checks on same metric in the future and more. I came up on my own
(and without knowing about new threshold syntax) with something that
is very much like it. The main difference is that I never bothered to
re-define range so my current library parses threshold line kind-of
like new format but with range specified using old style nagios way
plus also my own ">num", "<num" extensions. I will keep all that but
also add support for new range because it is more natural.

> I the wrote the comment under
>         http://nagiosplugins.org/rfc/new_threshold_syntax
> , and I'm *STILL* waiting for a check_disk (to reuse the example) that I
> can tell to consider the minfree part of the available diskspace for
> /var/log, but not /tmp,

This will be possible to do using "name" keyword. I brought it over
from my own specification (although in my own it also meant label
which is confusing and I separated it).

William

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________________
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