[Nagiosplug-devel] RFC: New threshold syntax

[Andreas Ericsson]

Max wrote:
> 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.
> 

Not really. Verbose and easy to read should win out any time, as the
syntax isn't supposed to be used daily. It's much more important that
it's accurate and that the user is comfortable with the thresholds
he/she has specified than that it's possible to cram as many args as
possible into an 80 char wide screen.

>>  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.
> 

No, that's really, really bad, because everyone will come to the same
place and ask for help, so if you get 9 different libraries you'll
have 8 of them which no developer knows how to handle. Although I
expect that will be a small issue, since 99% of all users will just
go with what's default anyway.

>>  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.
> 

man pages > all that, for the same reason that the help output is
restricted to an 80 char wide screen (no, I'm not being inconsistent).

>>  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?
> 

I am, in the strongest possible terms. For one simple reason: Bitrot.

>>  > 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.
> 

Not really. find does it that way.

>>  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?
> 

Not stupid, but naive if you think that both of them will be kept up
to date, along with the documentation for both of them. Like I said,
it's maintenance nightmare to support two different ways of saying the
same thing, and doubly so if you want users to know about it.

> 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.
> 

What about use?

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231