在微服務架構中，一個用戶請求往往需要經過多個服務的協同處理。為了有效追蹤請求的完整調用鏈路，需要一套完整的日志追蹤方案。Sleuth + Zipkin + ELK 組合提供了完整的解決方案

• Sleuth：生成和傳播追蹤ID
• Zipkin：收集、存儲和可視化追蹤數據
• ELK：集中存儲和檢索業務日志
• MDC：實現日志與追蹤上下文的關聯

1.組件介紹

組件一：Spring Cloud Sleuth

自動生成唯一的TraceID和SpanID，通過HTTP頭或消息中間件在服務間傳播這些ID，與MDC集成，將追蹤信息注入日志

spring:sleuth:sampler:probability: 1.0 # 采樣率，1.0表示100%采樣propagation:type: B3 # 使用Zipkin的B3傳播協議

組件二：Zipkin

收集各服務上報的追蹤數據，存儲調用鏈路信息，提供可視化界面展示調用鏈路和耗時

服務 → 上報數據 → Zipkin Collector → Storage → Zipkin UI

存儲選項：開發環境使用內存，正式環境推薦配置為Elasticsearch

spring:zipkin:base-url: http://zipkin-server:9411sender: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

• 日志輸出

服務A日志: [abc123,def456,order-111] INFO ... 創建訂單開始
服務B日志: [abc123,ghi789,order-111] INFO ... 庫存扣減開始

• 調用鏈路信息上報Zipkin，業務日志發送到ELK
• 通過Zipkin發現異常服務，通過TraceID在ELK中查找相關日志，通過業務ID追蹤特定業務對象全鏈路