2013/4/30 David Lang <[email protected]> > On Tue, 30 Apr 2013, Rainer Gerhards wrote: > > 2013/4/30 David Lang <[email protected]> >> >> On Tue, 30 Apr 2013, Rainer Gerhards wrote: >>> >>> On Tue, 2013-04-30 at 03:27 -0700, David Lang wrote: >>> >>>> >>>> On Tue, 30 Apr 2013, Rainer Gerhards wrote: >>>>> I agree that modifying the original message (or worse, a portion of the >>>>> original >>>>> message) and then having to re-parse it to properly update all the >>>>> derived >>>>> variables is extremely ugly. >>>>> >>>>> >>>> I think that modifying the MSG part of the message is probably not >>>> problematic. But anything beyond that most probably is... >>>> >>>> >>> With just traditional syslog (where the MSG is pure free-form text) you >>> are right, but we are past that now with JSON, RFC5424, etc. The MSG >>> portion is now being parsed and the results assigned to variables. >>> >>> What would you do if you parsed a message, it created a variable that's >>> then used in an IF statement to do a rewrite of the message that >>> eliminates >>> the variable that you created? >>> >>> or what if you have multiple IF statements, the first of which would >>> rewrite the message in a way that would create a variable that's used by >>> a >>> second IF statement. >>> >>> >>> I think this can be properly handled, as the user has control over what >> is >> done when. So the route to take would probably be to modify first, and >> then >> call the parsers. >> > > I don't see this working. Especially given the problem of false positives, > I see many cases where the user will want to make modifications inside IF > statements. And those IF statements will require that the message already > be parsed. > > so at the least, you will be doing the parse twice, and you almost would > want to do it again after each modification. > > > But, of course, using modifications only on the output definitely prevents >> problems... >> > > Yep. making the original message (and the built-in properties) read-only > but allowing the user to set and modify all the $! variables avoids all > these problems while still providing the user with all all the flexibility > they need. > I tend to agree ;)
Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
