Re:Nginx 1.7.1 adds syslog support
by danudey on Wednesday May 28, 2014 @10:12AM
(#7809979)
> 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.
rsyslog and syslog-ng have support for TCP
> Why not use something like multilog or svlogd
Additional point of failure.
> and wire up a tiny processor for it to kick logging data over someplace using something like rsync?
Additional point of failure (processor); additional point of failure (rsync/ssh); non-realtime log replication (which is bad for breaking/progressive system failure/etc).
> To boot, syslog is annoying to tune, depending on your particular implementation.
All of the examples you list are easier to learn about, tweak, and monitor than the suggestions you've proposed, however.
> 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.
If you're dealing with 2 TB/mo in transit, you're probably capable enough to understand the risks with centralized log management and mitigate/monitor them ahead of time.
rsyslog and syslog-ng have support for TCP
> Why not use something like multilog or svlogd
Additional point of failure.
> and wire up a tiny processor for it to kick logging data over someplace using something like rsync?
Additional point of failure (processor); additional point of failure (rsync/ssh); non-realtime log replication (which is bad for breaking/progressive system failure/etc).
> To boot, syslog is annoying to tune, depending on your particular implementation.
All of the examples you list are easier to learn about, tweak, and monitor than the suggestions you've proposed, however.
> 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.
If you're dealing with 2 TB/mo in transit, you're probably capable enough to understand the risks with centralized log management and mitigate/monitor them ahead of time.