> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Thursday, January 13, 2011 9:34 AM > To: rsyslog-users > Subject: Re: [rsyslog] question about the parser interface. > > am I correct in thinking that I can have the parser modify it's input > string and then fall through and have following parsers process the > modified string?
Yeah, that's right. Saying this, this is actually not a real parser module, but a message modification module (working at the parser level). This is just a differentiation in how this module is treated logically: the inner workings are the same. The trick is to simply modify the message, but return the "I am not the right parser" state. That will tell the engine to try the other parsers as well. The other ones do NOT know that the message has been modified. Rainer > > If this is possible, then this sort of thing is very simple, if not I > end > up duplicating a lot of the default parser with just a small > modification > at the beginning. > > David Lang > > On Thu, 13 Jan 2011, Rainer Gerhards wrote: > > > Date: Thu, 13 Jan 2011 09:27:35 +0100 > > From: Rainer Gerhards <[email protected]> > > Reply-To: rsyslog-users <[email protected]> > > To: rsyslog-users <[email protected]> > > Subject: Re: [rsyslog] question about the parser interface. > > > > David, > > > > sorry for the delay (I have to admit I did not notice in December > that you > > actually needed my help in integrating into the build system -- looks > like I > > really needed my vacation ;)). > > > > I have now merged the patch into a new branch v5-devel-david and > integrated > > the new module into the build system (this is done via a separate > commit, so > > it should be fairly obvious what you need to do if there is more need > :)). I > > have also tried to compile and that works. > > > > However, I have *not at all* looked at the code or tested anything. I > guess > > it's best if you can continue working on it. Once you tell me it is > ready, I > > can merge it into the main v5-devel branch. It would be great if you > could > > provide at least some minimal documentation before we do that (have a > look at > > the other modules' docs at ./doc/<modname>.html). > > > > Thanks, > > Rainer > > > > On 12/14/2010 05:46 AM, [email protected] wrote: > >> If the message can be modified by the parser, I think this is > >> appriximatly what is needed for the cisco problem. > >> > >> I'm not sure exactly what to do to tie it in to the build system, so > >> this one isn't even compile tested. > >> > >> David Lang > >> > >> On Mon, 13 Dec 2010, [email protected] wrote: > >> > >>> Date: Mon, 13 Dec 2010 20:26:35 -0800 (PST) > >>> From: [email protected] > >>> Reply-To: rsyslog-users <[email protected]> > >>> To: rsyslog-users <[email protected]> > >>> Subject: [rsyslog] question about the parser interface. > >>> > >>> Is it possible for a parser to just modify the input string and > then > >>> let it fall through for another parser to handle the modified > string? > >>> > >>> I have two rather simple parsers I want to write that fall in this > >>> category > >>> > >>> 1. Cisco with name resolution > >>> > >>> A cisco without name resolution turned on logs > >>> <pri> timestamp IPaddr %tag msg > >>> > >>> a cisco with name resolution turned on logs > >>> <pri> timestamp name : %tag msg > >>> > >>> I want to detect the bare : in the syslog field followed by the % > at > >>> the start of the next tag, and if I find them, just memmove > everything > >>> up (so that the % ends up where the : was, shortening the string by > >>> two characters), then let if fall through for normal processing. > >>> > >>> 2. AIX forwarding messages > >>> > >>> AIX defaults to messages in the format > >>> > >>> <pri> timestamp Message Forwarded From hostname syslogtag msg > >>> > >>> I want to look for 'Message Forwarded From' starting in the > hostname > >>> field, and if I find them, memmove everything up so that the > hostname > >>> is in the right place, and again let everything fall through to the > >>> normal parser for handling. > >>> > >>> I really don't want to have to duplicate the normal parser in each > of > >>> these parsers as they are just (almost) trivial cleanups of the log > >>> message before it's handled normally. > >>> > >>> David Lang > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
