[Nagiosplug-devel] Re: Suggested alterations to the Performan ce Protocol (Re: Nagiosplug-devel digest, Vol 1 #653 - 5 msgs)
Ben Clewett
Ben at clewett.org.uk
Thu Sep 9 04:16:25 CEST 2004
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
>
>
More information about the Devel
mailing list