You mean boot logging? There are numerous ways to solve this which would have made more sense, including a small change to the linux kernel to make it stop throwing away boot logs when they are large.
The kernel ring-buffer size can be user specified, so no need to ever lose such messages. The problem is that during boot, only messages directed at /dev/kmsg is recorded until rootfs is mounted and syslogd is running. This is hard to do something about since it is a kernel limitation that only one device at the time can own /dev/log. journald catches all messages, including those to /dev/kmsg and /dev/log, and it does this from early boot. So a journal based system will always contain more info than a pure syslog system.
So use syslog-ng, which can be used in place of syslog without changes to other daemons, unlike journald. Which again, is the reason we're even having this conversation.
Regarding silently dropping messages: AFAIK all syslog daemons does this per design (or lack thereof). The main problem is that calls to syslog() would be blocking if implemented in a safe manner.
Wait, you don't care about human-readability, but you don't want the logs to become unreadably long? Make up your fucking mind. You're just making shit up, I can tell because that shit is contradictory.
You misunderstand; a reason why syslog messages doesn't contain monotonic timestamps etc. is that it makes the log entries extremely long and hard to read for humans. It is a kind of limitation of the "design".
journald doesn't have such limitations since it is field based, and the output format is easily adapted to what view you want. If you only want wall time stamps, you can get that, if you want monotonic time stamps, you get that, and only that.
So with the journal, you can add more fields in the future without making the log entries unwieldy, something impossible with syslog.
Regarding human readable: I only care about that for the subset of information I intend to read, and this is exactly what journalctl does. That way you can have logs that are easy to parse for both humans and machines; each consumer gets exactly the view of the data that they want in a form they can use.
that text logs simply don't scale
Still not an argument against text logs, only an argument for also implementing binary logs. And I wouldn't put them into their own shitty files with their own shitty format, I would put them into an RDBMS. Putting them into crappy, easily-corrupted binary log files is just asking for trouble, and guess what? It's causing trouble.
Yes, the scaling thing is a good argument against using flat file text logs. You really need indexes when analysing such huge amount of data, which is exactly what people are doing at the moment; they invest in often proprietary commercial solutions in order to massage their flat text file log data into something usable.
RDBMS have been tried for a long time and they are not a good general purpose solution for local logging. They are also much more prone to corruption than the journal's simpler binary storage format.
What? So now you don't like flat files or regex? Why don't you just fuck off to Windows and let us have our Linux? You clearly don't like Unix.
While regex is a powerful tool, the old joke about trying to solve a problem using regex, and then discover you now have _two_ problems, is true too. Discounting the many variations of regex that each program like grep /egrep uses, it simply becomes unwieldy when you are using regex epressions that are +120 characters long. Making ad hoc queries with regex really is painful when the complexity rises beyond the basics. The systemd journal is so much better regarding this since it is field based. It is so trivial to make complex ad hoc queries without any need of using regex.
Really, stuff like:
"journalctl --since -5m"
"journalctl -b-1 -p warning"
"journalctl /usr/sbin/smartd --since 2015-05-10"
Is so much easier than trying to construct regexes that does the same.