anchor.diff:  
   Having this kind of information allows to group logs by user, by request, by processing.
   Remember that logs may be scattered across different servers, on different time periods. 
  -In short, these additional fields allow correlating logs belonging to the same scenario and finding answers to questions like "what was the user X doing when he met this nasty error?"
  +These additional fields allow correlating logs belonging to the same scenario and finding answers to questions like "what was the user X doing when he met this nasty error?"
   
   Let's get back to the example, we saw the MDC stores extra information about logs.
   The MDC is usually based on a thread local variable, this has two drawbacks:
  
positive.code: 2. The information may no be properly transfered from one 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 construct:
  [source,java]
  ----
  try(MDC.MDCCloseable mdc = MDC.putCloseable("userId", "gquintana")) {
  
negative.code:         </encoder>
      </appender>
  ----
  The result is very close as well, even though the fields are named differently:
  [source,json]
  ----
  {
  