一、为什么你需要Zipkin与日志联动
1.1 微服务时代的排障困境
在微服务架构盛行的今天，一个看似简单的用户操作，背后可能涉及十几个甚至几十个服务的串联调用。比如下单这个动作，系统要校验库存、查询用户信息、计算优惠、调用支付、发送通知，每一环都可能出问题。当用户反馈"我下单没成功"的时候，你要从几十个服务的日志里一条条翻，找到到底是哪一步出了岔子，这就像大海捞针一样让人崩溃。
1.2 单独使用日志或链路追踪的局限
只用日志系统有个大麻烦：日志是按服务分散存储的，你没法直观看到一个请求在各个服务间的完整路径，也没法判断时间线上哪个环节花了多少时间。你可能会翻A服务的日志看到一条报错，再去翻B服务的日志，但是A服务调用B服务的那条日志和B服务接收到的那条日志，它们之间的关联关系全靠人脑去拼。
而Zipkin这类链路追踪工具虽然能清楚地展示一个请求的完整调用链路和每一段耗时，但它的信息粒度比较粗，更多是告诉你"这里慢了"或者"这里报错了"，具体的错误详情、上下文信息、业务参数等细节还是得回到日志里去找。如果日志里没有带上链路标识，Zipkin告诉你某个Span异常了，你回到日志系统里还是不知道对应哪条日志。
两者联动之后，排查效率会提升非常多。在Zipkin里发现某段调用耗时异常或报错了，点击Span详情，直接通过TraceId跳转到日志系统里检索对应的日志，精确命中那几条关键日志，问题定位速度从小时级降到分钟级。
二、Zipkin与日志联动的基本原理
2.1 TraceId与SpanId的核心概念
在深入联动方案之前，先把两个核心概念搞清楚。TraceId可以理解为一个"请求的全局身份证号"，从请求进入系统的第一个服务开始生成，后续所有被调用的下游服务都共享同一个TraceId。一个TraceId对应一次完整的业务调用链，比如"用户下单"这一整个流程。
SpanId则是TraceId下的"局部编号"。每一次服务内部的独立操作（比如一次数据库查询、一次HTTP调用）都会产生一个SpanId。一个TraceId下面有多个SpanId，每个SpanId记录了这个独立操作的开始时间、结束时间、耗时、状态码、错误信息等等。
简单理解：TraceId是整条链路的身份证，SpanId是链路中每个小环节的编号。
2.2 日志中嵌入链路标识的机制
联动的核心思路其实很简单：在日志输出的时候，把当前请求的TraceId和SpanId也一并输出到日志内容里。这样当你在Zipkin里发现某个Span有问题时，直接拿那个TraceId去日志系统里搜索，就能找到对应的所有日志条目。
实现这个机制的关键在于SLF4J的MDC（Mapped Diagnostic Context）功能。MDC允许你在线程上下文中附加键值对，日志框架在输出日志时会自动把这些键值对渲染到日志格式中。你只需要在请求进入的时候把TraceId和SpanId放进MDC，然后在日志格式的pattern里加上对应的占位符就行。
2.3 数据流转的整体架构
整个联动方案的架构大致是这样的：
请求进入网关层时，如果请求头里没有TraceId就生成一个新的，然后放进请求上下文中。服务间调用时，当前服务的TraceId和SpanId会通过HTTP请求头传递给下游服务。每个服务接收到请求后，把TraceId和SpanId提取出来放进MDC，这样日志输出时就会自动带上这些信息。同时，每个服务也会把Span信息上报到Zipkin Server，Zipkin Server把这些信息聚合起来，形成一个完整的Trace视图。
排查问题时，你在Zipkin UI上看到某段调用有问题，复制TraceId，去日志系统里搜索这个TraceId，就能找到所有相关日志。如果日志系统（比如ELK）支持链接跳转，还可以直接配置从Zipkin一键跳转到日志页面。
三、实战搭建：基于Spring Boot + Java的联动方案
3.1 环境准备与技术栈说明
下面所有的示例统一基于以下技术栈：
- Java 17
- Spring Boot 3.2.x
- Spring Cloud 2023.x
- Spring Cloud Sleuth 3.x（或Spring Boot 3中已集成Micrometer Tracing）
- Zipkin Server 3.x
- SLF4J + Logback
这套技术栈是当前Spring生态下最主流的链路追踪和日志方案。如果你用的是Spring Boot 2.x，Sleuth的使用方式类似，但依赖坐标和配置前缀略有不同，本文以3.x为准。
3.2 引入Zipkin依赖配置
首先在pom.xml中引入必要的依赖。Spring Boot 3.x中，链路追踪功能由Micrometer Tracing接管，不再需要单独的Sleuth依赖。
<!-- pom.xml -->
<project>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.2.0</version>
<relativePath/>
</parent>
<groupId>com.example</groupId>
<artifactId>order-service</artifactId>
<version>1.0.0</version>
<dependencies>
<!-- Spring Boot Web Starter，提供REST服务基础能力 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Micrometer Tracing，Spring Boot 3中链路追踪的核心依赖 -->
<!-- 它会自动收集Span信息并上报到Zipkin -->
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<!-- Zipkin Reporter，负责把Span数据发送到Zipkin Server -->
<dependency>
<groupId>io.zipkin.reporter2</groupId>
<artifactId>zipkin-reporter-brave</artifactId>
</dependency>
<!-- Logback，Spring Boot默认的日志实现 -->
<!-- 这里不单独引入，starter-web已经包含了 -->
<!-- Spring Boot Actuator，暴露健康检查和环境信息等端点 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
3.3 日志配置中嵌入TraceId
接下来配置日志格式，让每条日志都自动带上TraceId和SpanId。修改src/main/resources/logback-spring.xml：
<!-- logback-spring.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- 控制台输出配置 -->
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<!--
日志格式说明：
%d{yyyy-MM-dd HH:mm:ss.SSS} - 时间戳
%5level - 日志级别，右对齐占5位
[%thread] - 线程名
%logger{36} - 日志记录器名称（类名），最多36个字符
[%X{traceId}] - 从MDC中取出traceId并输出
[%X{spanId}] - 从MDC中取出spanId并输出
: %msg%n - 日志消息 + 换行
-->
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %5level [%thread] %logger{36} [traceId=%X{traceId}] [spanId=%X{spanId}] : %msg%n</pattern>
</encoder>
</appender>
<!-- 文件输出配置，生产环境建议用 -->
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>/var/log/order-service/application.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- 按天滚动，保留30天日志 -->
<fileNamePattern>/var/log/order-service/application.%d{yyyy-MM-dd}.log</fileNamePattern>
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %5level [%thread] %logger{36} [traceId=%X{traceId}] [spanId=%X{spanId}] : %msg%n</pattern>
</encoder>
</appender>
<!-- 根日志级别设为INFO -->
<root level="INFO">
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
</configuration>
这里%X{traceId}和%X{spanId}就是从MDC中取值的关键。只要你的代码里有往MDC放入traceId和spanId，日志就会自动带上。Spring Boot 3的Micrometer Tracing会自动帮你把traceId和spanId放入MDC，但有时候你需要手动补充一些额外信息。
3.4 服务间调用传播TraceId
Spring Cloud的OpenFeign或者RestTemplate在调用下游服务时，会自动把当前的TraceId和SpanId通过HTTP请求头传递过去。下游服务接收后会自动生成新的SpanId（继承同一个TraceId），这样就保证了整条链路的TraceId一致。
我们来看一个完整的服务示例。假设我们有一个"订单服务"（order-service），它会调用"库存服务"（inventory-service）和"用户服务"（user-service）。
3.4.1 订单服务启动类
// OrderServiceApplication.java
// 订单服务启动类
package com.example.orderservice;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.openfeign.EnableFeignClients;
import org.springframework.scheduling.annotation.EnableAsync;
/**
* 订单服务 - 业务入口
*
* @EnableFeignClients: 开启Feign客户端功能，用于调用下游服务
* @EnableAsync: 开启异步方法支持，演示异步场景下TraceId的传递
*/
@SpringBootApplication
@EnableFeignClients
@EnableAsync
public class OrderServiceApplication {
public static void main(String[] args) {
SpringApplication.run(OrderServiceApplication.class, args);
}
}
3.4.2 订单服务配置文件
# application.yml - 订单服务配置
server:
port: 8081
spring:
application:
name: order-service
# Zipkin Server地址，所有Span数据都会发送到这个地址
# 确保Zipkin Server已启动并运行在9411端口
spring.zipkin:
base-url: http://localhost:9411
# 服务发现的配置（如果用Eureka/Nacos做服务发现）
# 这里用直连地址做演示，生产环境配合注册中心使用
management:
tracing:
sampling:
# 采样率设为1.0表示100%采样
# 生产环境建议根据实际情况调低，比如0.1即10%采样
probability: 1.0
endpoints:
web:
exposure:
include: health,info,threaddump
# Feign超时配置
feign:
client:
config:
default:
connectTimeout: 5000
readTimeout: 5000
# 日志配置
logging:
level:
com.example: DEBUG
3.4.3 定义Feign客户端调用下游服务
// InventoryFeignClient.java
// Feign客户端 - 调用库存服务
package com.example.orderservice.client;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestParam;
/**
* 库存服务Feign客户端
*
* @FeignClient注解说明：
* name/value: 下游服务名称，用于服务发现或直连
* url: 如果不用注册中心，可以直接指定地址
*/
@FeignClient(name = "inventory-service", url = "http://localhost:8082")
public interface InventoryFeignClient {
/**
* 查询商品库存
*
* @param productId 商品ID
* @return 库存数量
*/
@GetMapping("/inventory/{productId}")
Integer checkInventory(@PathVariable("productId") Long productId);
/**
* 扣减库存
*
* @param productId 商品ID
* @param quantity 扣减数量
* @return 操作结果
*/
@GetMapping("/inventory/deduct")
Boolean deductInventory(@RequestParam("productId") Long productId,
@RequestParam("quantity") Integer quantity);
}
// UserFeignClient.java
// Feign客户端 - 调用用户服务
package com.example.orderservice.client;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
/**
* 用户服务Feign客户端
*
* 同样使用@FeignClient注解声明下游服务
*/
@FeignClient(name = "user-service", url = "http://localhost:8083")
public interface UserFeignClient {
/**
* 查询用户信息
*
* @param userId 用户ID
* @return 用户信息
*/
@GetMapping("/user/{userId}")
UserInfoDTO getUser(@PathVariable("userId") Long userId);
}
// UserInfoDTO.java
// 用户信息数据传输对象
package com.example.orderservice.client;
/**
* 用户信息DTO - 与用户服务返回的结构对应
*/
public class UserInfoDTO {
private Long userId;
private String userName;
private String phone;
// 构造函数、getter和setter省略
public UserInfoDTO() {}
public UserInfoDTO(Long userId, String userName, String phone) {
this.userId = userId;
this.userName = userName;
this.phone = phone;
}
public Long getUserId() { return userId; }
public void setUserId(Long userId) { this.userId = userId; }
public String getUserName() { return userName; }
public void setUserName(String userName) { this.userName = userName; }
public String getPhone() { return phone; }
public void setPhone(String phone) { this.phone = phone; }
}
3.4.4 订单服务核心业务逻辑
// OrderService.java
// 订单服务核心业务类
package com.example.orderservice.service;
import com.example.orderservice.client.InventoryFeignClient;
import com.example.orderservice.client.UserFeignClient;
import com.example.orderservice.client.UserInfoDTO;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;
/**
* 订单服务核心逻辑
*
* 这里演示了TraceId在同步调用、异步调用、异常场景下的传递情况
*/
@Service
public class OrderService {
// 获取日志实例，Logback会自动应用logback-spring.xml中的pattern
private static final Logger log = LoggerFactory.getLogger(OrderService.class);
private final InventoryFeignClient inventoryClient;
private final UserFeignClient userClient;
// 构造函数注入，推荐使用
public OrderService(InventoryFeignClient inventoryClient, UserFeignClient userClient) {
this.inventoryClient = inventoryClient;
this.userClient = userClient;
}
/**
* 创建订单 - 模拟完整的下单流程
*
* 整个方法内产生的日志都会带上同一个traceId
* 每次Feign调用会自动生成新的span，但共享同一个traceId
*
* @param userId 用户ID
* @param productId 商品ID
* @param quantity 购买数量
* @return 订单号
*/
public String createOrder(Long userId, Long productId, Integer quantity) {
// 进入下单方法时记录日志
// 这条日志中traceId是请求级别的，整个下单流程共享
log.info("开始创建订单, userId={}, productId={}, quantity={}", userId, productId, quantity);
try {
// 第一步：查询用户信息
// Feign调用会自动传播traceId到user-service
UserInfoDTO user = userClient.getUser(userId);
if (user == null) {
log.warn("用户不存在, userId={}", userId);
throw new RuntimeException("用户不存在");
}
log.info("用户信息查询成功, userName={}", user.getUserName());
// 第二步：检查库存
// 这个调用也会自动带上traceId
Integer stock = inventoryClient.checkInventory(productId);
log.info("库存检查完成, productId={}, stock={}", productId, stock);
if (stock < quantity) {
log.error("库存不足, 需要={}, 实际={}", quantity, stock);
throw new RuntimeException("库存不足");
}
// 第三步：扣减库存
Boolean deducted = inventoryClient.deductInventory(productId, quantity);
if (!deducted) {
log.error("库存扣减失败, productId={}, quantity={}", productId, quantity);
throw new RuntimeException("库存扣减失败");
}
log.info("库存扣减成功");
// 第四步：生成订单（这里模拟数据库操作）
String orderNo = generateOrderNo(userId);
log.info("订单创建成功, orderNo={}", orderNo);
// 第五步：异步发送通知（这里演示异步场景）
// 注意：Spring默认线程池不会自动传递MDC
// 需要配置TaskDecorator来传递traceId，见3.5节
sendOrderNotificationAsync(userId, orderNo);
return orderNo;
} catch (Exception e) {
// 异常时记录日志，traceId同样会被输出
log.error("创建订单异常, userId={}, productId={}, error={}",
userId, productId, e.getMessage(), e);
throw e;
}
}
/**
* 异步发送订单通知
*
* @Async注解会让方法在新线程中执行
* 默认情况下MDC不会自动传递到新线程
* 所以需要配置TaskDecorator来手动传递（见3.5节）
*/
@Async("taskExecutor")
public void sendOrderNotificationAsync(Long userId, String orderNo) {
// 这里在新线程中执行
// 如果配置了TaskDecorator，traceId会传递过来
log.info("异步发送订单通知, userId={}, orderNo={}", userId, orderNo);
try {
// 模拟发送通知的操作
Thread.sleep(1000); // 模拟耗时操作
log.info("订单通知发送成功, orderNo={}", orderNo);
} catch (InterruptedException e) {
log.error("通知发送被中断, orderNo={}", orderNo, e);
Thread.currentThread().interrupt();
}
}
/**
* 生成订单号 - 模拟方法
*/
private String generateOrderNo(Long userId) {
// 简单模拟：用户ID + 时间戳后8位
return "ORD" + userId + System.currentTimeMillis() % 100000000;
}
}
3.4.5 订单控制器
// OrderController.java
// 订单控制器 - REST接口层
package com.example.orderservice.controller;
import com.example.orderservice.service.OrderService;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;
import java.util.Map;
/**
* 订单REST控制器
*
* 接收外部请求，调用OrderService完成业务逻辑
*/
@RestController
@RequestMapping("/order")
public class OrderController {
private static final Logger log = LoggerFactory.getLogger(OrderController.class);
private final OrderService orderService;
public OrderController(OrderService orderService) {
this.orderService = orderService;
}
/**
* 创建订单接口
*
* 请求示例：
* POST /order/create
* Body: {"userId": 1001, "productId": 2001, "quantity": 2}
*/
@PostMapping("/create")
public ResponseEntity<?> createOrder(@RequestBody Map<String, Object> params) {
log.info("收到创建订单请求, params={}", params);
try {
Long userId = Long.valueOf(params.get("userId").toString());
Long productId = Long.valueOf(params.get("productId").toString());
Integer quantity = Integer.valueOf(params.get("quantity").toString());
String orderNo = orderService.createOrder(userId, productId, quantity);
log.info("订单创建接口响应成功, orderNo={}", orderNo);
return ResponseEntity.ok(Map.of(
"code", 200,
"message", "订单创建成功",
"orderNo", orderNo
));
} catch (Exception e) {
log.error("订单创建接口异常, params={}, error={}", params, e.getMessage(), e);
return ResponseEntity.badRequest().body(Map.of(
"code", 500,
"message", "订单创建失败: " + e.getMessage()
));
}
}
}
3.5 异步场景下TraceId的传递配置
上面提到了一个关键问题：Spring的@Async异步方法默认使用新的线程池，新的线程不会自动继承原线程的MDC上下文。这意味着异步方法里的日志不会带traceId，链路追踪信息就断了。
解决这个问题需要配置一个TaskDecorator：
// AsyncConfig.java
// 异步线程池配置 - 确保traceId能跨线程传递
package com.example.orderservice.config;
import org.slf4j.MDC;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.task.TaskDecorator;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;
import java.util.Map;
import java.util.concurrent.Executor;
/**
* 异步任务配置类
*
* 核心目的：配置ThreadPoolTaskExecutor，并注入TaskDecorator
* 这样@Async方法执行时，MDC中的traceId会自动传递到新线程
*/
@Configuration
@EnableAsync
public class AsyncConfig {
/**
* 配置异步线程池
*
* 关键步骤：通过setTaskDecorator设置TaskDecorator
* TaskDecorator会在提交任务到线程池之前执行
* 它会捕获当前线程的MDC上下文，在新线程中恢复，任务完成后清理
*/
@Bean("taskExecutor")
public Executor taskExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
// 核心线程数
executor.setCorePoolSize(4);
// 最大线程数
executor.setMaxPoolSize(8);
// 队列容量
executor.setQueueCapacity(100);
// 线程名称前缀，方便日志排查
executor.setThreadNamePrefix("async-");
// 线程空闲时间
executor.setKeepAliveSeconds(60);
// 核心配置：设置TaskDecorator来传递MDC
executor.setTaskDecorator(new TraceMdcTaskDecorator());
// 线程池拒绝策略
executor.setRejectedExecutionHandler(new java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy());
// 初始化线程池
executor.initialize();
return executor;
}
/**
* TaskDecorator实现 - 负责MDC上下文的跨线程传递
*
* 原理：
* 1. 在提交任务到线程池之前（原线程），捕获当前线程的MDC上下文
* 2. 在新线程中执行任务之前，恢复MDC上下文
* 3. 任务执行完毕后，清理MDC上下文，避免污染
*/
static class TraceMdcTaskDecorator implements TaskDecorator {
@Override
public Runnable decorate(Runnable runnable) {
// 在原线程中获取当前MDC上下文（包含traceId等）
// getCopyOfContextMap返回的是当前线程MDC的快照
Map<String, String> contextMap = MDC.getCopyOfContextMap();
return () -> {
try {
// 在新线程中设置MDC上下文
// 如果原线程没有MDC（contextMap为null），则不设置
if (contextMap != null) {
MDC.setContextMap(contextMap);
}
// 执行原始任务
runnable.run();
} finally {
// 任务完成后清理MDC，防止线程复用导致上下文串数据
// 这个清理很重要，因为线程池的线程会被复用
MDC.clear();
}
};
}
}
}
这个TaskDecorator的设计是保证异步场景下链路追踪不断裂的关键。没有它，@Async方法里的日志就不会带traceId，你在Zipkin里发现异步调用有问题，却找不到对应的日志。
3.6 库存服务和用户服务的配合实现
为了让整个示例完整可运行，我们简要展示下游服务的实现。库存服务和用户服务的配置与订单服务类似，也需要引入Micrometer Tracing依赖并配置Zipkin地址。
// InventoryController.java - 库存服务控制器
package com.example.inventoryservice.controller;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.*;
import java.util.Map;
import java.util.Random;
/**
* 库存服务控制器
*
* 注意：库存服务不需要做任何额外配置
* Micrometer Tracing会自动从请求头中提取上游传来的traceId
* 并在本地生成新的spanId，上报到Zipkin
*/
@RestController
@RequestMapping("/inventory")
public class InventoryController {
private static final Logger log = LoggerFactory.getLogger(InventoryController.class);
/**
* 查询库存接口
*
* 接收订单服务的调用，返回库存数量
*/
@GetMapping("/{productId}")
public Integer checkInventory(@PathVariable("productId") Long productId) {
log.info("库存服务收到查询请求, productId={}", productId);
// 模拟数据库查询耗时
try {
Thread.sleep(200);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
// 模拟返回库存
Random random = new Random();
Integer stock = 10 + random.nextInt(50); // 10到60之间的随机库存
log.info("库存查询结果, productId={}, stock={}", productId, stock);
return stock;
}
/**
* 扣减库存接口
*/
@GetMapping("/deduct")
public Boolean deductInventory(@RequestParam("productId") Long productId,
@RequestParam("quantity") Integer quantity) {
log.info("库存服务收到扣减请求, productId={}, quantity={}", productId, quantity);
try {
Thread.sleep(100);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
log.info("库存扣减完成, productId={}, quantity={}", productId, quantity);
return true;
}
}
// UserController.java - 用户服务控制器
package com.example.userservice.controller;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.*;
import java.util.Map;
/**
* 用户服务控制器
*
* 同样不需要额外配置，自动接收上游traceId
*/
@RestController
@RequestMapping("/user")
public class UserController {
private static final Logger log = LoggerFactory.getLogger(UserController.class);
/**
* 查询用户信息接口
*/
@GetMapping("/{userId}")
public Map<String, Object> getUser(@PathVariable("userId") Long userId) {
log.info("用户服务收到查询请求, userId={}", userId);
// 模拟数据库查询
try {
Thread.sleep(150);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
// 模拟用户数据
Map<String, Object> user = Map.of(
"userId", userId,
"userName", "测试用户" + userId,
"phone", "13800138000"
);
log.info("用户查询完成, userId={}", userId);
return user;
}
}
3.7 查看效果
启动Zipkin Server（可以直接用Docker启动）：
# 使用Docker启动Zipkin Server
# Zipkin Server默认监听9411端口
docker run -d \
--name zipkin \
-p 9411:9411 \
openzipkin/zipkin:latest
然后依次启动用户服务（8083端口）、库存服务（8082端口）、订单服务（8081端口）。
发送一个测试请求：
# 发送下单请求到订单服务
curl -X POST http://localhost:8081/order/create \
-H "Content-Type: application/json" \
-d '{"userId": 1001, "productId": 2001, "quantity": 2}'
打开Zipkin UI（http://localhost:9411），在搜索框输入TraceId或者服务名称，就能看到完整的调用链路。
在Zipkin UI中点击某个Span，你会看到该Span的详情，包括开始时间、结束时间、耗时、标签（tags）、日志（events）等。
然后在日志系统中搜索这个TraceId，就能找到所有相关的日志条目。比如你在控制台看到的一条日志长这样：
2024-01-15 14:30:01.123 INFO [http-nio-8081-exec-1] c.e.o.s.OrderService [traceId=a1b2c3d4e5f6a7b8] [spanId=9c8d7e6f5a4b3c2d] : 开始创建订单, userId=1001, productId=2001, quantity=2
提取traceId=a1b2c3d4e5f6a7b8，去日志系统搜索，就能找到整条链路的所有日志。
四、典型排查场景演示
4.1 场景一：用户下单超时排查
假设用户反馈"我下单一直转圈，最后超时了"。
排查步骤如下：
第一步，在Zipkin UI中搜索最近的下单相关Trace。你会看到一条调用链，包含order-service -> user-service和order-service -> inventory-service的调用。
第二步，检查每个Span的耗时。假设你发现inventory-service的checkInventory这个Span耗时异常，正常应该是200ms左右，但这条链路里花了5秒。
第三步，点击这个Span的详情，查看Span的tags和日志。你可能会看到Span上记录了错误信息error: Connection timeout。
第四步，复制这条Trace的TraceId，去日志系统搜索。你会找到库存服务中对应的日志：
2024-01-15 14:30:01.456 INFO [http-nio-8082-exec-3] c.e.i.c.InventoryController [traceId=a1b2c3d4e5f6a7b8] [spanId=f1e2d3c4b5a69788] : 库存服务收到查询请求, productId=2001
2024-01-15 14:30:06.789 ERROR [http-nio-8082-exec-3] c.e.i.c.InventoryController [traceId=a1b2c3d4e5f6a7b8] [spanId=f1e2d3c4b5a69788] : 数据库查询超时
通过这两条日志，你可以明确知道：这条调用链中，库存服务的数据库查询超时了，而且耗时从日志时间戳也能看出来。结合Zipkin的可视化信息（这个Span耗时5秒，而正常应该是200ms），排查效率非常高。
4.2 场景二：第三方支付服务调用失败排查
另一个场景：支付服务调用第三方支付接口失败了，用户支付没成功。
在Zipkin UI中搜索支付服务（payment-service）的Trace，找到标记为error的Span。点击进去看到Span详情中有错误标签http.status_code=500和error=Payment timeout。
复制TraceId到日志系统搜索，找到支付服务的详细日志：
2024-01-15 15:20:03.001 INFO [http-nio-8084-exec-2] c.e.p.s.PaymentService [traceId=b2c3d4e5f6a7b8c9] [spanId=1a2b3c4d5e6f7a8b] : 开始处理支付, orderId=ORD1001123456789, amount=99.90
2024-01-15 15:20:03.234 INFO [http-nio-8084-exec-2] c.e.p.s.PaymentService [traceId=b2c3d4e5f6a7b8c9] [spanId=1a2b3c4d5e6f7a8b] : 调用第三方支付接口, provider=Alipay, tradeNo=202401151234567890
2024-01-15 15:20:08.567 ERROR [http-nio-8084-exec-2] c.e.p.s.PaymentService [traceId=b2c3d4e5f6a7b8c9] [spanId=1a2b3c4d5e6f7a8b] : 第三方支付接口响应超时, provider=Alipay, elapsed=5333ms
从日志中你可以看出：调用的是支付宝接口，请求已经发出（15:20:03.234），但直到15:20:08.567才超时（5.3秒后），说明是第三方支付接口的响应时间过长。
然后你可以通过traceId继续追踪上游，看看订单服务那边的日志，确认订单状态是什么（可能还是"支付中"），以及用户收到了什么反馈。
4.3 场景三：批量任务执行异常排查
再举一个例子：一个定时任务批量处理订单，其中某几条订单处理失败了。
定时任务的日志可能没有HTTP请求头带来的TraceId，这时候你需要手动生成TraceId。可以在任务开始时用Micrometer的Tracer创建一个新的Trace：
// BatchOrderJob.java
// 批量订单处理定时任务
package com.example.orderservice.job;
import io.micrometer.tracing.Tracer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
import java.util.List;
/**
* 批量订单处理定时任务
*
* 定时扫描需要处理的订单，逐条处理
*
* 关键：定时任务没有HTTP上下文，需要手动创建Trace
*/
@Component
public class BatchOrderJob {
private static final Logger log = LoggerFactory.getLogger(BatchOrderJob.class);
private final Tracer tracer;
private final OrderService orderService;
public BatchOrderJob(Tracer tracer, OrderService orderService) {
this.tracer = tracer;
this.orderService = orderService;
}
/**
* 每5分钟执行一次批量订单处理
*
* 每条订单处理时创建独立的Trace
* 这样在Zipkin中可以看到每条订单的独立链路
*/
@Scheduled(cron = "0 */5 * * * ?")
public void processBatchOrders() {
// 批量任务的根Trace
var rootSpan = tracer.nextSpan().name("BatchOrderJob-processBatchOrders").start();
try (Tracer.SpanInScope ws = tracer.withSpan(rootSpan)) {
log.info("批量订单任务开始执行");
List<Long> pendingOrderIds = getPendingOrderIds(); // 模拟获取待处理订单列表
for (Long orderId : pendingOrderIds) {
// 每条订单创建一个子Span
// 这样在Zipkin中可以看到每条订单的处理链路
var orderSpan = tracer.nextSpan()
.name("BatchOrderJob-processOrder")
.tag("order.id", orderId.toString())
.parent(rootSpan)
.start();
try (Tracer.SpanInScope orderScope = tracer.withSpan(orderSpan)) {
// 处理单条订单
log.info("开始处理订单, orderId={}", orderId);
try {
// 这里调用具体业务逻辑
orderService.createOrder(
1001L, // 用户ID
2001L, // 商品ID
1 // 数量
);
log.info("订单处理成功, orderId={}", orderId);
} catch (Exception e) {
// 记录错误到Span中
orderSpan.error(e);
log.error("订单处理失败, orderId={}, error={}", orderId, e.getMessage(), e);
}
// 结束子Span
orderSpan.end();
} catch (Exception e) {
// 如果withSpan块本身出错
orderSpan.error(e);
orderSpan.end();
log.error("订单处理异常, orderId={}", orderId, e);
}
}
log.info("批量订单任务执行完成, 共处理={}条", pendingOrderIds.size());
} catch (Exception e) {
rootSpan.error(e);
log.error("批量订单任务执行异常", e);
} finally {
rootSpan.end();
}
}
private List<Long> getPendingOrderIds() {
// 模拟获取待处理订单ID列表
return List.of(10001L, 10002L, 10003L, 10004L, 10005L);
}
}
五、关联技术详解
5.1 MDC与SLF4J日志上下文
MDC（Mapped Diagnostic Context）是SLF4J提供的一个线程级别的上下文工具，它本质上是一个线程安全的Map，允许你在代码中放入任意键值对，日志框架在格式化日志时会自动输出这些键值对。
MDC最典型的用法就是把TraceId、SpanId、用户ID等上下文信息放进去，这样每一行日志都能关联到具体的业务上下文。
// MDC使用示例
package com.example.demo;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;
/**
* MDC基本用法示例
*
* 在业务代码中手动管理MDC
*/
public class MdcExample {
private static final Logger log = LoggerFactory.getLogger(MdcExample.class);
public void doSomething() {
// 往MDC中放入键值对
// 这些值会在日志pattern中通过%X{key}来引用
MDC.put("traceId", "my-trace-001");
MDC.put("userId", "1001");
try {
log.info("这条日志会带上traceId=my-trace-001和userId=1001");
// 可以在嵌套的方法中继续使用
nestedMethod();
} finally {
// 用完了一定要清理，尤其是线程池场景
// 不清理的话，下一个使用这个线程的任务会看到上一个任务的MDC数据
MDC.remove("traceId");
MDC.remove("userId");
}
}
private void nestedMethod() {
// 嵌套方法中也能用到MDC的值
// 因为MDC是线程级别的，同一个线程内的所有日志都会带上
log.info("嵌套方法中的日志，同样带有traceId和userId");
}
}
MDC在Spring Cloud链路追踪中的作用是：Micrometer Tracing在接收到带有traceId的请求时，会自动调用MDC.put("traceId", traceId)和MDC.put("spanId", spanId)，你不需要手动操作，日志里自然就带上了。但如果是异步场景或者定时任务，就需要手动管理，这也是3.5节TaskDecorator要解决的问题。
5.2 OpenTelemetry与Zipkin集成
如果你不想依赖Spring Cloud的Micrometer Tracing，也可以直接使用OpenTelemetry。OpenTelemetry是目前云原生可观测性的标准，它的Trace和Zipkin的格式是兼容的，可以直接上报到Zipkin。
<!-- pom.xml - OpenTelemetry依赖 -->
<dependencies>
<!-- OpenTelemetry SDK -->
<dependency>
<groupId>io.opentelemetry</groupId>
<artifactId>opentelemetry-sdk</artifactId>
<version>1.32.0</version>
</dependency>
<!-- OpenTelemetry Zipkin Exporter -->
<dependency>
<groupId>io.opentelemetry</groupId>
<artifactId>opentelemetry-exporter-zipkin</artifactId>
<version>1.32.0</version>
</dependency>
<!-- OpenTelemetry Spring Boot Starter（如果用Spring Boot） -->
<dependency>
<groupId>io.opentelemetry.instrumentation</groupId>
<artifactId>opentelemetry-spring-boot-starter</artifactId>
<version>1.32.0</version>
</dependency>
</dependencies>
// OpenTelemetryConfig.java
// OpenTelemetry手动配置示例
package com.example.config;
import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.common.Attributes;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.SpanKind;
import io.opentelemetry.api.trace.StatusCode;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.context.Scope;
import io.opentelemetry.exporter.zipkin.ZipkinSpanExporter;
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.resources.Resource;
import io.opentelemetry.sdk.trace.SdkTracerProvider;
import io.opentelemetry.sdk.trace.export.BatchSpanProcessor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
/**
* OpenTelemetry配置类
*
* 这个配置独立于Spring Cloud，适用于任何Java项目
*/
@Configuration
public class OpenTelemetryConfig {
/**
* 创建OpenTelemetry SDK实例
*/
@Bean
public OpenTelemetrySdk openTelemetrySdk() {
// Zipkin导出器：把Trace数据发送到Zipkin Server
ZipkinSpanExporter zipkinExporter = ZipkinSpanExporter.builder()
.setEndpoint("http://localhost:9411/api/v2/spans")
.build();
// 资源标识：标识这个服务的信息
Resource resource = Resource.getDefault()
.merge(Resource.create(Attributes.of(
io.opentelemetry.semconv.resource.attributes.SemanticResourceAttributes.SERVICE_NAME,
"order-service"
)));
// Tracer Provider：管理Tracer的创建和Span的上报
SdkTracerProvider tracerProvider = SdkTracerProvider.builder()
.setResource(resource)
.addSpanProcessor(BatchSpanProcessor.builder(zipkinExporter).build())
.build();
return OpenTelemetrySdk.builder()
.setTracerProvider(tracerProvider)
.build();
}
/**
* 创建Tracer实例
*/
@Bean
public Tracer tracer(OpenTelemetrySdk openTelemetrySdk) {
return openTelemetrySdk.getTracer("order-service", "1.0.0");
}
}
// OrderServiceWithOTel.java
// 使用OpenTelemetry创建Span的示例
package com.example.service;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.SpanKind;
import io.opentelemetry.api.trace.StatusCode;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.context.Scope;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;
/**
* 使用OpenTelemetry的订单服务
*
* 手动创建Span来追踪业务方法
*/
@Service
public class OrderServiceWithOTel {
private static final Logger log = LoggerFactory.getLogger(OrderServiceWithOTel.class);
private final Tracer tracer;
public OrderServiceWithOTel(Tracer tracer) {
this.tracer = tracer;
}
/**
* 创建订单
*
* 注意：这里手动创建Span
* Spring Boot Starter会自动为HTTP请求创建根Span
* 但业务方法内部的细分操作需要手动创建子Span
*/
public String createOrder(Long userId, Long productId, Integer quantity) {
// 获取当前Span（由Spring Boot Starter自动创建的HTTP请求Span）
Span parentSpan = Span.current();
// 创建子Span：查询用户信息
Span userSpan = tracer.spanBuilder("order.queryUser")
.setParent(parentSpan)
.setAttribute("user.id", userId)
.startSpan();
try (Scope scope = userSpan.makeCurrent()) {
log.info("查询用户信息, userId={}", userId);
// 模拟调用用户服务
String userName = callUserService(userId);
log.info("用户查询成功, userName={}", userName);
// 创建子Span：检查库存
Span inventorySpan = tracer.spanBuilder("order.checkInventory")
.setParent(parentSpan)
.setAttribute("product.id", productId)
.setAttribute("order.quantity", quantity)
.startSpan();
try (Scope invScope = inventorySpan.makeCurrent()) {
log.info("检查库存, productId={}", productId);
int stock = callInventoryService(productId);
log.info("库存检查完成, stock={}", stock);
if (stock < quantity) {
inventorySpan.setStatus(StatusCode.ERROR, "库存不足");
inventorySpan.setAttribute("error.message", "库存不足");
log.error("库存不足, 需要={}, 实际={}", quantity, stock);
throw new RuntimeException("库存不足");
}
inventorySpan.setStatus(StatusCode.OK);
} finally {
inventorySpan.end();
}
// 创建子Span：生成订单
Span createSpan = tracer.spanBuilder("order.createOrder")
.setParent(parentSpan)
.setAttribute("user.id", userId)
.setAttribute("product.id", productId)
.startSpan();
try (Scope cs = createSpan.makeCurrent()) {
String orderNo = generateOrderNo(userId);
createSpan.setAttribute("order.no", orderNo);
log.info("订单创建成功, orderNo={}", orderNo);
createSpan.setStatus(StatusCode.OK);
return orderNo;
} finally {
createSpan.end();
}
} catch (Exception e) {
// 异常时标记Span为错误状态
userSpan.setStatus(StatusCode.ERROR, e.getMessage());
userSpan.recordException(e);
log.error("创建订单异常", e);
throw e;
} finally {
userSpan.end();
}
}
private String callUserService(Long userId) {
// 模拟调用
return "用户" + userId;
}
private int callInventoryService(Long productId) {
// 模拟调用
return 30;
}
private String generateOrderNo(Long userId) {
return "ORD" + System.currentTimeMillis();
}
}
OpenTelemetry的好处是它语言无关，Java、Go、Python等语言都能用同一套SDK上报到同一个Zipkin。如果你的技术栈比较杂，OpenTelemetry是一个很好的选择。
5.3 ELK与Zipkin联动
如果你的日志存储用的是ELK（Elasticsearch + Logstash + Kibana），可以进一步实现从Zipkin一键跳转到Kibana。
在ELK的日志格式中确保包含traceId字段：
{
"@timestamp": "2024-01-15T14:30:01.123Z",
"level": "INFO",
"logger": "com.example.orderservice.service.OrderService",
"thread": "http-nio-8081-exec-1",
"message": "开始创建订单, userId=1001, productId=2001, quantity=2",
"traceId": "a1b2c3d4e5f6a7b8",
"spanId": "9c8d7e6f5a4b3c2d"
}
在Kibana中配置索引模式时，确保traceId字段被正确索引。然后配置自定义链接：
{
"url": "http://localhost:5601/app/kibana#/discover?_g=(refreshInterval:(pause:!t,value:0),time:(from:now-24h,to:now))&_a=(columns:(hide:!t,_a:!t,sortable:!t),filters:!(),index:'logstash-*',interval:auto,query:(language:kuery,query:'traceId:{{traceId}}'),sort:!((@timestamp,desc)))"
}
这样在Zipkin中点击Span详情时，就可以直接跳转到Kibana查看对应TraceId的所有日志。
六、应用场景
6.1 线上故障快速定位
线上服务出现告警时，比如某个接口错误率突然升高，值班工程师可以从监控系统中获取最近的TraceId，直接去Zipkin查看调用链，定位到异常的服务和Span，然后通过TraceId去日志系统查看详细错误信息，整个过程通常在几分钟内完成。如果没有联动，排查可能需要十几分钟甚至更长。
6.2 性能瓶颈分析
当某个业务接口响应变慢时，通过Zipkin可以直观看到整条链路上每个服务的耗时分布。比如一个订单创建接口总耗时3秒，通过Trace可以发现其中2.5秒花在了库存服务的数据库查询上，剩下的0.5秒是用户服务和订单服务的正常耗时。这样就能快速定位到性能瓶颈，不需要逐个服务去排查。
6.3 分布式事务追踪
在涉及多个服务协作的事务场景中（比如订单创建涉及库存扣减、支付、发货等多个步骤），通过统一的TraceId可以追踪整个事务的执行状态。如果事务在某个环节失败了，通过Zipkin可以看到失败发生在哪个服务，通过日志可以看到失败的具体原因（是数据库错误、网络超时还是业务逻辑异常）。
6.4 自动化告警联动
可以将Zipkin的Trace数据与日志告警联动。比如当某个服务的错误Span数量超过阈值时触发告警，告警通知中附带最近的错误TraceId，值班人员点击TraceId就能直接查看链路详情和相关日志，不用手动去多个系统间切换。
6.5 开发调试
在开发和测试环境中，开发者可以通过TraceId快速定位代码执行路径。比如在单元测试中，可以通过日志找到某个方法被调用的具体上下文和参数，配合Zipkin的Span信息了解调用时序，这对复杂业务的调试非常有帮助。
七、技术优缺点分析
7.1 优点
跨语言兼容性好。 Zipkin是CNCF毕业项目，支持Java、Go、Python、Node.js等多种语言的SDK。OpenTelemetry更是语言无关的标准，无论你用Java还是Go，上报到Zipkin的Trace格式都一样。
社区成熟度高。 Zipkin已经发展了十多年，生态完善，与Prometheus、Jaeger、ELK等工具都有良好的集成方案。遇到问题容易找到解决方案。
轻量级。 Zipkin Server是一个单进程应用，资源消耗小。不像一些商业APM工具需要部署多个组件，Zipkin只需要一个容器就能跑起来。
与日志天然联动。 通过在日志中嵌入TraceId和SpanId，实现链路追踪与日志的无缝关联。这个方案不依赖任何第三方商业工具，完全可以用开源组件搭建。
7.2 缺点
采样策略需要权衡。 全量采样意味着所有请求都会被记录，这对高并发场景来说数据量非常大，存储成本和检索性能都会受影响。采样率太低又可能漏掉关键问题。需要根据业务量和服务等级来制定合理的采样策略。
对业务代码有一定侵入。 虽然Spring Boot的自动配置能减少很多手动操作，但异步场景、定时任务等边缘场景还是需要手动处理TraceId的传递。如果代码结构复杂，维护这些手动操作的成本不低。
排查流程仍需要人工操作。 虽然联动方案提高了排查效率，但本质上还是"先查Zipkin，再查日志"的两步操作。一些商业APM工具实现了在Trace详情中直接展示关联日志，体验更好，但这需要额外的集成开发。
数据量管理挑战。 Trace数据本身不小，每条Span包含时间戳、标签、日志等字段。在高并发系统下，一天可能产生数GB甚至数十GB的Trace数据。需要配置合理的保留策略和数据生命周期管理。
八、注意事项
8.1 采样策略的选择
采样率不是越高越好。生产环境建议根据服务的重要性来分级设置：
- 核心交易链路（下单、支付）：建议10%-100%采样，或者采用基于错误率的采样（错误请求100%采样，正常请求10%采样）
- 普通业务链路：5%-10%采样
- 后台管理类接口：1%-5%采样
Micrometer Tracing支持多种采样策略，可以通过配置灵活调整。
8.2 MDC清理的纪律性
在线程池场景中，MDC如果不及时清理会导致严重的上下文串数据问题。比如线程A处理用户1001的请求时把userId=1001放进了MDC，处理完后没有清理，然后线程池复用了这个线程去处理用户1002的请求，如果线程B没有正确设置MDC，日志中就会出现userId=1001这种错误数据。
养成习惯：每次设置MDC后，在finally块中清理。或者像前面的TaskDecorator那样，在新线程执行完任务后清理MDC。
8.3 性能影响评估
链路追踪和日志埋点都会带来额外的性能开销。虽然单个Span的创建和上报开销很小（通常在微秒级别），但在超高并发场景下累积起来也会有影响。建议在压测环境中评估：
- 全量采样vs部分采样对接口P99延迟的影响
- Trace上报是同步还是异步（建议异步）
- Zipkin Server的吞吐量是否满足需求
8.4 日志格式的统一性
团队中不同服务可能由不同开发者维护，需要统一日志格式规范。建议团队约定：
- 所有服务必须在日志中包含traceId
- traceId的键名统一（traceId或trace_id，团队内部统一即可）
- 日志级别的使用规范（什么场景用INFO，什么场景用WARN，什么场景用ERROR）
- 敏感信息（密码、身份证、银行卡号）禁止写入日志
8.5 Zipkin Server的高可用
在生产环境中，Zipkin Server需要保证高可用。单点部署的Zipkin Server如果宕机，虽然不会直接影响业务（Span上报失败只是丢失Trace数据），但会影响排查能力。建议：
- 部署至少2个Zipkin Server实例，前面加负载均衡
- 配置持久化存储（Zipkin支持MySQL、Cassandra、Elasticsearch等存储后端）
- 设置数据保留策略，避免存储无限增长
8.6 异步和跨线程场景的覆盖
除了前面提到的@Async异步方法，还有其他场景需要注意TraceId传递：
- CompletableFuture、ParallelStream等并行计算
- 消息队列的生产者-消费者模式（消息中需要携带traceId）
- 定时任务（没有HTTP上下文，需要手动创建Trace）
- 回调函数和监听器
每一种场景都需要确认TraceId是否正确传递，否则链路会断裂。
8.7 与现有监控体系的集成
如果团队已经在使用Prometheus + Grafana做指标监控，可以通过OpenTelemetry把Trace数据和Metrics数据关联起来。比如通过Service Name、TraceId等维度，在Grafana仪表盘上同时展示指标和Trace数据，形成完整的可观测性体系。
九、文章总结
Zipkin与日志系统联动的核心价值在于：把"链路视角"和"细节视角"结合起来。Zipkin提供宏观的调用链路视图，让你知道请求经过了哪些服务、每个服务花了多长时间、哪个环节出错了；日志系统提供微观的详细上下文，让你看到具体的错误信息、业务参数、代码堆栈。
通过TraceId这个纽带，两个系统实现了对齐，排查问题的效率有了质的提升。从"大海捞针"式的翻日志变成了"按图索骥"式的精准定位。
这个方案的搭建并不复杂，Spring Boot 3.x中Micrometer Tracing已经做了大量的自动配置工作，你只需要：
- 引入相关依赖
- 配置Zipkin Server地址
- 在日志格式中加入%X{traceId}
- 处理异步场景的MDC传递
然后就可以在Zipkin UI中查看完整链路，用TraceId关联日志，大幅提升线上问题的排查效率。
如果你的技术栈不是Spring Boot，OpenTelemetry也是一个很好的选择。它是语言无关的标准，无论你用什么语言开发，都能接入Zipkin。
随着微服务架构的深入应用，可观测性（包括链路追踪、日志、指标）已经成为必不可少的能力。花一点时间搭建Zipkin与日志的联动，会在未来的故障排查中为你节省大量时间。与其在问题发生时手忙脚乱地翻日志，不如提前把基础设施做好。
评论
围绕“Zipkin与日志系统联动：实现分布式服务链路追踪与日志关联排查的实用方案”参与讨论