----- Original Message -----
> From: "Zbigniew Jędrzejewski-Szmek" <zbys...@in.waw.pl>
> To: "Sebastian Schindler" <sebastian.schind...@travelping.com>
> Cc: systemd-devel@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
- mulhern
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
