[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Ton Voon]

Sorry for not chipping in earlier. I'd like to wrap this up soon.

On 14 Sep 2004, at 10:19, Yves Mettier wrote:

> 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 have finally given in on the strings argument. I think it was Karl's 
example and the idea of pie graphs that swayed me.

I vote for 2, but with a guideline on the type of strings (as suggested 
by Ben). Log file entries that are uniquely different (eg, by the 
addition of time), should not be included. I would also put a paragraph 
on the future idea of XML data because everyone here seems to think it 
is a good idea and I don't want to lose it.

I think we should use standard C convention for the strings - eg, use 
single quotes, allow any characters with two single quotes for a single 
quote within the string, so check_procs may return:
   process_warn='httpd' process_warn='java program' 
process_critical='/usr/bin/xntpd'
Also allow duplicate labels (for pie chart purposes).

Can anyone think of other good examples for the documentation?

Back to the other proposals:

> Back to perf data, in my opinion, we still have:
> - do we replace "~" with "inf" in ranges, and do we allow "nan" for 
> values ? (I vote for
> yes)
I would prefer to not use characters like ~. Readable macros are good 
for me and I would prefer no funny delimiters like $INF$. But what if 
valueUOM is the format, what if the value is text? Is NANms okay?

Karl says following POSIX, NAN/INF can be case insensitive.

> - do we replace [min];[max] with a unique field with range format ? (I 
> vote for yes only
> if we change the protocol and make something not compatible)
I forgot what the argument for this is :)

> - do we allow non numerical values ? (I vote no)
Yes for strings as above.

> - do we add a separator between the value and the UOM ? (I vote yes 
> only if we allow non
> numerical data for values)
No.

Ton