I do not want to store plaintext logs and use ancient workarounds like logrotate. journald itself has the built-in ability to receive logs from remote hosts (journald remote & gateway) and search them using --merge.
I do not want to store plaintext logs and use ancient workarounds like logrotate. journald itself has the built-in ability to receive logs from remote hosts (journald remote & gateway) and search them using --merge.
As mentioned in the article, my original use case was: having a fleet of hosts, each printing pretty sizeable amount of logs, e.g. having more than 1-2GB log file on every host on a single day was pretty common. My biggest problem with journalctl is that, during some intensive spikes of logs, it might drop logs; we were definitely observing this behavior that some messages are clearly missing from the journalctl output, but when we check the plain log files, the messages are there. I don't remember details now, but I've read about some kind of ratelimiting / buffer overflow going on there (and somehow the part which writes to the files enjoys not having these limits, or at least having more permissive limits). So that's the primary one; I definitely didn't want to deal with missing logs. Somehow, old school technology like plain log files keeps being more reliable.
Second, at least back then, journalctl was noticeably slower than simply using tail+head hacks to "select" the requested time range.
Third, having a dependency like journalctl it's just harder to test than plain log files.
Lastly, I wanted to be able to use any log files, not necessarily controlled by journalctl.
I think adding support for journalctl should be possible, but I still do have doubts on whether it's worth it. You mention that you don't want to store plaintext logs and using logrotate, but is it painful to simply install rsyslog? I think it takes care of all this without us having to worry about it.
Example: I'm running an Arch-based Linux desktop. Installing ryslog took several minutes to build and install. If I wasn't highly motivated to try out nerdlog, I would have canceled the install.
Also, can the SSH requirement for localhost be bypassed? Most users won't be running an SSH server on their desktop, and this would improve nerdlog's use-cases and make it easier for new users to give it a quick local test run.
Final suggestion: add `go get` support to your repo, so that I can install nerdlog from a single command and not have to clone the repo itself.
Just posting it in case you want to subscribe to it. Looks like it's a popular demand indeed, so I'll at least poke it and see what kind of performance we can get out of it.