[systemd-devel] Filtering / routing messages to different journal namespaces
Hannu Lounento
hannu.lounento at vaisala.com
Mon Mar 20 08:25:06 UTC 2023
Hi,
My question would be: is using journal namespaces like described below a
reasonable approach or abusing the namespace concept? If reasonable,
would it be possible to extend the `sd_journal` API -- more specifically
`sd_journal_send` or alike as we'd need to add structured data to the
entries -- to support writing to a selected namespace?
We have an embedded system where we would like to treat a few categories
of log messages differently: some should be persisted for later
retrieval, some sent to an external system (e.g. over the syslog
protocol) immediately, and the rest / most messages should be stored in
memory to minimize flash wear.
Furthermore, some messages (from either proprietary or especially 3rd
party components) should be decorated with additional metadata in
addition to one of the aforementioned persistence actions. A single
process may produce log messages that fall into different categories.
One option that we're considering is running journal namespaces with
different storage configurations for the different categories of
persistence (but still have all applications log to the default
namespace), and a separate filtering component (either proprietary or
some 3rd party log / filtering daemon possibly with custom plugin(s))
that would basically follow the default namespace journal, decorate
matching messages and forward them as necessary to other journal
namespace(s) for local persistence or other sinks for other storage
actions like sending to a remote system.
This design, however, would require the filtering component to be able
to write to the desired journal namespace each message is targeted to,
which doesn't seem to be possible with the current `sd_journal` API [1]
(please let us know if this is incorrect). I assume the usual case is to
route all logging from a given unit directly to a single namespace
according to LogNamespace= [2] configured for the unit.
A fallback option would of course be to implement a custom storage for
the persisted messages if nothing else fits the use case, but we'd
preferably take advantage of systemd-journald's features including e.g.
structured log entries, rotation & other storage options, and the
`sd_journal` API for reading and filtering messages.
[1] https://www.freedesktop.org/software/systemd/man/sd-journal.html
[2]
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LogNamespace=
Thanks,
Hannu Lounento
hannu.lounento at vaisala.com
More information about the systemd-devel
mailing list