[logback-dev] RFC 5424 and Structured Data support.

[Ceki Gülcü]

Ralph Goers wrote:
 > Oh. I never understood the point of logback-access or
 > logback-audit. It just seems like a nice way to make things very
 > complicated. I've glanced at both but never figured out how they could
 > be useful to me. I don't understand what benefit AuditEvent has over
 > LoggingEvent if LoggingEvent can contain some sort of structured data
 > object (as in EventData).  I understand why it is great to provide
 > support for Jetty and Tomcat but it has always seemed odd to me that
 > the support isn't done as a layer on top of logback-classic instead of
 > logback-core. But then, I've never had a good reason to really look
 > very hard at the code in logback-access.

When you can rely on the type of the event you are dealing with, you
can write specialized logic for that type much more easily. This is
pretty basic OO stuff as you can imagine.

 > Again, having to write a whole new module per event type just isn't
 > practical. But then, I don't think you really mean "event
 > type". logback-access and logback-audit certainly can handle more than
 > one kind of "event".

Well, it's kind of a pain in the neck but once you put a structure in
place, such a module, writing code becomes much easier than dealing
with generic types. But I agree with or at least am sympathetic to the
general point.

 > The main issue I faced was there is no good way to pass a data
 > object through SLF4J to the underlying logging implementation. Really,
 > the most significant change I made was to add XLocationAwareLogger to
 > SLF4J to accomplish that, and even that is fairly transparent. I also
 > still haven't looked at Joern's code, but if he is generalizing that
 > to a more generic Message interface then that could be a very good
 > thing. Within Logback the main issue was determining if the first
 > parameter is a StructuredData object. At first I tried adding it to
 > the LoggingEvent but soon realized that would be far more extensive a
 > change. Again, I'm interested to see what Joern has done.

 > One of the main reasons I am enamored with RFC 5424 is that it is a
 > fabulous way of sending serialized event data around without being
 > tied to any particular logging implementation, with the exception of
 > the names of the keys. I don't think sending a throwable with its call
 > stack would be a good idea, but virtually everything else could be
 > captured in structured data such as the mdc (which I am already doing)
 > and even the caller data.  I don't really think of it as a syslog
 > message but as an industry standard way of sending event messages
 > through a system. Using a message bus one can easily inspect the data
 > as it passes through the bus. Plus, I just noticed yesterday that
 > there are two new RFCs, 5674 - Alarms in Syslog and 5675 - Mapping
 > SNMP Notifications to Syslog Messages, that are building on top of the
 > 5424 spec and making it even more useful.  >

RFC 5424 is a big mental leap in the sense that one needs to start
seeing logging events as a map with named fields, with the entailing
changes at the API level. At the same time, and very contradictorily,
it can be viewed as just a new encoding technique, i.e. business as
usual.

Could you, without going into the business details, give an example of
a use case. In particular, I am curious with the kind of
post-processing you do with the logs. Do you do any post processing?