Syslog include match granularity?

Hi JC,

What are the symptoms of the failure? Does syslog-ng start? If so, what happens/what doesn't happen that you expect to?

Can you try clearing your existing syslog include config using 'b syslog include none' and then create a file named /var/tmp/syslog.test.inc which contains the following:

 
 syslog include " 
  
 destination d_loghost { 
  udp(\"172.22.X.X\" port(514)); 
  udp(\"172.24.X.X\" port(514)); 
 }; 
 filter f_pool_member { 
  match(\"Pool member\"); 
 }; 
 filter f_jc_not_6 { 
  not facility(local6); 
 }; 
 log { 
  source(local); 
  filter(f_pool_member); 
  filter(f_jc_not_6); 
  destination(d_loghost); 
 }; 
 " 
 

The run bpsh < /var/tmp/syslog.test.inc

If that works, save the change from memory to file using 'b save'.

Thanks,

Aaron

Strangely enough the symptoms we are seeing are other misc log traffic not just "Pool member" related log messages on our 2 remote syslog servers. Yes we tried clearing it, restarting the syslog-ng services and still same results. What is the major difference between using my original script and creating a new one syslog.test.inc? Will this cause any undesired issues or impact with the LTM system itself?

I wasn't sure whether the problem was with syntax or function, so I removed some potential syntax problems (removed the backslash which was escaping the closing double quote, removed the single quotes). I also added both the f_pool_member and f_jc_not_6 filters to the log definition. These would be logically AND'd together. If you only want to send the Pool Member logs to the remote syslog servers, you could remove the f_jc_not_6 filter from the log definition.

 

 

I'd guess the reason you're seeing other logs being sent to the syslog server is that the "Pool member" filter wasn't actually applied to the log definition.

 

 

Making these changes shouldn't have any impact on load balancing, but it's always ideal to test on a non-live unit. You could try testing the changes on the standby or a dev unit.

 

 

Aaron