Is there a robust java.util.logging handler implementation of syslog?

Question

I'm looking into hooking up a 3rd party Java application to our log aggregation/analysis solution (probably Splunk, we haven't finalized our selection yet though). It seems to be easiest to hook the Splunk agent to syslog, so I'm looking for a way to redirect the application logs to a local syslog daemon on the server.

The Java application uses java.util.logging, which unfortunately does not feature a syslog handler out of the box (I believe log4j does, though). Are there any proven libraries to do this? The log load isn't huge (probably 10-20 messages per minute from each process, up to 6 processes per host) but I'm concerned with reliability and durability (e.g. what happens when the daemon is down?...).

Any help would be appreciated...

Ravishment

Answer 1

SLF4J has a bridge for passing java.util.logging events to SLF4J (and hence to log4j or logback) that you could use. It has a performance cost (see the link) but given your load, this shouldn't be a big deal. So you could then use Log4J's SyslogAppender (or better its successor, logback, which also has a SyslogAppender). I do not have any experience with this appender (so this might require some testing) but logback is definitely a reliable library and I know that it can be configured to not print stack traces using the "nopexception" or "nopex" conversion word (in case sending messages when the daemon is down would generate some exception). Coupling this appender with another one (e.g. file based) would allow to not loose any message.

Shortchange

Thank you, but this does not answer the question - I'm looking to hook up an /existing/ Java application which uses JUL, so external libraries are not really useful. – Ravishment

@Tomer I don't know how I missed that. I've update my answer to cover the bridging. – Shortchange

Note that if the existing application uses slf4j internally you may run into trouble (unless there is a separation of classloaders so the feeding back into slf4j does not hit the original slf4j backend) – Theine

Answer 2

Our project is also using java.util.Logging mechanism, so, after spending some time to find the ready Handler implementation for syslog protocol, I ended up by reading RFC 3164 and creating my own implementation http://code.google.com/p/agafua-syslog/

We using it in production, both with UDP and TCP transports. In our case flow of log messages is approximately 1-2 msg per second, so I guess it is probably applicable for your needs.

Cranston

We have decide to use Agafua-Syslog as well, though we needed to make some mods to it and the original code isn't extensible so we ended up copying his code into our own local repo manually and building our own JAR instead of using his directly. He doesn't appear to be maintaining it, so that's not too much of an issue I guess. We took a look at your fork, but it seemed way more complicated than we needed so we just took the easier path down the middle. – Elsworth

Essentially, what we have is a bunch of Glassfish servers with about 6 domains on each and using GF's syslog feature was just logging the events as "hostx" -- when what we really needed was "hostx-domain". So we just added a property ('host') to each domain's logging.properties file and then append that property in the loghandler's logging logic. – Elsworth

And then we wired-up Graylog to enable viewing in the browser, filtering for events, etc – Elsworth

Bane, actually I would like to continue to maintain my project, so if you have a request for features, I would consider implementing them – Cranston

Oh, nice! :) The primary thing (for our specific need) that could make your project better is to allow a way to parameterize the host such that when you log to syslog it doesn't just say "localhost" but rather says "host-1", "host-2", etc. The primary change I made was in SyslogHandler I added a property 'glassfish_domain' and then in the publish() I did "host += "-" + glassfishDomain – Elsworth