[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Yves Mettier]

> Date: Mon, 13 Sep 2004 21:10:22 -0400
> From: Karl DeBisschop <karl at debisschop.net>
> To:  nagiosplug-devel at lists.sourceforge.net
> Subject: Re: [Nagiosplug-devel] Suggested alterations to the Performance P
>  rotocoll
>
> 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.

Let's think again with an new point of view. Maybe you already had that point of view,
and not me.
My point of view was this until now:
label=valueUOM;...

Now, here is my new point of view:
label=value
And value can be one of:
'string'
'valueUOM;...'

What I am against is to have label=string;...
Now, I have something that karl should agree with, and that does not break compatibility
with numeric performance data.

label=data

label can optionnaly be inside quotes, like now. No change here.
data is either a string inside quotes (quotes are necessary here), or valueUOM;... with
no quotes.

So if the parser reads some quote char after the = char, it means a string and will not
be parsed as numeric perf data. If the parser reads no quotes after =, it is numeric
perfpdata like now.

The only compatibility we break here is that a quote char after the = char is
authorized, and parser now have to consider that as valid (even if they don't do
anything with it).

[...]

> 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"

This line gave me the idea of what I said before : this is a good example.

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

We have to have all plugins to print compatible output. Compatible with all the parsers
we want to be compatible with that.


>
> 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 2nd thing that gave me my new point of view.

Now, more comments :

>From nagios docs, we can do what we want with that, including a second | character to
add more information.

Whatever we do, accepting strings after the label, or using a second | char, we do what
we want with performance data.

Because the name of that data is "performance data", I think that the initial goal was
to use numeric performance data. If we can put strings as values, I don't consider that
as performance data any more. The name is no more a good name for that data. They should
be named "extra data" or "nagios unparsed data", but not "performance data". For
historical reasons, I prefer that we keep the name "performance data", but say "numeric
performance data" when we want to use valueUOM;range... and "string performance data"
otherwise.

I suggest a new vote. Who is for/against:
1| label=valueUOM;range... | <xml>extra data</xml>
2| label=valueUOM;range... label='string'
3| label=valueUOM;range... label='string' | <xml>extra data</xml>
4| other suggestion ?

I vote for 2 and I would agree with 3 if needed one day because 3 is not far from 1 :)
I vote for 2 because with 2, I don't know if 3 is already needed, and let's do things
one at a time.

Yves
-- 
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -