[slf4j-user] logging common data simply

Shanholtz, Jeff jeff.shanholtz at intel.com
Sun Feb 26 01:14:44 CET 2017


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<mailto: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<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<mailto: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<tel:25.02.2017%2020>: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<mailto:slf4j-user at qos.ch>
http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
slf4j-user at qos.ch<mailto:slf4j-user at qos.ch>
http://mailman.qos.ch/mailman/listinfo/slf4j-user



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


More information about the slf4j-user mailing list