[systemd-devel] [PATCH] journalctl: allow customizable output formats

[Daniel P. Berrange]

On Wed, Oct 08, 2014 at 11:53:38PM +0200, Lennart Poettering wrote:
> On Mon, 22.09.14 16:33, Daniel P. Berrange (berrange at redhat.com) wrote:
> 
> > The current '--output FORMAT' argument defines a number of
> > common output formats, but there are some useful cases it
> > does cover. In particular when reading application logs it
> > is often desirable to display the code file name, line number
> > and function name. Rather than defining yet more fixed output
> > formats, this patch introduces user defined output formats.
> > 
> > The format string is an arbitrary string which contains a
> > mixture of literal text and variable subsistitions. Each
> > variable name corresponds to a journal field name. A variable
> > name can be optionally followed by a data type, and in the
> > case of string types, a length limit.
> 
> Hmm, hmm, hmm.
> 
> I am quite afraid about inventing a new template language for this. I
> can see the usecase though, and I sympasize with it.
> 
> I am particularly afraid of the entire type thing. The fact that the
> journal is more or less typeless is after all by design: i really
> didn't want to invent a new type system. Adding this to the formatter
> now, kinda feels like adding it after all, but through the backdoor...
> 
> So, I am not against this in general, but I'd really be careful with
> the language we define here, and try to make this as similar to an
> existing language (like the python/java one Zbigniew mentioned) as we
> can.
> 
> Or even better, we already have a very limited formatting language in
> place, which is the "specifier" logic, that can replace %i, %f and
> such things in unit files, maybe we can build on this, and allow
> specifiers to take a field name as parameter. Then, if we really need
> formatters for different field "types", we could just give them
> high-level characters or so?
> 
> Hmm, also, we already have a really bad formatter in place for the
> journal catalog files (which only replaces @foo@ by the value of field
> foo). We should probably use the same code for this new journalctl
> formatter and the catalog code. In fact the catalog formatter could
> really use some improvement...

Ok, I didn't know about the catalog files until now, so I'll
investigate that and see what I can do about unifying the code
for these two options.

Do you consider the catalog file format to be part of the stable
ABI ?  ie, do we need to preserve support for @foo@  if we took
the "%s{FOO}" approach ?

> Maybe something like this:
> 
> journalctl -O "%t %s{CODE_FILE}:%s{CODE_LINE} %d{_SOURCE_REALTIME_TIMESTAMP}"
> 
> or something like that, where %t would simply map to the timestamp,
> and %s{} maps to a field name, and %d{} the same, but reformats the
> field as timestamp, assuming it is a UNIX timestamp formatted as
> number...
> 
> Or something like that...

Yep, that would work for me. I'll cook up another patch to demonstrate
that approach along with catalog support.

I'm about to be travelling for KVM Forum / LinuxCon so probably won't get
a chance to send an updated patch for a week or two.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|