[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Yves Mettier]

>> 2| label=valueUOM;range... label='string'
>> 3| label=valueUOM;range... label='string' | <xml>extra data</xml>

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

If you want a guideline on the type of strings, I agree in the concept, but we cannot do
it easily and keep things simple.
Why would we have valueUOM;range... without quotes, and all other possibilities inside
quotes ? The answer is: because of compatibility. This is not a good answer for me.

I have an idea: we have nothing on the label yet :)
Could we have label:type=value ?

label1:string='any string'
label2:perf=valueUOM;range...
label3:log=timestamp;'log line'
label4:double=value   (just a value, that can be stored in a "double" variable in C)
label5:int=value      (just an integer value...)

label:type=value

- label allows any character except one of " :'" and if you want to put one of those
chars inside the label, you can still do it if you put the label between quotes, and ''
is considered as ' inside quotes, like now.

- type is an allowed one. My parser allows "string" and "perf" but recognize it from a
value with or without quotes. For compatibility, I will keep that behaviour when the
type is not specified. Allowed types are discussed here of course :)

- value follows the syntax corresponding to the type. "string" syntax is any string
inside quotes. "perf" syntax is the current one. "log" would be (remove the double
quotes) "timestamp;'log line'". "ipaddress" would be A.B.C.D where A->D are either
decimal or hexa numbers. We can even have a type "error" where the string explain the
error. This is probably for debugging purpose. And so on...


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

My parser already allows this, so I can only agree :)

> Can anyone think of other good examples for the documentation?

See above :)

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

I agree with you.
NANms is not OK. It could be OK if we code a parser that test the 3 first chars for the
string "NAN". But I don't want to do it because this is nonsense. How can you put a unit
to something that is Not a Number ? :)
The plugins have to check it. The parser will refuse a NAN with a unit because it does
not recognize it as NAN.
And below, I found a way to allow it easily even if I don't like it... :)


>
> 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 :)

min-max is a range, but with perfs, it is coded as 2 separate values. I'd like to code
them as a range. But this is not possible for compatibility purposes.

Hey, wait !
If you agree with my label:type=value syntax, I have a suggestion. Let's allow those 2
syntax:
label1=valueUOM;[warn range];[crit range];[min];[max] (this is like now)
label2:perf=value;[UOM];[warn range];[crit range];[limit range] (where the limits are
min and max)

The syntax with label1 would be supported for compatibility and considered as obsolete.
The syntax with label2 is more logic.
The syntax with label2 even allows NAN;ms :)

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

I now vote yes, with label:type=value syntax :)

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

yes, with label:type:value, this is possible :)

Your opinions ?

You can find here (http://ymettier.chez.tiscali.fr/perfparse-devel/index.php) a new
version of my parser (nagios_generic_perf_parser-0.0.2.tar.gz) that should compile
better on Linux and with no reference to glib. It does not follow label:type=value
syntax yet. It still allows ~ for infinity, but I agree to remove it.
I will code something to recognize the | as a separator where everything after remains
unparsed. This will allow plugins to use it even if my parser does not understand XML.

I wait for your comments before improving my parser.
Does anybody have a suggestion of a name for the library that will contain my parser
when I extract it definitively from the perfparse project ?

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