[Nagiosplug-devel] Suggested alterations to the Performance P rotocoll
Ben Clewett
Ben.Clewett at roadrunner.uk.com
Mon Sep 13 14:31:21 CEST 2004
Andreas Ericsson wrote:
> Ton Voon wrote:
>
>>
>> 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.
>> Which is why I want to keep perfdata to just performance data. But I'm
>> currently losing 3-1.
>>
>
> Make that 3-2.
I'll have to agree with Ton making it 3-3.
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. Or break
compatibility and insert new delimiters.
I don't class the second '|' as breaking the compatibility. This does
not effect the representation of the metrics after the first '|'. The
second '|' BTW is a great idea.
The old PerfParse would break at this point, keeping all data it has as
that point found. I would be interested to know from the authors of
other parsers what their mechanism will do when it hits this. As the
film says, 'Is it safe?'
The only place I can think of for textual data is a discrete data set
which cannot be easily adjusted to a number. Like the room name a
person is in, or the name of the last user to log in. Like MySQL, the
actual enumeration of this information can be completed as a hidden
back-office process, allowing the user to use the names as is. Which is
also a good idea from MySQL.
A classical line graph cannot represent this. However a pie chart or
bar graph can...
But as I said, I can't see how this can be supported with the standard
as-is. A macro $NAN$ is not a value. (Not actually a Macro either,
thanks Yves :) $NAN$ is a number by another name, where only a few
specific values will be supported. (Actually if $NAN$ = 0.0/0.0 surely
this is a Macro ? :)
Anyway, before I make this more complex, I'll leave it there...
Ben
More information about the Devel
mailing list