Au contraire, plain text is just about the only format for logs that works. Having to use some obscure tool to query logs just isn't worth it, especially not in

Au contraire, plain text is just about the only format for logs that works. Having to use some obscure tool to query logs just isn't worth it, especially not in 20 years time, when you still need to analyze said logs but the tool doesn't even run on any contemporary systems anymore and the documentation about the binary format has been irretrievably lost. And yeah, sure, you want to use structured logging. So, in addition to the greppable log message, include a Magic Separator Character (say, \t) that you treat as 'end-of-line' in human-oriented processing, and have your key-value-pair structured data following that for automated tooling to have its way with. Or, be really creative with [key=value] blocks that are both human- and machine-readable. Some of my most painful logging experiences were having to extract application logs from binary blobs created by a proprietary Windows tool (no, not the main Windows event log: that's bad, but at least documented). Even the most recent versions of the official viewer just crashed, the vendor was not interested in fixing that (since we were not a customer, just a third party in need of log data, but even an offer of a modest payment was met with indifference...), and the actual format turned out to be byzantine beyond words. So, yeah, give me plain text all day, every day...