在微服务架构中，一个用户请求往往需要经过多个服务的协同处理。为了有效追踪请求的完整调用链路，需要一套完整的日志追踪方案。Sleuth + Zipkin + ELK 组合提供了完整的解决方案
- Sleuth：生成和传播追踪ID
- Zipkin：收集、存储和可视化追踪数据
- ELK：集中存储和检索业务日志
- MDC：实现日志与追踪上下文的关联
1.组件介绍
组件一：Spring Cloud Sleuth
自动生成唯一的TraceID和SpanID，通过HTTP头或消息中间件在服务间传播这些ID，与MDC集成，将追踪信息注入日志
yaml
spring:
sleuth:
sampler:
probability: 1.0 # 采样率，1.0表示100%采样
propagation:
type: B3 # 使用Zipkin的B3传播协议组件二：Zipkin
收集各服务上报的追踪数据，存储调用链路信息，提供可视化界面展示调用链路和耗时
服务 → 上报数据 → Zipkin Collector → Storage → Zipkin UI
存储选项：开发环境使用内存，正式环境推荐配置为Elasticsearch
yaml
spring:
zipkin:
base-url: http://zipkin-server:9411
sender:
type: web # 使用HTTP方式上报组件三：ELK Stack (Elasticsearch + Logstash + Kibana)
Elasticsearch用于存储和索引日志数据 ，Logstash用于收集、过滤和转发日志，Kibana用于可视化查询和分析日志。确保日志中包含TraceID，便于通过TraceID关联业务日志和调用链路
2.完整请求链路示例
-
用户请求到达服务A，生成TraceID: abc123，生成SpanID: def456
-
服务A调用服务B，携带HTTP头: X-B3-TraceId=abc123, X-B3-ParentSpanId=def456，服务B生成新SpanID: ghi789
-
日志输出
matlab
服务A日志: [abc123,def456,order-111] INFO ... 创建订单开始
服务B日志: [abc123,ghi789,order-111] INFO ... 库存扣减开始- 调用链路信息上报Zipkin，业务日志发送到ELK
- 通过Zipkin发现异常服务，通过TraceID在ELK中查找相关日志，通过业务ID追踪特定业务对象全链路