[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