[syslog-ng] set tag in log statement

[Patrick Hemmer]

Sent: Wed Dec 21 2011 08:13:13 GMT-0500 (EST)
From: Balazs Scheidler <bazsi at balabit.hu>
To: Syslog-ng users' and developers' mailing list 
<syslog-ng at lists.balabit.hu>
Subject: Re: [syslog-ng] set tag in log statement
> On Sat, 2011-12-17 at 20:26 +0100, Fekete Róbert wrote:
>> On Friday, December 16, 2011 21:59 CET, Patrick Hemmer<syslogng at feystorm.net>  wrote:
>>
>>> Would it be possible to set tags on a message when it is matched by a
>>> `log {}` statement? This would be useful for complex log configurations
>>> so you could filter out messages that were logged by previous `log {}`
>>> statements without having to write really long `filter {}`s.
>>>
>>> I'm not sure if this is possible or not. Would depend on the order of
>>> operations, like if a filter block in a latter log statement is
>>> evaluated at the same time as an earlier filter block, or if its
>>> evaluated when it reaches the `log {}`.
>> Hi,
>>
>> currently that is possible only with a small workaround: using a rewrite rule to modify the $TAGS field of the message.
>>
>> Something like:
>> rewrite r_rewrite_tag1 { set("$TAGS,tag1", value("TAGS"));};
>>
> No, this wouldn't work. $TAGS is read-only right now.
>
>> Then a log statement would look like:
>>
>> log { source(s_local); filter(f_a); r_rewrite_tag1; destination(d_a); };
>>
>> http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/syslog-ng-ose-v3.3-guide-admin-en.html/modifying-messages.html
>>
>> You can probably combine the filter and the rewrite into a single conditional rewrite rule to simplify the log statement.
>>
>> http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/syslog-ng-ose-v3.3-guide-admin-en.html/conditional-rewrite.html
> Would it not be enought to use the flags(final) rule on log statements,
> perhaps using embedded log {} statements?
>
> This is equivalent to your configuration:
>
> filter f_a { facility(mail); };
> log { source(s_local); filter(f_a); destination(d_a); flags(final); };
>
> filter f_b { facility(local0); };
> log { source(s_local); filter(f_b); destination(d_b); flags(final); };
>
> log { source(s_local); destination (d_c); };
Hrm, missed this reply somehow. Anyway, yes that would work for that 
example configuration. But it doesnt work so cleanly on more complex 
configurations.

filter f_prog1 { program("prog1"); };
log { source(s_local); filter(f_prog1); destination(d_prog1); tags("tag_prog"); };
filter f_prog2 { program("prog2"}; };
log { source(s_local); filter(f_prog2); destination(d_prog2); tags("tag_prog"); };

filter f_crit { level(crit); };
log { source(s_local); filter(f_crit); destination(d_crit); tags("tag_crit"); };
filter f_notcrit { not tags("tag_crit"); };
log { source(s_local); filter(f_notcrit); destination(d_notcrit); };

filter f_other { not tags("tag_prog"); };
log { source(s_local); filter(f_other); destination(d_other); };


That is a bit of a bizarre config, but was just an example. You could 
probably work some combination of fallback and final plus reordering to 
get it working, but you end up with really hard to read configs. Plus if 
you ever have to go and add a new log statement in, if you dont add it 
in the right place it might not work or it might end up breaking the 
fallback/final rules. It just becomes very difficult to configure.

This