[tylerjl]

One convenience of journald is that it exposes a single place to plug in log collection for observability tooling

opentelemetry-collector, promtail, and so on have native plugins for it, which makes aggregation easier to setup

Most tools have "tail this plaintext file" as well, but if it's all flowing to journald, setting up log collection ends up being that much simpler

[thyristan]

That is what syslogd has been doing since forever. Journald actually made this harder due to not supporting the established syslog protocol.

[Ferret7446]

And a lot of software don't use syslog because it's easier to print to stderr/stdout or some random log file. Journald makes it easier to capture everything no matter what the software does, including the established syslog protocol, so I don't even see your point.

If everything on your machine uses syslog, journald is a drop in replacement for the dozen of possible syslogd implementations.

[thyristan]

journald isn't drop-in because it only saves logs locally. syslog also is a protocol to send your logs to a log-server.

And the usual syslog APIs are 2 lines: Initialize with openlog(stream, process_name, flags) and after that do syslog(urgency, message). That is on par with stderr/stdout, and far simpler than handling your own logfiles. Except if you use log4$yourlanguage or something, then everything is just the same, you just configure a different destination.

And if you can't change your code to not use stdout/stderr, you can easily do yourcode | logger -t yourcode -p daemon.info 2| logger -t yourcode -p daemon.err