[Nagiosplug-devel] Suggested alterations to the Performance P rotocoll

[Ton Voon]

On 11 Sep 2004, at 03:03, Karl DeBisschop wrote:

> Voon, Ton wrote:
>>> From:	Karl DeBisschop [SMTP:karl at debisschop.net]
>>>
>>> Ben Clewett wrote:
>>>
>>>> 9.  Limit protocol to just numerical data:  No.  But will not be 
>>>> supported by some storage programs
>>>
>>> Right - programs that are built for graphing would be expected to 
>>> ignore such data. But that does not give license to design the 
>>> guideline such that nothing but graphing can ever be done with the 
>>> data.
>> 	[Voon, Ton]  [apologies for using Outlook]
>> 	Actually, I disagree on this fundamental point. I think perf data is
>> **only** about graphing the data - this is why I am against strings 
>> and
>> check_time labels. 	I've been thinking a lot about this and I think 
>> what is required is
>> the concept of "additional structured data". The status output gives 
>> an
>> overview, the perf data gives the graphing and the "additional 
>> structured
>> data" gives plugin-specific stuff that can be processed in some way.
>
> I like the idea of "additional structured data"
>
> But I don't see how it in any way suggests we should require that all 
> perfdata be numeric.
>
> Sometimes the data itself is a string (e.g., the current status of a 
> printer - ONLINE/OFFLINE, or the DHCP-assigned IP address of an 
> interface, or the hostname of a machine connected to a particular port 
> on a Shiva terminal concentrator)
>
> SNMP recognizes this - if has the capacity to return simple strings 
> and other "interesting" data like IP addresses. Why should we assert 
> that if someone monitors a string via SNMP, that they will not be able 
> to use perfdata to create a long-term log of that data?
>
> Note that I'm not requiring anyone to actually handle that data - I'm 
> only saying that we should not create a data specification that forces 
> one view of perfdata utility (graphing) onto the world as a whole, 
> when there may be other uses also.
>
> And what is the cost of allowing strings? We use "$NAN$ instead of 
> "NAN" and "$$" instead on "$". A small effort.
>
> I just do not see how the new guideline will benefit significantly by 
> outlawing string data. If someone has explained the harm in allowing 
> strings, I have just missed it, and could you repeat the argument?

The argument is one of appropriateness. At the moment, we call it "perf 
data", which (for me) implies graphing. This discussion is about allow 
extra information  which provides more data about the particular check 
(including returning strings or log entries or even configuration 
data).

If we are serious about providing "extra data" in the perfdata section 
of plugin ouput, then the argument for me becomes 'is this label="info" 
format the best way of representing this data', and I would say no. 
Already we are getting into using $ for strings/macros and arguments on 
time representation. What happens with multiple log entries? It will 
probably look like "ntm={time} entry={log} ntm={time2} entry={log2}". 
The reason for proposing XML for the output of the (future) "additional 
structured data" is because they have already solved a lot of these 
problems - moving away from a variable-pair based system to a more 
flexible xml tag structure.

Which is why I want to keep perfdata to just performance data. But I'm 
currently losing 3-1.

Ton