[Nagiosplug-devel] Suggested alterations to the Performance P rotocoll
Karl DeBisschop
karl at debisschop.net
Fri Sep 10 19:04:29 CEST 2004
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?
--
Karl
More information about the Devel
mailing list