As I said, I’ve dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it’s easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.
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.
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
As I said, I’ve dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it’s easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.
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