Menu
▾
▴
perfparse-devel
|
From: Florian G. <fl...@bi...> - 2007-03-07 09:30:14
|
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. 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 ... 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 > > |
|
From: Yves M. <yme...@fr...> - 2007-03-07 10:02:37
|
> 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 - |
|
From: Florian G. <fl...@bi...> - 2007-03-07 22:05:32
|
Sometimes it is better to think about things one time more. As is see now we can circumvent the problem: We just have to deliver a custom process-service-perfdata command that takes the $SERVICEOUTPUT$ and $LONGSERVICEOUTPUT$ and merges or parses them or adds a custom line separator. The easiest way would be if the $SERVICEPERFDATA$ would contain all perfdata. Then we would not have to parse them. I'll ask at the nagios-devel list. The only drawback would be that we are not able to use the file that nagios can generate for parsing.. Flo |
|
From: Yves M. <yme...@fr...> - 2007-03-07 22:54:34
|
> Sometimes it is better to think about things one time more. > > As is see now we can circumvent the problem: We just have to deliver a > custom process-service-perfdata command that takes the $SERVICEOUTPUT$ > and $LONGSERVICEOUTPUT$ and merges or parses them or adds a custom line > separator. The easiest way would be if the $SERVICEPERFDATA$ would > contain all perfdata. Then we would not have to parse them. I'll ask at > the nagios-devel list. With such a command, we can use our own separator. This is where we can use "\n||" for example. No problem :) Another one is to use the plugin feature of nagios called "Event Broker" if someone wants to code it :) > The only drawback would be that we are not able to use the file that > nagios can generate for parsing.. Yeah ! :) If I'm not too far from reality, I found the bug ! How do you find the beginning and the end of an event in the file that nagios-3.0 generates ? If the nagios developers can answer that question, we have the solution for perfparse. If not, I consider that as a bug. What do you think ? Now, I'm going to sleep :) $ date mercredi 7 mars 2007, 23:53:32 (UTC+0100) 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 - |
|
From: Florian G. <fl...@bi...> - 2007-03-07 23:38:49
|
Yves Mettier wrote: > > > Yeah ! :) > If I'm not too far from reality, I found the bug ! > How do you find the beginning and the end of an event in the file that nagios-3.0 > generates ? If the nagios developers can answer that question, we have the solution for > perfparse. If not, I consider that as a bug. What do you think ? > Now, I'm going to sleep :) > > $ date > mercredi 7 mars 2007, 23:53:32 (UTC+0100) > > Yves > I'd just say: the option that nagios generates the file does simply make no sense. Call it a bug or a logfile - if we don't support that setup, then we don't have to care. Flo |
|
From: Yves M. <yme...@fr...> - 2007-03-08 09:45:42
|
> I'd just say: the option that nagios generates the file does simply make > no sense. Call it a bug or a logfile - if we don't support that setup, > then we don't have to care. OK. So as far as I see, when perfparse is plugged in nagios-3.0, we will only support the command that use the $SERVICEPERFDATA$ macro (from the other mail from Ethan Galstad). And is there is somebody who wants to help, some code can be developped to use the Event Broker of Nagios. Except the need to clean perfparse code, this is good news :) 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 - |
|
From: <Mat...@ka...> - 2007-03-12 14:34:41
|
per...@li... schrieb am 08.03.2007 10:45:20: > And is there is somebody who wants to help, some code can be > developped to use the Event > Broker of Nagios. Despite the fact that I don't know the code, I think a large part perfparsed could be reused. If i had more time I would give it a try. But I haven't :( |
|
From: <Mat...@ka...> - 2007-03-07 10:09:19
|
Hi all, > 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 ... I know three reasons: - all plugins need to be changed - performance output would not be usable with systems < nagios 3.0 (the pipe limit) since xml is too bloat for - i don't know - 512 bytes? - all performance graphers would need to be changed There was a discussion about performance output changes on the nagiosplug-devel list a couple of weeks ago. Ton and me called for input from performance addon developers - no reply. > > TEXT OUTPUT | OPTIONAL PERFDATA > > LONG TEXT LINE 1 > > LONG TEXT LINE 2 I think Ethan told sth like "I think this won't break anything" at the Nagios Conference last year. That's true if only the first line is interpreted. matthias |
|
From: Yves M. <yme...@fr...> - 2007-03-07 10:51:17
|
Hi all > There was a discussion about performance output changes on the > nagiosplug-devel list a couple of weeks ago. > Ton and me called for input from performance addon developers - no reply. Too bad that I was not in nagiosplug-devel list :( >> > TEXT OUTPUT | OPTIONAL PERFDATA >> > LONG TEXT LINE 1 >> > LONG TEXT LINE 2 > > I think Ethan told sth like "I think this won't break anything" at the > Nagios Conference last year. > That's true if only the first line is interpreted. Not as true as you think... The problem is that "first line" with no definition of a separator for the end of events, means "first line of a stream of events", not "first line of an event". So yes, it will break nothing. But with LONG TEST LINE X containing a pipe (for multiline perf data) will also be parsed as events. And perf data following the 1st LONG TEST LINE X with a pipe do not contain a pipe so they will be ignored. Is it acceptable to have more but not all perf data parsed ? :) Is there anybody who can make things change in Nagios before nagios-3.0-stable ? If not, how can we do ? 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 - |
|
From: <Mat...@ka...> - 2007-03-07 11:06:58
|
> > Is there anybody who can make things change in Nagios before > nagios-3.0-stable ? > If not, how can we do ? If i know it right, ethan is the only developer working on 3.0. You could ask on nagios-devel. But maybe you shouldn't be too optimistical. matthias |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X