[systemd-devel] RFC: filter and search journalctl

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 17, 2015 at 10:24:22AM -0400, Anne Mulhern wrote:
> 
> 
> 
> 
> ----- 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 what what happen when the entry is "malformed", i.e. missing some fields?
Would journald reject the message? I don't think this would be useful to
anyone at all. Instead the readers of the message should gracefully adapt
to missing fields.

...
> 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?
MESSAGE_ID is a contrace between the writers of the message and the readers of
the message. The first say: messages with this ID mean ... and have have the
fields ... . There is no need to mark the fields in any other way,
except by documentation or custom.

Zbyszek