4 ms·
> [..] elk/splunk, etc, because journald is simply not up to par. Could you expand on what's not up to par in journald vs. rsyslog? Watching textfiles for chan
by habarnam 7y ago
> [..] elk/splunk, etc, because journald is simply not up to par.
Could you expand on what's not up to par in journald vs. rsyslog? Watching textfiles for changes vs. receiving data on a non blocking socket is definitely _not_ more efficient (nor "better" in my opinion).
- arminiusreturns 7y agoMostly related to the tooling around those things, especially when dealing with groups of machines sending logs to a central system. It's worth remembering you are still using journald when using one of the syslogs, it's just forwarding all the journal messages to the syslog socket. As the tooling catches up this gap will close. For example the json output of journald can be really useful, that said, most of the tools still require some change of the output from the binary format which they can't read to a text format whether that be json or syslog... and the binary format in general being a general pain point if (read: when) things break (such as corruption of the whole journal past corruption point vs one section of text in syslog). It's worth remembering that journald was designed for local system use. It's just one more of the reasons I had some hesitation with systemd but got shouted down by everyone on the systemd bandwagon.