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

Ben Clewett Ben at clewett.org.uk
Mon Sep 13 01:16:01 CEST 2004


I'll have to agree with Ton making it 3-3.

Not because I want 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 we 
break compatibility and insert new delimiters.  For that reason I vote 
to exclude from this version.

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.  Therefore this is safe for us.  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, 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






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.
> 
>> Ton
>>
> 





More information about the Devel mailing list