21–30 of 45 posts
Why is logging to syslog as opposed to a separate file an important use case? Genuinely curious.
I think one reason people wanted it was to reduce/eliminate disk IO.
How much buffering does it do, if any? If not sufficient, it can result in either reduced performance or dropped log messages..
Any systemd experts know if there would there be any benefit to supporting journald directly, rather than through the syslog API, on Linux hosts?
What does Nginx do if the log message is longer than the 1KB limit imposed by the syslog protocol?
Why is logging to syslog as opposed to a separate file an important use case? Genuinely curious.
It's useful if you want to log to a centralized logging server. This helps to have all your logs in one place and also keeps the logs safe, if someone breaks into your server.
Why not use something like multilog or svlogd and wire up a tiny processor for it to kick logging data over someplace using something like rsync?
To boot, syslog is annoying to tune, depending on your particular implementation. rsyslog has a default buffer limit of 2k, whereas other syslog implementations (IIRC, syslog-ng and Solaris syslog at the very least) have default buffer limits of 1k, and this might not be obvious until you're running up against that and make the shocking discovery that you're losing data.
On an nginx server that services 2TB/mo worth of transit (which is distinctly possible since I've got infrastructure in production that does this), there's a good chance that you'll be stretching some of these limits a bit.
Why is logging to syslog as opposed to a separate file an important use case? Genuinely curious.
It's useful if you want to log to a centralized logging server. This helps to have all your logs in one place and also keeps the logs safe, if someone breaks into your server.
Earlier quoted context omitted.
It's useful if you want to log to a centralized logging server. This helps to have all your logs in one place and also keeps the logs safe, if someone breaks into your server.
That's a pretty weak argument considering that syslog is entirely UDP and is bound to drop log data, sometimes en masse, most likely even silently. Not a good idea. Why not use something like multilog or svlogd and wire up a tiny processor for it to kick logging data over someplace using something like rsync? To boot, syslog is annoying to tune, depending on your particular implementation. rsyslog has a default buffe…
Why is logging to syslog as opposed to a separate file an important use case? Genuinely curious.
- A large enough deployment to want centralized logging
but are:
- Cheap enough not to buy nginx (for good reason or not)
and
- Too lazy to maintain a patcheset against distro packages
and
- Too bad at linux administration to use the file pipe trick to log to syslog anyway
So, yeah syslog is nice but this change does have quite a narrow use case. What it did have were vocal complainers that knew the right places to complain online to be noticed.