Re: [logs] idea: let's scare ourselves...

bet@private

2004-08-09T20:05:35 Adam Sah:
> UDP syslog is obviously broken and not reasonable to fix [...]

I used to feel that way. I've since changed my mind.

These days, I say instead that UDP transport isn't the best tradeoff
for all circumstances. But for the common case where system
availability is more important than log completeness, it can be an
appropriate choice. UDP-based syslog doesn't cause writers to block
when readers go unavailable. It also doesn't allow someone to easily
cause the reader to stop accepting any traffic by just establishing
and holding open the max number of connections it can handle.

Yeah, it's sure nice having alternative transports for syslog, but
no, having one of them --- the default one maybe even --- being UDP
isn't necessarily broken. Sometimes switching /dev/log from
unix_stream to unix_dgram can be beneficial too, similar reasoning;
if a server might have to spike up to more than maxfds concurrent
writers, and if you prefer incomplete logs to loss of service.

Now what's _broken_ about syslog is the idiot timestamp format. That
is so losing.

But the choice of UDP transport is just one of several reasonable
tradeoff points.

For a lot of applications, UDP is appropriate.

For a few more, TCP in the style syslog-ng does it is worthwhile;
that certainly improves the reliability in the face of heavy load,
and with well-tuned TCP can push more bits through fat pipes. Plus
it's easier to access-control TCP transport.

And for the occasional application, it's even possible that
transporting your log data via RDBMS transactions, or even something
more complex and revolting like BEEP, might conceivably make sense;
who knows.

-Bennett