[Nagiosplug-devel] Re: Suggested alterations to the Performan ce Protocol (Re: Nagiosplug-devel digest, Vol 1 #653 - 5 msgs)

[Yves Mettier]

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

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