You would need two source definitions, one for "regular" message trans- port to syslog-ng (would probably contain internal, /dev/log, etc. and your network port(s)), and the other one for messages that are fed back to syslog-ng (which IMO should be a FIFO, because that gives you more flexibility when choosing a language to implement your external filter programs).
The log statement for the first source would then probably be so that all syslog-ng filters ("internal" filters in that case) would be applied to the log message, while the log statement for the second source definition could possibly be without any filters, and directly going to a specific log.
Much better explanation :) The only problem with this implementation is the double hit for every message.I have 53 hosts that generated 2.5 million log entries yesterday; so having a 'loopback' filter could theoretically throw up to 5 million at syslog-ng. I don'twant to overload the system. Also, when an 'event' happens, and a cluster of boxes all start logging furiously for a few seconds, I think that the burst * 2will temporarily overwhelm it. Meanwhile, an 'inline external'(?) filter would obviously eliminate the double hit,and in my specific case, could help reduce the load by re-writing the messages on the fly and doing a language compression.