Approaches to implement RFC5424 structured data support
Hi there, I was wondering whether anyone has so far been successful in implementing RFC5424 [1] structured data syslog support using logback (despite it probably being DOA [2] - the alternatives are IMHO currently in a too early stage). In the archives I see one attempt at a pretty invasive approach that altered the logback implementation itself (unfortunately, the fork over at Github seems to be no longer maintained) as well as a proposal [3] to use a custom encoder along with a special "RFC5424Aware" interface. Would the latter still be the preferred way to go? Reading through the code, I guess a custom Layout (that knows how to deal with RFC5424Aware instances) should also do the trick... I guess one would also need to replace SyslogStartConverter due to the changed message header... Any input is appreciated! Thanks, Thilo [1] http://tools.ietf.org/html/rfc5424 [2] http://www.gossamer-threads.com/lists/rsyslog/users/6361 [3] http://mailman.qos.ch/pipermail/slf4j-dev/2010-March/002878.html
As you noted this subject has come up before. It was one of the things that ultimately motivated me to go off and create Log4j 2. I abandoned the fork at Github when it became clear that there wasn't going to be a good resolution to the issue. I'm not sure what value the second link has. I've gotten RFC 5424 to work with several systems including Splunk, rsyslog and syslog-ng. FWIW, my use case is Apache Log4j 2 Flume Appender -> Apache Flume -> Apache Cassandra. What is interesting here is that while RFC 5424 isn't strictly necessary for Flume integration, structured data is, at least for what we are using it for. Ralph On Jun 18, 2012, at 4:28 AM, Thilo-Alexander Ginkel wrote:
Hi there,
I was wondering whether anyone has so far been successful in implementing RFC5424 [1] structured data syslog support using logback (despite it probably being DOA [2] - the alternatives are IMHO currently in a too early stage). In the archives I see one attempt at a pretty invasive approach that altered the logback implementation itself (unfortunately, the fork over at Github seems to be no longer maintained) as well as a proposal [3] to use a custom encoder along with a special "RFC5424Aware" interface.
Would the latter still be the preferred way to go? Reading through the code, I guess a custom Layout (that knows how to deal with RFC5424Aware instances) should also do the trick...
I guess one would also need to replace SyslogStartConverter due to the changed message header...
Any input is appreciated!
Thanks, Thilo
[1] http://tools.ietf.org/html/rfc5424 [2] http://www.gossamer-threads.com/lists/rsyslog/users/6361 [3] http://mailman.qos.ch/pipermail/slf4j-dev/2010-March/002878.html _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
On 18.06.2012 18:53, Ralph Goers wrote:
As you noted this subject has come up before. It was one of the things that ultimately motivated me to go off and create Log4j 2. I abandoned the fork at Github when it became clear that there wasn't going to be a good resolution to the issue.
I've got to admit, payload support in SLF4J/logback is pretty bad. -- Ceki http://twitter.com/#!/ceki
On Mon, Jun 18, 2012 at 6:53 PM, Ralph Goers <rgoers@apache.org> wrote:
As you noted this subject has come up before. It was one of the things that ultimately motivated me to go off and create Log4j 2. I abandoned the fork at Github when it became clear that there wasn't going to be a good resolution to the issue.
For now I went for an approach using a custom Appender (that inherits from SyslogAppenderBase), a new ClassicConverter for the syslog header and another ClassicConverter for the structured data. The latter needs to inspect the ILoggingEvent's argument array for the presence of a special interface, which is a little ugly, but technically works...
I'm not sure what value the second link has.
Me neither. ;-)
I've gotten RFC 5424 to work with several systems including Splunk, rsyslog and syslog-ng. FWIW, my use case is Apache Log4j 2 Flume Appender -> Apache Flume -> Apache Cassandra. What is interesting here is that while RFC 5424 isn't strictly necessary for Flume integration, structured data is, at least for what we are using it for.
For now I "just" need to feed structured data into rsyslog, but this is probably going to change some time. Thanks, Thilo
participants (3)
-
ceki -
Ralph Goers -
Thilo-Alexander Ginkel