| 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? |