[systemd-devel] RFC: filter and search journalctl

[Anne Mulhern]

----- Original Message -----
> From: "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
> To: "Sebastian Schindler" <sebastian.schindler at travelping.com>
> Cc: systemd-devel at lists.freedesktop.org
> Sent: Saturday, August 8, 2015 3:48:30 PM
> Subject: Re: [systemd-devel] RFC: filter and search journalctl
> 
> On Fri, Aug 07, 2015 at 11:53:13AM +0200, Sebastian Schindler wrote:
> > Grep-ing seems to be the only solution to find log entries if you don't
> > fully
> > know what you're looking for. For example: You want to see all entries
> > containing a certain MESSAGE that gets enriched with additional information
> > during the logging process:
> > 
> > MESSAGE=host <HOST> has closed connection <CONNECTION_ID>
> This is a bit contentious, but at least I would like to see some
> grep functionality implemented directly in journalctl.
> 

I am late to the party, but I think it is obvious that the "right" way for this
to be achieved, in a perfect world, is that this log entry be accompanied
by a MESSAGE_ID, and HOST and CONNECTION_ID keys, and a catalog entry that combined
with the keys, generates the above message so that grepping is entirely
unnecessary.

It is true that this perfect world is not just around the corner, or anything like that,
but it is technically possible.

I agree that grepping would be handy for me, right now, for just the reasons stated
in the original message.

I wonder if it would be reasonable for journalctl to supply the (additional) fields that are
guaranteed to be associated with a MESSAGE_ID, and how this information might
be registered. One way is to essentially derive this from an associated catalog
entry, if any. Any fields that the catalog entry uses really ought to be supplied
along w/ the MESSAGE_ID. This mapping is available to any human being, of course, by
inspecting journal entries.

But it also seems likely that there might be fields that
should be guaranteed to accompany a MESSAGE_ID that should not be incorporated into
a catalog message. I would be interested in the idea of, e.g., extending the format of
the catalog file that an application distributes to allow an extra line that specifies
guaranteed fields, or alternatively, to allow an additional file, dedicated to specifying
this interface. This is a bit analogous to the interface file that is specified for
foreign language bindings for a library.

I'm also curious about a mechanism to distinguish those entries that are supplied
specifically for a particular MESSAGE_ID from those that are, e.g., auto-generated
by systemd or derived from some other sources. systemd has already taken the underscore
for the unfakeable entries it provides. Is it reasonable to preface any MESSAGE_ID
specific keys with the MESSAGE_ID, e.g.,
"9bb33380-fbfa-4d5b-88b5-6e6bb8a39124:KEY"? Or perhaps a double underscore, e.g.,
"__KEY" would do the trick?

<-- SNIP -->

> 
> Zbyszek
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

- mulhern