Re: Unifying logging by default

[Tollef Fog Heen <tfheen@err.no>]

]] Josh Triplett 

For the normal and easy cases of line-oriented logs, I think something
in the direction of your proposal makes sense, but I think we need to
have exceptions for all the weird and wonderful exceptions out there,
such as the example below.

> - If the software has a well-established set of logfile analyzers
>   specific to its logfile location and format, and the most commonly
>   used logfile analyzers do not support reading data from syslog or
>   journald, the software MAY continue using standalone logfiles (instead
>   of or in addition to the below behavior) until that changes;
>   alternatively, such logfile analyzers MAY facilitate the user's
>   configuration of the software to log to a location they understand.

This assumes that syslog is even able to handle the data, both in terms
of volume, but also format.  Syslog generally deals poorly with binary
data, for example.

I'm also reluctant to require software such as Varnish to send its logs
through any other logging infrastructure, since its logs are rather
verbose.

I picked a random example from a host and it was ~4kbytes and 97 log
entries for the text representation of one request with a backend
fetch.  Now imagine you're doing a few thousand request-becquerel of
that with traditional logging: you'd have about a magnitude more
syscalls for logging than you would for the processing itself.  This is
obviously silly, especially when you can get by with no syscalls at all
for it, by logging to an mmap-ed file and using that as a circular
buffer.

While Varnish is certainly an extreme case, I'd be surprised if it's the
only one doing something that doesn't fit into a traditional syslog
model.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are