Re: Unifying logging by default
On Wed, Feb 20, 2019 at 02:03:08PM -0800, Josh Triplett wrote:
> While there are *absolutely* configurations in which system
> administrators want to log to arbitrary locations and files, I would
> like to propose that for consistency we should configure software to
> unify logging into syslog and/or journald by default. In particular, I'd
> propose that daemons and applications should default to logging to
> syslog (working with any installed syslog implementation providing
> /dev/log), and that daemons run via systemd units may detect or be
> configured to log to stdout/stderr which will be wired to the sysadmin's
> preferred log target.
To suggest a more concrete proposal, I'd propose the following rough
sketch of future logging policy (not to be incorporated into Policy
until after packages generally start following it):
- 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.
- The software MAY (but is not required to) detect that it is running
with stderr or stdout connected to journald, and in that case, log to
stderr or stdout, optionally using structured logging. The software
MAY detect that /dev/log is connected to journald, and in that case,
log to journald directly if it has such support. If the software does
not support any such detection, any systemd unit file invoking it
SHOULD pass an explicit command-line option enabling logging to
stderr.
- Otherwise, if /dev/log exists, the software SHOULD log to /dev/log.
The software MAY choose to use a structured log format if supported.
- Otherwise, the software SHOULD choose an appropriate fallback behavior,
such as logging to a standalone file, or displaying log messages to
the user if running interactively.
Some concrete use cases:
- Running logs through a log analyzer.
- Shipping logs over the network to an off-machine logging
infrastructure.
- Controlling where log messages go using syslog configuration.
- Logging to an in-memory journal on a system without persistent
storage.
Reply to: