Re: [Perfparse-devel] nagios-3.0a and plugin output

[Yves M. <yme...@fr...>]

> Hi Yves,
>
> yes, this morning i've seen the announcement too. The biggest problem is
> the separator i think. For the parser i once had the idea to use the
> regex library. With this we could use a well known "parser" that is
> fairly easy to configure.

While the events are monoline, don't change it : it works well, it is very fast and
nobody complains about bugs.
But when the events change, rewriting the code with the regex features of libc (or if
you don't mind an additionnal dependancy, libpcre) is a good idea to have the code
readdable :)

About the separator, what do you think about a line beginning with double pipe || ?
I also suggest that the separator is configurable (for possible future extensions of
nagios or third-party user tools).

> I don't know why the nagios people don't use something like XML for the
> plugin output. It would bloat the output a bit, but there would not be
> any limitation in characters or whatever any more ...

Should you send a mail to nagios-devel@mailinglist to tell them ? And describe the
problem we have with streams ?
The separator is \n in nagios-1.x and nagios-2.x. Because the need is not multiline but
to have \n no more a separator but a "blank" character. what is the new separator ? What
separator would they suggest ? The string "\n||" like me ? Or just one of "\n|" or "||"
?

About XML or similar, I fully agree with the idea, but if I was a nagios developer, my
answer would be no because of backward compatibility.

Well, easy for me to speak and do nothing :)

Yves

>
> Flo
>
> Yves Mettier wrote:
>> Hi Flo,
>>
>> I have problems with the mailing-list (on my side, not sourceforge). So I'm sending
>> this
>> to you, not to perfparse-devel@... Feel free to forward it to perfparse-devel@...
>>
>> It is about the new nagios-3.0a. I'm reading the "what's new" and I found this :
>>
>> http://nagios.cvs.sourceforge.net/*checkout*/nagios/nagios/html/docs/pluginapi.html
>> The plugin output spec will be this :
>>
>> TEXT OUTPUT | OPTIONAL PERFDATA
>> LONG TEXT LINE 1
>> LONG TEXT LINE 2
>> …
>> LONG TEXT LINE N | PERFDATA LINE 2
>> PERFDATA LINE 3
>> …
>> PERFDATA LINE N
>>
>>
>> This will affect perfdata parsing in perfparse : the whole parser assumes that there
>> is
>> one event per line and one line per event.
>> With multi-line events, we have 2 problems.
>> 1st problem : don't stop at the end of the line. This should be not very difficult.
>> 2nd problem : in a stream of perf data (like a pipe or a socket), how to know the
>> start
>> of a new multiline event ? Should the perfparse plugin in nagios echo an ending
>> separator ?
>>
>> If you have no idea, ask the nagios guys. If they don't have any idea either, maybe
>> it's
>> still time for them to change the plugin spec ?
>>
>> And don't forget, I've not worked on perfparse for years. Maybe I'm obsolete ? :)
>>
>> Yves
>>
>>
>
>


-- 
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- C en action - http://www.oreilly.fr/catalogue/2841772896.html    -