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

[Ben Clewett]

Just a single comment from me:

The max and min are used by check_disk to return the range of the 
metric.  This is useful for sizing graphs and also useful if the user 
wants the data displayed as a percentage rather than absolute value.  In 
PerfParse they can also be used to invert the graphical output by 
setting the max to a value lower than the min :)

Whilst I think of it, and not wanting to complicate the protocol out of 
all practical usability:

If there is a change to the delimiters, and use of reserved variables, 
macros, and an additional 'ntm' field.  All of which make sense.  There 
might as well be a protocol version number in the output.  Which can of 
course be a reserved variable in it's own right:

| protocol_version=2.0 ntm key=tm;valueUOM;... key=tm;valueUOM;...

It will not help older parsers, but new parsers can check this variable 
and know that the plugin is using the new format.

Or it's getting too complex already :)

Ben

Yves Mettier wrote:

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