[logback-user] Recommendations on including manifest implementation information into logging events

Adam Gent adam.gent at snaphop.com
Sun Mar 12 15:48:17 CET 2017


We do this for all of our services. What I recommend is having some
bootstrap code that gets that information and sets it as a
System.properties.

The bootstrap code *needs to run before any logging code* which for some
frameworks can be nontrivial due to the static initialization of SLF4J (and
SLF4J should really have some way to intercept the initial binding but that
would probably hurt startup performance).

If you have control of the entry point (e.g. static main(args)) you can put
the code in there. Again it needs to be done before any call to
LoggingFactory.getLogger()

If you have a servlet container you can use a context listener and register
that listener before all other listeners (otherwise logging code might be
executed before bootstrap). However this only works if your servlet
container does not use SLF4J or Logback (most of them have their own
logging framework but if you configure them to use Logback you won't be
able to set the properties apriori).

Logback (and almost all logging frameworks for that matter) allow you to
get access to the system properties for output but they won't be in the MDC.

To inject the properties into the MDC for your entire application is
extremely specific to the framework you are using.  Basically you need to
go find where threads are created or an entrypoint. You also need to
cleanup your MDC once the thread is released.

For Spring MVC this could be done by subclassing the DispatcherServlet.

For other things you can make a custom ExecutorService and put the required
MDC logic and wire your custom ExecutorService in.

As you can see it is pretty nontrivial to do all of this but I will put a
silver lining in that it is totally worth if you use something like the ELK
stack (google it) or the commercial Splunk or the plethora of logging SaaS
services.

These days other than during development file based logging is completely
dead to me. It is so powerful to search by MDC attributes in ELK and
resolve issues.


On Sat, Mar 11, 2017 at 2:59 PM, Andrew Feller <afeller at bandwidth.com>
wrote:

> Does anyone have recommendations on how to best to add manifest
> implementation information (Implementation-Title, Implementation-Version,
> etc) to logback MDC trivially?
>
> I know this information can retrieved programmatically from a package (
> Package.getImplementationTitle()
> <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html#getImplementationTitle-->,
> Package.getImplementationVersion()
> <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html#getImplementationVersion-->,
> etc), but I'd rather avoid having every application hardcode logic on
> startup to determine this and stash it in MDC for later use.  I would also
> like to avoid hard coding this information within logback.xml /
> logback-spring.xml as the manifest is the source of truth.
>
> Any recommendations would be greatly appreciated!
> --
>
> [image: email-signature-logo.jpg]
>
> *Andy Feller*
>
> Sr. DevOps Engineer
> 900 Main Campus Drive, Suite 500
>
> Raleigh, NC 27606
>
> Bandwidth <http://www.bandwidth.com/>
> <http://www.bandwidth.com/>e afeller at bandwidth.com
>
> _______________________________________________
> logback-user mailing list
> logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>



-- 
CTO
SnapHop (snaphop.com)
(twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt (cell)
781-883-5182
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20170312/cb01c606/attachment.html>


More information about the logback-user mailing list