Indeed I just figured out that every 40 ms I add a structured record containing the serial frame received, 90% of additional metadata are added, which we don't need in this case (except maybe the timestamp).
Will keep sd-journal pour INFO messages but indeed we need to rework our DEBUG stuff. Thank you for your reply. Le mar. 20 mai 2025 à 13:28, Mantas Mikulėnas <graw...@gmail.com> a écrit : > > 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
