事情的起因是在我在 Gentoo 修改 syslog-ng.conf ，想把 sshd 的 分離出來，使用了match之後，重開服務卻出現
the match() filter without the use of the value() option is deprecated
拿去google之後找到這篇
https://lists.balabit.hu/pipermail/syslog-ng/2009-September/013372.htmlin syslog-ng versions prior to 3.0, the complete message starting from the program name was stored internally as a single string, e.g. the $MSG macro was a simple variable reference, and the match() filter always matched against this string. In syslog-ng 3.0, this was changed (because of the new IETF protocol format), syslog-ng stores all bits found in the syslog message in separate fields, e.g. $PROGRAM, $PID and $MSG together make up the syslog message as you know it. Because of backwards compatibility, match() still mastches against the old "$PROGRAM[$PID]: $MSG" format (expressed in the new meanings of these macros), however since this is not a simple variable reference anymore, syslog-ng needs to construct this value for every match() invocation. The match() filter has been repurposed, and a new message() filter was also introduced. E.g. if you want to match against the message payload (without the program name and pid), you should use the message() filter.
The match() filter was extended to be able to match against any fields of a syslog message using this syntax: match("regexp" value("MESSAGE"));
This is equivalent to the message() filter. However now you can also match against custom fields that you can associate with the message using parsers, e.g. you are not limited to internal values, you can also add your own. -- Bazsi
There's still some problems related to match() with the value() option present. For now it only works with the 'standard' syslog parts (host, program, msg) _and_ the dynamic values generated using the new parser framework. Generic macros (which do not fall into the previous categories) do not. This is basically a design error, but I think it is a bug and I intend to fix it. The correct syntax is value("MESSAGE"), e.g. there's no dollar sign before the macro name. This is not fortunate as it differs from the normal template definition where the dollar sign indicates that a macro expansion needs to be done. The problem is that I originally didn't intend to support _any_ kind of macro expansion here. That's the design error, that I have to admit. The solution is not that difficult, but as of now, the value() option for the match() filter is not very usable. Sorry for that. Here's a list of supported "values": "HOST", "HOST_FROM", "MESSAGE", "PROGRAM", "PID", "MSGID", "SOURCE", And any kind of values that you created with a parser. Hopefully I can come up with a solution that's compatible with the current 3.0.x behaviour and one that is more intuitive. -- Bazsi