In 10 years, though, reading recent bug reports, I can see that the project's leads have grown out of it, largely.
Case in point, they had recently put a bug into a 24x release that made a lot of machines, including mine, unbootable, but the fix was just as quick.
IMO Lennart is right in that collection should be optimized to a point where it is (almost) never the bottleneck. I, personally, would put a filtering program between the chatty application and journald.
- Legacy application, with no access to source code.
- Company that wrote the application hasn't existed for a decade.
- It logs several useless lines every second. This is non-configurable, and includes a timestamp which makes each linue distinct.
- It also logs some very important lines that _must_ be responded to.
I don't think this is a unique situation to find yourself in, and currently this application is permitted - explicitly - to spam the journal to a point that it is effectively useless. Yes, you can use a filtering application to sit in between systemd but that's a workaround and not an actual solution (as stated in the issue linked above):
- it could not be "plugged in" via overlay (i.e. modification of Exec... is needed - this gets ugly especially if you have ExecStartPre/ExecStopPost)
- SyslogIdentifier has to be set to produce proper name in journald
- The filter itself has to be quite reliable (to not hang) and a bit sophisticated to properly handle signals, process shutdown, low disk space etc.
Rate limiting works, but it’s a pretty blunt instrument and can lead to losing your actually valuable entries vs capturing garbage.
