[slf4j-user] logging common data simply

[Matt Sicker]

Generally, what you're describing isn't necessarily the MDC. It sounds more
like distributed tracing:

http://opentracing.io/
http://zipkin.io/

The MDC/ThreadContext APIs are useful for maintaining contextual data
within threads, but if you want to propagate between microservices or do
any sort of correlation, you'll need to standardize ways on passing that
context data over HTTP, JMS, etc. A couple projects exist out there that
can instrument your IPC with the relevant ids and will send log messages to
a Zipkin collector (or similar):

https://github.com/openzipkin/brave
https://cloud.spring.io/spring-cloud-sleuth/

If this is what you're working on, then I hope this helps! I'm working on a
very similar project at my work right now, so this is all fresh.

On 25 February 2017 at 14:40, Shanholtz, Jeff <jeff.shanholtz at intel.com>
wrote:

> Thanks for the quick responses everyone! Now I know what to start
> researching. :)
>
> -----Original Message-----
> From: slf4j-user [mailto:slf4j-user-bounces at qos.ch] On Behalf Of Ceki
> Gülcü
> Sent: Saturday, February 25, 2017 12:37 PM
> To: User list for the slf4j project <slf4j-user at qos.ch>
> Subject: Re: [slf4j-user] logging common data simply
>
>
> Regarding wrong line numbers shown with your log wrapper, with logback you
> can fix the issue by calling:
>
> LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
> lc.getFrameworkPackages().add("package of log wrapper");
>
> Best regards,
>
> --
> Ceki
>
> On 2/25/2017 21:15, Joachim Durchholz wrote:
> > On 25.02.2017 20:34, Shanholtz, Jeff wrote:
> >> I have a scenario where I have 1, 2, or 3 pieces of data (guids)
> >> which I want to to log with all messages in order to track records as
> >> they traverse their way through a series of microservices.
> >
> > That's a common scenario.
> >
> >> Currently I’ve written my own wrapper class with my own debug, info,
> >> warn, error methods that take these 3 parameters, followed by the
> >> message field, followed by the optional parameters.
> >
> > Any library function that you call will still use the original loggers
> > so you won't know with which of the guids some log message from deep
> > inside a call is associated.
> > This is a real PITA if you have multiple requests executing in parallel.
> >
> >> There must be a better way, plus this has the disadvantage of
> >> rendering the line number useless in log messages because the line
> >> numbers are the line numbers from my log wrapper class, not the
> >> actual code doing the logging.
> >
> > Elliot has the start of the trail right: Use an MDC.
> > The other half of the trail is that formatters have an escape code for
> > extracting data from the MDC (%m if I remember correctly).
> >
> > HTH
> > Jo
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>



-- 
Matt Sicker <boards at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170225/7d459485/attachment.html>