[Nagiosplug-devel] RFC: New threshold syntax

[Max]

On Wed, Mar 19, 2008 at 5:41 AM, Ton Voon <ton.voon at altinity.com> wrote:
>  I agree it looks arcane. But I bet, with any other plausible way of
>  defining on the command line, that what you intend to do above will
>  not be any clearer.

I agree with this, the balance between being verbose and easy to read
vs compact and arcane will be an interesting one to strike.

>  The driver for this is not to invent Yet-Another-Custom-Way-Of-
>  Defining-Thresholds. The driver is to get a standard/consistent/
>  dependable way of stating what your thresholds are, with some library
>  functions to make it simple to add into plugins.

And I agree that this is excellent and can let the Nagios user
community have a choice between libraries if needed.

>  I can imagine some helper functions (cmdline, web pages, google
>  calculator) that, with more fields and example values, will tell you
>  if your threshold is defined "as you expect".

Nice idea.

>  Or maybe do the reverse - enter in a specification like above, put in
>  a few load1, load10 and load15 values - and tell you which metrics the
>  plugin would alert on or not.

Not to go back to a sore topic that is just closing, but kind of the
equivalent of an explain plan in SQL?  This would be nice.

>  You can only do this with a standard way of defining the threshold.

My worry is that trying to have just one standard will leave the less
experienced and more experienced both less than content .. are people
on this thread adverse to having more than one way of specifying
thresholds to meet the needs of both groups?

>  > Ordered arguments could solve this quite easily, with a command-line
>  > looking like this:
>  >
>  > ./check_procs -u user -C command -c 1:1 --metric=VSZ -c 100000 --
>  > metric=CPU -c 30
>
>  I hadn't considered ordered command line options. check_disk had such
>  a painful way of specifying the thresholds, that I probably
>  subconsciously blocked that out.

I agree that forcing order on the threshold arguments from the command
line will frustrate some users and completely goes against the grain
of how 99% of Unix CLI tools work.

>  OK, "framework" is a bit marketing-speak. But in your list of "common
>  tasks" I would add "calculation of thresholds", which is precisely
>  what I'm trying to do here.

Agreed.

>  Absolutely. Which is why I spent 2 hours writing tests to make sure I
>  get exactly the expected results using a fixed ps output and a set of
>  command line options: http://nagiosplug.svn.sourceforge.net/viewvc/nagiosplug/nagiosplug/trunk/plugins/tests/check_procs.t?view=log
>
>  If you'd like to add in your favourite options, patches welcome.

So is this heading the direction of developing maybe two separate
libraries that would meet the needs of people who just want simple
thresholds and those who want complex thresholds or am I being
'stupid' again?

As with Unix having the getopt and long getopt libraries from GNU, I
personally would really like being able to choose between two families
of option parsers to make the plugins I write as easy to read and
maintain as possible.

- Max