[Nagiosplug-devel] RFC: new style command arguments for thresholds

[Matthias Eble]

Hi Ton, hi list,
> Thanks for the feedback so far. Original post 
> here: http://thread.gmane.org/gmane.network.nagios.plugins.devel/4461/focus=4461
thanks for the summary. I like the way you manage the information from 
RFCs: ask, wait, summarize.

> Matthias points out lots of current work on SF trackers. Yes, current 
> tracker items is a big problem which I'm trying to address that. Any 
> help always appreciated.
Maybe I pointed this out a bit too unclearly. I meant that switching to 
the new arguments etc looks pretty time consuming to me. So my question 
is if the patches from the tracker need to/should be added first in 
terms of compliance and priorization.

In short:
  Will the discussed changes break the patches?
  Which task has higher priority?

Imo its important that submitted patches are included to the 
distribution because people who submit patches perhaps make more effort 
to include new features instead of creating their own way/plugin.

I should stay on topic..

> 
> Gavin Carr and Andreas Ericsson say that thresholds definitions could be 
> "contextual" based on what is best for the plugin, eg, check_procs 
> --processes=^1:1 to mean alert outside is . I think consistency is 
> better - any more thoughts?

I especially liked the threshold consistency. Defining arguments means 
to make the plugin do I want it to do. I don't want to examine if the 
plugin actually does with what I say.
Of course forcing explicit ranges would break compatibility.

> 
> Gavin and Andreas suggest that metric names are defined on command line 
> with "-", but mapped to "_" in perf data output. I'm fine with that 
> unless anyone objects.

I prefer -, too.

> Andreas disagrees with the choice of "/" as the separator in 
> --metric=crit/warn and suggests comma instead. I want to avoid a comma 
> because, in future, I can see ranges will be defined with comma to mean 
> other ranges, such as current page ranges: 1-6,9. Also, I'd like to keep 
> the crit and warn definition in the same syntax argument, rather than 
> separating out to --metric-crit and --metric-warn. I'm all for a 
> different delimiter if it makes sense and doesn't clash. I avoided 
> semi-colon because of the shell meaning.
I disliked the / at first, too but I couldn't find another valuable 
character on my keyboard. :/
> 
> Andreas suggests warn comes before crit. I favoured crit first because 
> it is more important than warn, but I'm not fixed to this. Any other 
> thoughts?

I always define warning first. But I think this is different from person 
to person. Maybe because for example check_disk first exits warning and 
then critical if nothing gets fixed.

> 
> Andreas suggests sticking plugin name and version in the current perf 
> data format as reserved words. Good idea.
>  

yes

> There's no major disagreements about a more consistent syntax required 
> for thresholds, so that sounds like an "okay".
> 
> I'm starting to think that, with the Nagios/NRPE output limitations, 
> that XML is too much right now and that we need to stick to the current 
> output style. However, I think the warn and crit sections of the current 
> perf data output is inconsistent to the point of being useless right 
> now, but I would need some people from the graphing teams to tell me 
> what they think. I'll drop the emails to various lists.
> 

What do you think about an new major version of the plugins?
New syntax and performance data could be acceptable to me in a new major 
version. What  do you think?

matthias