I've been pushing to implement this for our application, but I'm told that we used to, and had to turn it off because it would saturate the IO of the logging server.
Has anyone else experienced this? Is it just a simple configuration tuning problem?
Has anyone else experienced this? Is it just a simple configuration tuning problem?
Rather unlikely unless your deployment is very large or you're doing extraordinarily expensive filtering/binning on the sink-host.
The first bottleneck is normally diskspace, not disk I/O. Those logs pile up very quickly, depending on how long you retain them.
The raw network and disk I/O, however, are rarely of concern. Before you approach either limit you're already logging to the tune of ~300G per hour - and have probably switched to a distributed architecture of some sort long ago.
Writing broad streams of sequential text is very cheap.
Making sense of what you wrote, ideally before actually writing it, but at the very least before being forced to purge it due to storage constraints, is the difficult part. ;-)
Looking at limits on open files, and considering tcp timeouts and cookies were all we needed. Total volume was in the order of high 10s of GB.
If you want to unpack offline, contact details are in my profile.
If you're running a whole datacenter's worth of logs into your loghost, then you might want to consider a distributed approach. For medium sized companies, I don't see why rsyslog wouldn't do the trick.
On the other hand, a lot of high security environments want to encrypt their syslog traffic using something like stunnel, which introduces OpenSSL overhead as well as TCP connection overhead. With thousands of clients and lots of encryption going on you definitely are going to hit some limits sooner rather than later. Check kernel parameter net.ipv4.ip_local_port_range (on Linux) and make sure you have a large enough range to accomodate all of the clients.