Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the ‘fanciness’. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an ‘old fashioned’ way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.
We have only one week of very sparse logs in it, yet it takes several seconds… greping tens of gigabytes of logs can be sometimes faster. That is insane.
Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the ‘fanciness’. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an ‘old fashioned’ way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.
Plain text is slow and cumbersome for large amounts of logs. It would of had a decent performance penalty for little value add.
If you like text you can pipe journalctl
But if journalctl is slow, piping is not helping.
We have only one week of very sparse logs in it, yet it takes several seconds… greping tens of gigabytes of logs can be sometimes faster. That is insane.
Strange
Probably worth asking on a technical