[Nagiosplug-devel] Re: Suggested alterations to the Performan ce Protocol (Re: Nagiosplug-devel digest, Vol 1 #653 - 5 msgs)
Yves Mettier
ymettier at libertysurf.fr
Thu Sep 9 03:08:09 CEST 2004
> My philosophy is that perfdata must be a measureable range of data, and time
> is not.
I agree with you, but maybe not fully. My opinion:
We have this:
ntm key=valueUOM;... key=valueUOM;...
ntm is when the plugin was run, and we assume that it is also when the data were
retrieved. (ntm for Nagios TiMestamp)
I suggest this:
ntm key=tm;valueUOM;... key=tm;valueUOM;...
Here, we still have when the plugin was run. But the plugin explicitely says when it got
the data. If the tm field is empty (read this: "key=;valueUOM;..."), the parser will
return the nagios timestamp.
Many plugins (check_disk, check_load...) don't need to say explicitely when they were
run. This field should be used only for specific needs. This is where I agree with you.
One example is to scan some log file with perf data in it and convert them to nagios
perf data format. In most case, this can be done without using nagios. However, even if
we don't use nagios, we can use perfparse or other tools, and use that syntax.
Another example is if we need precision. I consider that nagios cannot be very precise
with its $TIMET$ macro (that becomes my "ntm" field above). Maybe some users (I'm not
one of them) want more precision and can code that precision in the new "tm" field ?
Some additionnal question: wouldn't it be better, if the perf data syntax changes, to
put some ";" between the value and the UOM ? Something like key=[tm];value;[UOM];[warn
range]:[crit range];[min];[max]
btw, what are min and max for ? I have no idea of what they can represent as a plugin
output value. Isn't it something to compute by a tool like perfparse ? If there is no
good reason to keep those, can we remove them ? If this is used, forget about my request
:)
Yves
--
- Homepage - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key - http://ymettier.free.fr/gpg.txt -
- Maitretarot - http://www.nongnu.org/maitretarot/ -
- GTKtalog - http://www.nongnu.org/gtktalog/ -
More information about the Devel
mailing list