Hi List, Just looking for a bit of clarification on exactly what fields I can rewrite in a message. Basically I've got an annoying debug message coming out of a program and while I could filter it off to a separate file, what I really want to do is drop its level to debug (from warning) and let my existing filters take care of it. The docs say "Setting a field can operate on any value available via macros, e.g., HOST, MESSAGE, PROGRAM, or any user-defined macros created using parsers" so modifying LEVEL is not listed but its not explicitly excluded either. I tried "rewrite r_norm {set("1", value("LEVEL")); };" but that didn't work. However "rewrite r_norm {set("FOO", value("MESSAGE")); };" and "rewrite r_norm {set("BAR", value("PROGRAM")); };" work as expected. Are there limitations as to which parts of a message I can rewrite? Are there some fuller examples hanging around? Thanks, Chris
On Mon, 2009-04-27 at 16:54 +1200, chris packham wrote:
Hi List,
Just looking for a bit of clarification on exactly what fields I can rewrite in a message.
Basically I've got an annoying debug message coming out of a program and while I could filter it off to a separate file, what I really want to do is drop its level to debug (from warning) and let my existing filters take care of it.
The docs say "Setting a field can operate on any value available via macros, e.g., HOST, MESSAGE, PROGRAM, or any user-defined macros created using parsers" so modifying LEVEL is not listed but its not explicitly excluded either.
I tried "rewrite r_norm {set("1", value("LEVEL")); };" but that didn't work.
However "rewrite r_norm {set("FOO", value("MESSAGE")); };" and "rewrite r_norm {set("BAR", value("PROGRAM")); };" work as expected.
Are there limitations as to which parts of a message I can rewrite? Are there some fuller examples hanging around?
Hi, The limitation on what syslog-ng allows you to change has been lifted somewhat in syslog-ng OSE 3.1. You still can't rewrite facility/level though, since those are not string-like properties. But any string like data can be, like: * basic message properties (HOST, MESSAGE, etc) * structured data (.SDATA.id.element) * numbered regexp matches ($1 .. $255) Also macros can be referenced as values, although they are read-only and cannot be changed, value("R_DATE") for example should expand to the the received date of the message, even though it is not a string property. -- Bazsi
participants (3)
-
Balazs Scheidler
-
chris packham
-
okapareeya@hotmail.com