3 ms·

Where is this confusion made? The author compares syslog-style logging (plain text, with some tools grafting on ad-hoc metadata embedding formats) with systemd-

Where is this confusion made? The author compares syslog-style logging (plain text, with some tools grafting on ad-hoc metadata embedding formats) with systemd-style journal logging (binary with special tools to read them).

JackSlateur 2y ago
A log entry is composed of many things: some event nature, a user, who sent the entry, when it happened etc The core problem is that log messages themselves almost invariably come with additional metadata, often fairly rich metadata, but if you store things in plain text it's difficult to handle that metadata So this is wrong: there are few "metadata" with logs : the "metadata" are part of the log, are stored with the log, they are the actual data for which we generated the log. It has nothing to do with "plain text": structured-logging is a thing, and it is plain text. And writing random english sentences to a mysql database is also a thing, and it is not plain text. And you can move from one to another, just as you can compress a logfile (which is then no longer plain text) etc. So the plain text vs binary is a format issue, and the logs' content is another, unrelated topic So I do not know what's the point here, except saying "journald is awesome", which is just an opinion
- tomsmeding 2y ago
  This is fair. However, I think the situation the OP is complaining about is not one application that does structured logging (where I agree with you that even if the data is "plain text" in some sense, it's not terribly productive to think of it as plain text), but instead about a system log that many unrelated applications write to. Each of those applications has their own way of structuring their logs: there is no standard. Hence you end up with something that is technically plain text, but also really nothing more because there is no consistent structure. So it's really just plain text.

JackSlateur 2y ago

A log entry is composed of many things: some event nature, a user, who sent the entry, when it happened etc The core problem is that log messages themselves almost invariably come with additional metadata, often fairly rich metadata, but if you store things in plain text it's difficult to handle that metadata So this is wrong: there are few "metadata" with logs : the "metadata" are part of the log, are stored with the log, they are the actual data for which we generated the log. It has nothing to do with "plain text": structured-logging is a thing, and it is plain text. And writing random english sentences to a mysql database is also a thing, and it is not plain text. And you can move from one to another, just as you can compress a logfile (which is then no longer plain text) etc. So the plain text vs binary is a format issue, and the logs' content is another, unrelated topic So I do not know what's the point here, except saying "journald is awesome", which is just an opinion

tomsmeding 2y ago
This is fair. However, I think the situation the OP is complaining about is not one application that does structured logging (where I agree with you that even if the data is "plain text" in some sense, it's not terribly productive to think of it as plain text), but instead about a system log that many unrelated applications write to. Each of those applications has their own way of structuring their logs: there is no standard. Hence you end up with something that is technically plain text, but also really nothing more because there is no consistent structure. So it's really just plain text.