]] 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
