I have a similar issue. I found that using syslog-ng to filter out messages is quite effective for syslog-based stuff, obviously. For non syslog-stuff the nullQueue transformer is probably the best option. Doing that with SEC seems painful, and probably not any more efficient. (Although, there are still things I can do with SEC that I can't with splunk, so we are still using both for the time being.)
I found that redirecting my syslog-ng output to a "nosplunk.log" file (which Splunk doesn't index) was helpful in the process of verifying that I was weeding out the right messages. You approach also has to depend on whether these messages are completely expendable (in other words, you don't need them to even make it to the log files), or you just don't want to waste index space in splunk...
This is probably obvious, but make sure that you are only applying the transformations on relevant sources or sourcetypes. In other words, unless everything you are trying to filter is coming from a single file, than you can use per-source transformers to keep the pre-processing down to a minimum. (In other words, you aren't trying to filter our mesages for app "X" in the log file of app "Y".) It's certainly easier to do per-sourcetype setups as much as possible, but sometimes setting up per-source settings can be better for the kind of filtering that you are looking to do.
If you haven't already gone down this kind of per-source setup path before, you should know that it can be tricky to get the config right. (Although, the docs have been updated since I first tried this, which helps a ton! See "Pattern collisions" section on this page: http://www.splunk.com/base/Documentation/4.0.10/admin/Propsconf). I've found the following command to be very beneficial in confirming the setup on a per-log file basis: splunk test sourcetype /var/log/mail.log
Well. That was longer than I wanted it to be. Hope you find some of it to be helpful.
