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?