I can't help but notice that most of these flags seem to solve self-inflicted problems that don't occur with plaintext logfiles. Why have a special grep flag instead of, yaknow, piping through grep? (A: because journalctl is slow). Why special flags to load different categories of log? (A: because all the logs are mixed together in a big blob). Why a special flag to load logs from a container, and another different(!) special flag to load logs from a mounted system? (A: because journalctl throws away the logfile metaphor).

I don't know what "boot indices" are, but your other commands with plaintext are as follows:

dmesg or cat /var/log/whatever

grep <pattern> /var/log/whatever

cat /mnt/host/var/log/whatever

cat /mnt/container/var/log/whatever

> Why have a special grep flag instead of, yaknow, piping through grep? (A: because journalctl is slow).

No, because it only matches the message field, so you're not grepping anything extraneous like the timestamp or service name. This is also convenient if you want JSON output, which includes a bunch of extra stuff | grep might match.

The performance argument makes no sense, because if it's slow, then --grep will also be. Any slowness is likely before things get to that point.

> Why special flags to load different categories of log? (A: because all the logs are mixed together in a big blob).

And that's a good thing, because it means you can mix everything together and see the interactions between the different parts of the system in the order they happened. And this can be achieved by logging everything only once, rather than having duplicated logs for such an use case.

> (A: because journalctl throws away the logfile metaphor).

That's also a good thing IMO because I don't really care about the details of log storage. Whether a log is named this or that, and is compressed or not, and if the data I need is in .log or .log.1 or .log.4.gz is all a distraction from my actual need -- seeing a particular set of data. The fact that I can just get the log files from Apache from a given date, regardless of what file that happens to be stored in is a good thing.

> I don't know what "boot indices" are, but your other commands with plaintext are as follows:

Per-boot log classification. You can easily ask for the logs since the last time the machine booted, or what happened during the previous boot, and so on. And the list shows timestamps, so you can tell at a glance that the machine last rebooted today, and has been rebooting every 3 hours as of late.

This is very useful if the machine say, crashed and rebooted at some point. So you can just ask for journalctl -b -1, which will give you the log of the previous boot until the crash. You don't have to do any grepping to figure out where is that in the logs, because the system can trivially give you that.

Except that whatever is absolutely not trivial to find. Is it per service/day? What if it was rotated before? How do you look at the logs from the boot before the current?

If it is per service, will you grep the service name? It will have many false positive lines. Raw data is not too useful.