[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 05:47:14 CEST 2004

> It seems there are two arguments here:
> 1) some users might want more presision than nagios provides. You are
> not one of them. Nor am I. Do people really need better than one-second
> resolution? If they think they do, how often is it reallt accurate when
> it come from different machines which wil have dispersion in ther
> clocks? (I'm thinking of a distributed setup here)

If you make a graph for only one machine, there is no dispersion of the clocks. I agree
for the rest.

> To me, the case has not been made for the need for time here.

Same for me. But... see below

> 2) other programs run outside of the context of nagios do not provide
> the nagios time macro.
> In that case, couldn't the progam provide that data? So if tou run a log
> analysis program to extract events from a log, you should run it outside
> the context of nagios and report the data to the handler in the same way
> nagios does.

Right, and this is what we will probably do here.
However, for somebody who needs precision and who runs another tool to make perf data
for nagios-compatible perfdata tool (like perfparse), we need that compatibility. And
nagios plugins are unable to give something compatible with higher precision.

Is it a good idea to extend the protocol for such a need, even if nagios does not use it ?

I'm still thinking...
if we adapt our parsers to be able to read the following, is the problem solved ?

ntm[.xx] key=valueUOM;...

where ntm is the time that nagios provides with $TIMET$, where xx are milliseconds and
are optionnal


>> 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]
> The original perfdata idea was to have some spac e-separated list of
> results. Round 1 of refinement was to add the capability to express
> units, Round 2 was to add ranges so graohs could be scaled. This is
> round 3. So far every round has been a refinement that retained
> compatibility with previous guidelines. If there's no strong reason to
> change, let's not.

Just a question: why don't we have this ?
key=valueUOM;[warn range];[crit range];[possible values range]

Well, we can keep ...;[min];[max] for compatibility with the previous. But if some
change is made that breaks compatibility, and if you like my suggestion, don't forget it

Now, about Ben's suggestion of protocol version. This can be a reserved keyword for the
label. But will it really be used ? Will new parsers try to support old versions ? Old
parsers cannot support new versions of course :)
Aren't log files enough to see that there is a problem, and that some old plugin needs
to be updated ?

Well, for now, the only agreed changes are to allow INF (-INF, +INF) for the ranges, and
NaN for the value. Is that right ?


- 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