Much as I like the inference that I've not tried journal, or that I'm immune to new ideas, thanks, thanks very much.
Look, my job is to implement new ideas. I run a datacenter that has 15pb on tier 1 storage, and 28,000 CPUs.
The one thing I care about most is this: getting home to see my children.
The only time I look at logs is if something terrible has gone wrong. Everything else is done by sourcing metrics directly from the components directly (collectd + graphite)
We do ship logs, and yes we have elastic search, but thats far to heavy and far to higher latency to be useful.
So the only real time that I look at logs is when something is horrifically broken, or we cant figure out from the graphs what has gone wrong.
At that time, I do not want to have to remember new syntax to get at what should be text files. (yes signed logs, but lets be honest thats why you ship logs.)
If I got more functionality, then yes I'll be onboard.
However I can't use bash to talk to journal, It only has a C API, which smacks of it being designed for phones and super integrated HPC, not the 95% use case.
Because it uses binary blobs, (And yes, I do love binary, just not for logs) Its a pain in the arse to inspect using a scripting language.
if journalctl _COMM=sshd | tail | grep "something" then;
really nice. also what the fuck is with starting a switch with an _? underscore indicates hidden function. seriously, why is it different to every over log inspection tool?