anchor.diff:  ----
   21:10:29.178 [Thread-1] gquintana INFO  logodissey.DemoLogger - Hello world!
   ----
  -The `MDC.remove` (or `MDC.clear`) call is necessary to clean the MDC after usage and avoid leaving information for later logs.
  +The MDC can store information about the user (user Id, session Id, token Id), about the current request (request Id, transaction Id), about long running threads (batch instance Id, broker client Id). 
  +Later on, this information will be part of the log.
  +
  +Having this kind of information allows to group logs by user, by request, by processing.
  +Remember that logs may be scattered across differents servers, on different time periods. 
  +In short having something to correlate logs is important.
  +
  +Let's get back to the example.
  +The MDC is stores extra information about logs.
  +It is usually based on a thread local variable, this  means two things:
  +
  +1. It must be properly cleaned after being used, or you may experience information leaks if the thread is reused (thread pools).
  +2. The information may no be properly transfered from thread to another. Think about asynchronous calls.
  +
  +As a result calling `MDC.remove`, like the above example, (or `MDC.clear`) is required to clean the MDC after usage.
   To avoid forgetting to do housekeeping afterwards, we can use a try-with-resource:
   [source,java]
   ----
  
positive.code: ----
  Hopefully, this kind of code won't make its way in your business code because, it is usually hidden in an interceptor like a Servlet filter, a Spring aspect. In Logback, there is a `MDCInsertingServletFilter` class which can be used as an example.
  
  The MDC can store information about the user (user Id, session Id, token Id), about the current request (request Id, transaction Id), about long running threads (batch instance Id, broker client Id). 
  Later on, this information will be part of the log.
  
  By the way, as the MDC is usually stored as a thread local variable.
  This means two things:
  
  1. It must be properly cleaned after being used, or you may experience information leaks if the thread is reused (thread pools).
  2. The information may no be properly transfered from thread to another. Think about asynchronous calls.
  
  == JSON logging with Logback contrib
  
  
  
  == JSON logging with Logback Logstash layout
  
negative.code: :published_at: 2017-12-01
  :hp-tags: java
  :hp-image: /images/logos/slf4j.png
  
  I stumbled upon the term "structured logging" reading https://kartar.net/2015/12/structured-logging/[a 2015 blog post by James Turnbull].
  It's not a new concept. 
  I discovered Python developpers had a library dedicated to *structured logging*: http://www.structlog.org[structlog].
  
  In this article I will describe what can be done in Java with usual logging libraries like SLF4J et Logback.
  
  == Structured logging with SLF4J
  
  