分布式链路追踪

1. 概述

在项目中随着项目的业务越来越复杂，以及项目的微服务化等，导致平常的项目中出现如:同一次操作日志散乱等现象，对通过查询日志的方式排查问题造成极大困扰.因此迫切需要一种可以追溯当前链路操作日志的手段。

当有效的日志信息不是很明显，我们需要追溯本次操作整个链路的关键信息时,由于日志的散乱，可能在此事上面耗费较大的精力并且结果还可能有误，分布式链路追踪就是为了解决这种情况下出现的。

2. 追踪实现

在分布式链路跟踪中有两个重要的概念：跟踪（trace）和 跨度（ span）。trace 是请求在分布式系统中的整个链路视图，span 则代表整个链路中不同服务内部的视图，span 组合在一起就是整个 trace 的视图。

追踪和跨度的由三个参数实现：TraceId、SpanId、ParentSpanId

TraceId:
日志中每一次操作都有该次操作的唯一TraceId,属于当前操作的所有相关日志都记录了本次的TraceId,回溯的时候只需要通过TraceId就能获取到指定操作的全链路日志信息，这样可以保证获取的信息都是咱们想要的，节省了不少排查问题的精力。
TraceId可以解决项目微服务化下操作日志散乱的现象。

SpanId、ParentSpanId:
在分布式链路跟踪中有两个很重要的概念：跟踪(trace)和跨度(span)。trace是请求在分布式系统中的整个链路视图，Span则代表整个链路中不同服务内部的视图，Span组合在一起就是整个trace的视图。
请求到达每个服务后，服务都会为请求生成SpanId,而随请求一起从上游传过来的上游服务的spanid都会被记录成ParentSpanId,
当前服务生成的 spanid 随着请求一起再传到下游服务时，这个spanid 又会被下游服务当做 pspanid 记录。

通过在访问日志和业务日志里记录的traceid、spanid 和 pspanid 能完整的还原出整个请求的调用链路视图，对错误排查能起到很大的帮助。

3. 使用

上面就是分布式链路跟踪的原理，我们可以自己实现，也可以依赖 opentracing 这种开源的解决方案。一般是在请求到达网关的开始，生成本次请求的traceid 和 在网关服务内的spanid ，将他们放在HTTP 请求头或者RPC调用的元数据里，在调用下游服务时继续向下传递。下游的RESTful API服务的全局路由中间件和RPC服务的拦截器里会接收请求携带的traceid 和生成当次请求在服务内部的spanid，从上游接收到的 spanid 在这里会被转换成 pspanid。除此之外我们甚至可以把 traceid 和 spanid 注入到一些数据库连接池应用里，让记录的慢SQL日志里同样能打上 traceid 和 spanid 信息，为请求的响应过慢提供有效的分析数据。

4. 具体分析

1. 参数CommonPattern中的设置为：
   %d{yyyy-MM-dd HH:mm:ss.SSS}-${PID}-[%X{X-B3-TraceId},%X{X-B3-SpanId},%X{X-B3-ParentSpanId}]-[%thread] %-5level %logger{30} [%file:%line] - %msg%n%rEx{…}

2.一句日志例子：
2022-05-10 13:47:08.167-1-[43a229c4f616ad3c,43a229c4f616ad3c,]-[http-nio-8083-exec-6] DEBUG c.l.b.c.util.SqlInjectionUtils [SqlInjectionUtils.java:29] - 安全验证, 1, false

这篇好文章是转载于：学新通技术网