(A few preliminary answers follow - I'll have another look at this later tonight from home, once I tested a few things on my local solaris vm) "Mishou Michael" <Michael.Mishou@csirc.irs.gov> writes:
I'm going to experiment with syslog-ng and the loggen tool to find a point at which a single syslog-ng instance starts dropping inbound UDP traffic with a simple configuration writing to disk. Once I have that number, I have a few options:
1. Experiment with syslog-ng 3.3 and the new threaded code to see if I have performance gains. I'm hesitant to push Alpha code in production, if anyone has any experience with 3.3 in semi-production environment running consistently I'd love to hear it.
I've been running 3.3 on most systems I administer (2 of my own servers + a few I administer for friends; and all of my virtual machines). It's been serving me fine for the past 4 months now. However, most of my systems are also linux systems, where syslog-ng is much better tested (and I'm not using UDP at all). Personally, I'd give it a test run, as current 3.3 is fairly stable.
3. Give up on syslog-ng until 3.3, or move to some other solution. Not sure what I could do here, rsyslog is the other major contender I guess, not sure what gains I would get. Could also do native syslog server and post-process to different buckets/relay which is what we mainly use syslog-ng for.
I wouldn't consider rsyslog. It's a nightmare to maintain that, and an even bigger nightmare to get it to perform well in any but the most trivial situations. (Or it might be just me being too used to good documentation and readable config files, but I'm fairly sure it's not just that :P) -- |8]