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

[Karl DeBisschop]

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 ?

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)

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

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. If you run the analysis within nagios to count the number 
of events in the last hour, then nagios will return the time the plugin 
was run, as it should. If you are transcrining the log entry time, maybe 
you should not be using a plugin from within the nagios execution 
environment.
> 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.