I don't know about journald's design performance, but at "every 40ms", I'd probably second the suggestion to switch to something else for DEBUG-level stuff (while perhaps keeping regular journald for regular INFO messages), although instead of periodic-rotation-based logs consider some kind of "ring buffer" system – it doesn't sound like you need to poke a complex external process (be it journald or rsyslogd or anything else) if you could instead directly mmap the log file.
That being said, sd_journal_stream_fd_with_namespace() does exist; it's the function used to set up a flat "stdout logging" stream (no metadata, no complex protocol). Regular messages likely aren't bound to a single namespace but the libsystemd API is hardcoded to connect to the "main" journal socket (which systemd overmounts if the unit declares a different namespace). You could manually connect to a separate instance's socket and implement https://systemd.io/JOURNAL_NATIVE_PROTOCOL/ yourself if you want to stress test it. On Tue, May 20, 2025 at 11:13 AM Etienne Doms <etienne.d...@gmail.com> wrote: > Hi, > > We're developing an embedded application which is run through a > systemd service, and we use sd-journal for logging. > > We just figured out that something is not scaling up: we log at INFO > level things like "user pushed that button so we did that" (which > occurs once in a while) and at DEBUG level "received that frame from > /dev/ttyUSB42" which occurs every 40ms on various serial lines. There > is no I/O issue since we use Storage=volatile, but the journal is > rotating way too fast. > > At first sight, it seems we just need to dynamically enable/disable > DEBUG messages but the problem is that we can't: in the wild, the > operator of our system can press a "something went wrong" button which > basically does a journal export that we can inspect later, and > obviously we can't predict when a problem is about to happen... > > So basically, we need to be able at any time to persist one hour of > INFO messages and the last five minutes of DEBUG messages. From what I > understood, the retention strategy is global to a systemd-journald > instance, I read about sd-journal namespaces, and my first intent was > to log INFO stuff in the system journal and DEBUG stuff in dedicated > namespaces (maybe one per serial lines), so I've been looking for some > sd_journal_print_with_namespace() or sd_journal_sendv([MESSAGE="foo", > NAMESPACE="bar"])... > > Now, two questions: > > * What I'm looking for does not exist, a systemd unit is bound to a > single journal namespace, and it's actually the .service that defines > to which namespace the application logs. Am I right? To achieve what I > want, I need to split my application into several services? > * Is systemd-journald designed so that it can record hundreds (if not > thousands...) of records per second? > > $COLLEAGUE proposed to switch to rsyslog, but I'd like your reading about > this. > > Thanks in advance, > Etienne >
