"Song" == Song, Young <young.song@sap.com> writes:
Song> I'm trying to send various flat files to a central syslog-ng server. Song> So, I have the following setups but somehow using the "local1" Song> and "local2" facilities don't work, although no errors when Song> restarting syslog services on both client & server. Song> My syslog-ng CLIENT (running syslog-ng 3.6.2): Song> source s_file1 { Song> file("/var/log/syslog/file1.log" Song> follow-freq(1) flags(no-parse) Song> program_override("audit")); Song> }; Song> filter f_file1 { facility(local1); }; Song> destination d_file1 { Song> syslog("10.10.10.10" transport("udp") port(514)); Song> }; Song> log { Song> source(s_file1); filter(f_file1); destination(d_file1); Song> }; Both your `s_file1` and `s_file2` sources have `flags(no-parse)`, which tells syslog-ng to *not* parse the file. As such, it will not be able to figure out the facilities. Mind you, in a lot of cases, logs already on disk rarely contain the facilities they were originally sent with. In this case, even if you dropped the no-parse flag, the filter still wouldn't work, because that information is simply not in the file. Now, if you want to read `file1.log`, and *add* the local1 facility before forwarding, that'd be a different thing - but as far as I know, that's not something syslog-ng supports at the moment. I would suggest a different approach: instead of the facility, set some custom SDATA field on the sending side, use the RFC5424 protocol (in other words, `syslog()`, like you already do) for transfer over the network, and filter based on the SDATA field on the server side. For example: rewrite r_file1 { set("audit-log" value(".SDATA.custom@18372.4.source")); }; And on the server side: filter f_audit_source { match("audit-log" value(".SDATA.custom@18372.4.source")); }; And similarly for the others. -- |8]