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

[Karl DeBisschop]

Ben Clewett wrote:

> Not to exclude textual data.  There are I am sure valid places for this. 
>  But as Yves said.  If we include text, there is no way of saying where 
> the metric value ends and the metric unit begins.

If the data IS a string, then it is not a measure and there is no metric.

> Or break 
> compatibility and insert new delimiters.

I don't believe representing stings breaks compatibility - I do believe 
that precluding strings does change the interface in a non-compatible way.

Further, you are suggesting new mechanisms for handling string-type 
perfdata in nagios when it is not required.

Perfdata is very simply the stuff after the "|" - nagios does not parse 
it or care what it say - it simply returns the data following the "|" in 
the perfdata macro. It is precisely this separation between plugin and 
scheduling that give nagios its extensibility.

If it is not sufficient for a parser to pass on things that it cannot 
parse as a number, we could do

  DHclient OK - 192.168.1.1|eth0="192.168.1.1"

I don't see how that is ambiguous, and it preserves the existing 
flexabilty in the interface.

Again, I would like to have someone give me a compelling reason why 
string data will break things - unit of measure and everything after it 
are and always have been optional, and were in fact not in the nagios 
documentation - they are just a convention of the plugin developers.

Also from the nagios docs:

	What you do with the performance data once its out of Nagios is
	completely up to you. If you are simply writing performance
	data to text files...

This is the sort of statement that suggests to me that the existing 
standard should be considered as relating to more than only the process 
of making a graph.

-- 
Karl