背景

在我们进行软件开发的过程中，日志收集与打印是解决产品发布后查找问题分析问题的主要途径。对于日志收集我们又很多种方法如ELK、EFK，还有我之前发布的轻量级日志收集工具Grafan-Loki。日志收集查看分析有了根据，我们在查看日志的时候通常会因为某个事件触发的一系列日志信息，那么怎么通过一种方式去日志链接起来，这就需要我们进行全日志链路分析了。可以根据trace-ID来查询整个链路的过程

MDC操作

当然针对这种问题很多日志打印的框架都有做出贡献。例如slf4j的MDC就可以将trace-id注入即可。

具体操作说明：

在springboot 中注入一个logUtil的类，为MDC设置trace—ID，我代码使用的requestID

@Component
public class LogUtil {
    private static final String REQUEST_ID="RequestId";

    public static final String COMMON="={}";
    public void autowiredMessageId(String messageId){

            MDC.put(REQUEST_ID, messageId);//将id注入到MDC中
        }
}

定义好后，可以在http请求的filter中获取http中定义好的requestID或则traceID并注入到MDC中。也可以kafka消息队列的消费者中，将消息的messageID注入。

怎么打印那

<property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] [%X{RequestId}]  %logger{50} - %msg%n" />

只需要在lockback.xml中的配置打印格式既可[%X{RequestId}] 就是MDC配置的ID。这样既可以打印了。

MDC存在的问题

在使用的过程中发现，MDC只当前线程有效，对子线程不起作用，requestId没办法进行追踪使用。

Zipkin

Zipkin这里只对其做简要的介绍，zipkin的官网 https://zipkin.io/；

Zipkin 是 Twitter 的一个开源项目，允许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口。Zipkin是一个分布式追踪系统。它有助于收集解决服务架构中的延迟问题所需的时间数据。功能包括收集和查找此数据。

如果您在日志文件中有跟踪 ID，则可以直接跳转到它。否则，您可以根据服务、操作名称、标签和持续时间等属性进行查询。会为你总结一些有趣的数据，比如在服务中花费的时间百分比，以及操作是否失败。

Zipkin UI 还提供了一个依赖关系图，显示有多少跟踪请求通过了每个应用程序。这有助于识别聚合行为，包括错误路径或对已弃用服务的调用。