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.
David Lang
_______________________________________________
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.