[Nagiosplug-devel] Suggested alterations to the Performance Protocoll
Ton Voon
tonvoon at mac.com
Thu Sep 16 15:49:14 CEST 2004
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
More information about the Devel
mailing list