From anti-systemd to pro-systemd in the shortest time

Posted Feb 3, 2014 0:00 UTC (Mon) by mchapman (subscriber, #66589)
In reply to: From anti-systemd to pro-systemd in the shortest time by dlang
Parent article: This week in "As the Technical Committee Turns"

> without systemd the syslog daemon could gather this data itself (the same way that journald does), in the mode where journald sends logs to the syslog /dev/log, this data is not all still available (some gets forged to be available, which costs additional processing time, other data is just not there)

I think we might be talking about different things.

I am interested in providing structured messages -- multiple fields containing all sorts of useful metadata -- from applications themselves. I am not too concerned about the "automatic" metadata journald adds; it's clear that if journald can add that, then so can any other logging system.

I note that you've linked to RFC 5424 elsewhere. The structured data extension in that does look interesting; I wonder if journald can support it (or if anybody has asked the developers or proposed it to them).

From anti-systemd to pro-systemd in the shortest time

Posted Feb 3, 2014 4:54 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

journald would just store this as text.

The RFC5424 structured data really isn't used very much, and even rsyslog (who's primary developer is the author of RFC5424) didn't have the ability to actually _use_ this data until a few months ago.

in spite of the official standard, the de-facto standard is looking like it's going to end up being JSON structured messages. All of the syslog daemons can parse JSON structured logs and act on the different variables in them (and modify them for that matter)

From anti-systemd to pro-systemd in the shortest time

Posted Feb 3, 2014 18:38 UTC (Mon) by rodgerd (guest, #58896) [Link] (1 responses)

That's good news, because while I appreciate journald forcing the issue of structured data, I don't appreciate the binary on-disk format.

Why it seems to have taken systemd to light a fire under the arses of syslog developers is another question entirely...

From anti-systemd to pro-systemd in the shortest time

Posted Feb 3, 2014 18:55 UTC (Mon) by dlang (guest, #313) [Link]

> Why it seems to have taken systemd to light a fire under the arses of syslog developers is another question entirely...

It didn't, the syslog developers had already been working on these things (and many others)

RFC5424 and the CEE standardization projects came out several years before the systemd journal.

The only features that the systemd journal had (or at least claimed to have) that syslog didn't have at release were

capturing STDOUT and STDERR (which I'm not sure is really that good an idea, as sloppy as many developers are with these)

trusted properties (some of which are racy to gather, so not as reliable as you may think), which had been discussed and was on the TODO list, but had not made it to the top

log 'security', which as many noted, the journald security did not protect you against malicious root on your system unless you sent data elsewhere, and sending data elsewhere is usually the best defence anyway. Syslog developers have implemented better anti-tampering features that specifically document what external connectivity is needed to make things secure.

It doesn't help that distros tend to ship such old versions of the syslog daemons. It is hard to see progress when the version that's included is several years old.