[slf4j-user] logging common data simply

[Matt Sicker]

In log4j-api, you could create your own Message class that has that data
and log via that.

Otherwise, it sounds like you're getting into scope rules and such
regarding the MDC. You could try the NDC for a nested version, but that's a
stack instead of a map, so you'll have to wrap your values in a sort of
tuple.

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

> No, it sounds like what you’re describing isn’t what I’m seeking. I’m
> talking purely about logging. The comment about multiple microservices was
> tangential. We’re using kafka for communicating between the microservices.
> Thanks for the thought though!
>
>
>
> Upon investigating MDC, I don’t think it’ll work very well for my
> scenario. I’m not looking for something that is essentially static or at
> least static over some period of time. I’m looking for more of a local
> variable/transient MDC concept. In other words, if I were to set MDC
> properties in one method and then call another method, that other method
> may want to log different values for the properties (or none of the
> properties for that matter).
>
>
>
> Could I make it work somehow? Probably. I just messed around with one idea
> I had. It would definitely require a standardized approach to logging and
> avoiding use of loggers without doing some MDC interaction or else log
> messages which * shouldn’t* have one or more of the guids will get them
> anyway.
>
>
>
> Unless there’s another way to approach my problem that doesn’t have the
> drawbacks I’m describing, I might be better off sticking with my wrapper
> approach and trying Ceki’s solution for line numbers.
>
>
>
> FWIW here’s the attempt I made at using MDC for my purpose but then I
> realized the potential for problems if someone uses a logger without this:
>
>
>
> *public class *GuidLog {
>     *public static *Log guids(Object xGuid, Object yGuid, String zGuid,
> Log log) {
>         MDC.*put*(*"xGuid"*, xGuid.toString());
>         MDC.*put*(*"yGuid"*, yGuid.toString());
>         MDC.*put*(*"zGuid"*, zGuid.toString());
>         *return *log;
>     }
> }
>
> GuidLog.*guids*(xGuid, yGuid, zGuid, *logger*).info(*"My log message"*);
>
>
>
>
>
> *From:* slf4j-user [mailto:slf4j-user-bounces at qos.ch] *On Behalf Of *Matt
> Sicker
> *Sent:* Saturday, February 25, 2017 1:55 PM
>
> *To:* User list for the slf4j project <slf4j-user at qos.ch>
> *Subject:* Re: [slf4j-user] logging common data simply
>
>
>
> 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>
>
> _______________________________________________
> 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/1a9f09bc/attachment.html>