Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage.
I know it can forward to syslog, but at that point I'd rather just have syslog.
systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.
I do.
I want my (e.g.) auth.log rotated regularly and kept forever. Many other things I only care about (say) 4-6 weeks of retention.
(This is in addition to off-host log shipping, which of course journald doesn't do itself so I have to run rsyslog regardlesss.)
I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald.
From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.
you can process millions of lines of plaintext in a tenth of a second using awk
It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.
They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it.
> The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness.
* https://www.linkedin.com/pulse/20140924071300-170035-why-you...
* You get real honest-to-god dependency solving, no more having to number scripts so they run in the right order or working with magic comments.
* .targets are the correct abstraction over runlevels that do what people actually need them to do.
* How journald manages disk finally fixes the stupidity of logrotate edgecases.
* sysusers/tmpfiles is by far by far the best way to manage non-human users and application specific directories.
* The entire system is programmable in real programming languages without having to shell out to system("systemctl start ..."). The whole thing is dbus-first and systemctl is just a client to it like any other.
* You can make your own unit types with systemd-generators if the built-in ones aren't enough for you.
* The system for overrides finally solves the package management bullshit where the init script and the package manager fight.
* Built-in userspace oom killer.
* Makes user sessions a real thing on Linux instead of an ad-hoc set of conventions.
* sd-notify for service readyness checks is fantastic
* Parameterized services!
* Config files and startup behavior are all in the same format; outputters for name daemons, cron jobs, networking, name resolution, NTP, coredumps, mountpoints, and more are all the same. Hand it a data structure with the proper keys and you know it's going to work.
* cgroup and namespace configuration are much more fine grained, flexible, and straightforward than docker. Have a weird vendor service that you'd like to restrict or isolate? you can do that.
* Process management is mostly a solved problem after years of being ignored by POSIX.
* Accounting metrics on memory, tasks, and I/O is for all your services is there
* Shipping to syslog is a breeze.
Yeah, it's got a learning curve but it's objectively better than a bunch of random init scripts. Which you can still use.