[systemd-devel] journal use case -- advice requested
lennart at poettering.net
Tue Feb 12 19:52:22 PST 2013
On Thu, 31.01.13 22:51, David Strauss (david at davidstrauss.net) wrote:
> We're using a wrapper for sd_journal_print() that adds a few extra
> items before the message: the thread ID and the build ID. This is okay
> for now, but I'd really like to get advice on how to inject those as
> proper fields without adding them manually to every logging call. I'd
> also like to maintain our global log-level support that quickly
> ignores any entries too verbose for the current configuration.
Hmm, so, I definitely want to see this kind of data added. I want the
thread ID, the thread name and also the GNU build ID.
Ideally we'd attach the thread ID from the receiver side, but we cannot
really do that, because there is no sane way to determine that with
current kernels. In the mean time we could attach this on the sender
side, too. But that would make things weird, if we later on do add
receiver side support, since the props would have to live in different
namespaces (one with and one without the "_" prefix that indicates
> I've tried a few approaches short of really arcane macros, but it
> looks like the right stuff just isn't exposed to users of the journal
> library. Rolling out own variadic logging function seems to require
> fill_iovec_sprintf(), but that's private.
> Any suggestions? Or should I explore patching the journal API to make
> it more modular?
Hmm, so, for the case of the thread ID, thread name and GNU build ID I
think we really should figure something good out that we can just to in
libsystemd-journald, for everybody without client intervention.
Now sure what we could do about the field name story though, Kay,
Michal, Zbigniew, ideas?
Regarding the GNU build id, I am not entirely sure how to get this idea
cheaply so that we can just add it implicitly on every invocation...
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel