[syslog-ng] Confusion on number of filters

[James Lay]

On 2015-01-16 10:38 AM, Evan Rempel wrote:
> In my environment I use the structure
>
> log { source(s_local);
>
>      log { filter(f_syslogfilter);  destination(d_file); };
>      log { filter(f_firewall); destination(d_syslogserver); };
>      log { filter(f_logontype10); destination(d_logontype10); };
> };
>
>
> with great success.
>
> On 01/16/2015 09:26 AM, James Lay wrote:
>> On 2015-01-15 01:22 PM, James Lay wrote:
>>> Hey all,
>>>
>>> Here's what I have...one source:
>>>
>>> source s_local {
>>>          unix-stream("/dev/log");
>>>          udp(ip(0.0.0.0) port(514));
>>>          tcp(ip(0.0.0.0) port(514));
>>>          file("/proc/kmsg");
>>> };
>>>
>>>
>>> three destinations:
>>> destination d_file { file("/var/log/messages"); };
>>> destination d_syslogserver { udp ("x.x.x.x", port(514)); };
>>> destination d_logontype { udp ("x.x.x.x", port(515)); };
>>>
>>>
>>> and a few filters:
>>> filter f_syslogfilter {
>>>          message("0x0004")
>>> };
>>>
>>> filter f_firewall {
>>>          program("firewall")
>>> };
>>>
>>> filter f_logontype {
>>>          message("Logon")
>>> };
>>>
>>>
>>> With the below log entry running with -F -d, I will only get the
>>> first 2 of the three filters evaluated:
>>> log {
>>>          source(s_local);
>>>          filter(f_syslogfilter);
>>>          destination(d_file);
>>>          filter(f_firewall);
>>>          destination(d_syslogserver);
>>>          filter(f_logontype);
>>>          destination(d_logontype);
>>> };
>>>
>>> but after splitting them out I see all three evaluated:
>>>
>>> log {
>>>          source(s_local);
>>>          filter(f_syslogfilter);
>>>          destination(d_file);
>>> };
>>>
>>> log {
>>>          source(s_local);
>>>          filter(f_firewall);
>>>          destination(d_syslogserver);
>>> };
>>>
>>> log {
>>>          source(s_local);
>>>          filter(f_logontype10);
>>>          destination(d_logontype10);
>>> };
>>>
>>> Is there a reason or limit or documentation for this?  I can verify
>>> that the log entry passed for "Logon" in my testing didn't match 
>>> the
>>> previous two filters.  Version is 3.3.11.  Thank you.
>>>
>>> James
>> So more on this...in my production environment, the above splitting 
>> the
>> log entries didn't log anything after I put it in place.  Does 
>> anyone
>> have any pointers for a single source, with multiple filters and
>> destinations?  Thank you.
>>
>> James

Your suggestion worked like a champ...thanks so much.

James