Spring Cloud Sleuth 分散式追蹤 Zipkin

使用 Spring Cloud Sleuth 實現分散式追蹤

戴佩涵 Hannah Tai 2021/12/30 09:26:35
1013
一、簡介
 
Spring Cloud Sleuth 是 Spring Cloud 針對 Distributed Tracing (分散式追蹤) 所提出的解決方案,使用 Google 針對分散式追蹤所提出的 Dapper 設計架構,並整合 Zipkin 所提供的 Java Client Library - OpenZipkin Brave.這個套件最主要可以做兩件事情:一是追蹤 Spring Boot 專案的輸入資訊,在日誌記錄增加相應的追蹤資訊,另一是整合 Zipkin,採集相關追蹤資訊並傳送.
 
Google 針對分散式追蹤所提出的 Dapper 設計架構,被廣為應用在分散式追蹤的系統設計中,以下以 Spring Cloud Sleuth 官方文件所提供的說明圖做說明.

  • 一個工作單位稱作Span,用以識別這個 Span 的唯一值,稱做 Span Id.
  • 一組 Span 稱作 Trace,用以識別這個 Trace 的唯一值,稱做 Trace Id.
  • 當最一開始的 REQUEST 進入 SERVICE1 時,SERVICE1 會先查看這個 REQUEST 是否有 Baggage (包袱),包袱意指 Trace ID 及 Span ID 等相關資訊.如果沒有 Baggage,表示是第一次進入服務鏈,此時 SERVICE1 會創建 Trace 和 Span,並有各自對應的 Id,在此案例中, Trace Id 為 X ,Span Id 為 A .括號 no custom span 表示,首次進入服務鏈所創建的 Span.
  • 當 SERVICE1 要呼叫 SERVICE2 時,SERVICE1 會再創建新的 Span,Span ID 為 B,註記 Client Sent,攜帶資訊在 Baggage 中.當 SERVICE2 收到時,發現有 Baggage,註記 Server Received,並另創建新的 Span,Span ID 為 C,沿用原來的 Trace ID 為 X.括號 custom span,表示非首次進入服務鏈所創建的 Span.
  • 當 SERVICE2 要回傳 SERVICE1 時,註記 Server Sent,當 SERVICE1 收到時,則會註記 Client Received.
  • 同理類推,SERVICE2 呼叫 SERVICE3 和 SERVICE4 .
 
二、開始使用 Spring Cloud Sleuth
 
假設已有可執行的 Spring Boot 微服務專案,欲使用 Spring Cloud Sleuth,需要新增依賴在 pom.xml,並且定義專案名稱在 application.yml.
  1. 新增依賴在 pom.xml
    • 定義 properties
    • 定義 dependencyManagement
    • 增加 dependency
  2. 定義專案名稱在 application.yml
 
啟動專案並呼叫 Restful API 後,可以看到每個日誌記錄中,被加入了 [Application Name,Trace ID,Span ID] 資訊,並且在跨服務呼叫中,不同的服務會使用相同的 Trace ID,並使用不同的 Span ID.
  1. 示例一:呼叫產品服務的取得所有商品 Restful API.從日誌記錄中,可以看到加入了追蹤資訊,Application Name 為 product-service,Trace ID 為 77e0c8860769d2a8,Span ID 為 77e0c8860769d2a8.
    • 產品服務
  2. 示例二:呼叫購物車服務的建立訂單 Restful API,其會再呼叫產品服務的異動庫存 Restful API,完成後再接續呼叫訂單服務的建立訂單 Restful API .從日誌記錄中,可以看到在跨服務的呼叫中,購物車服務、訂單服務及庫存服務會使用相同的 Trace ID 為 942939f2c44addc1,並分別使用不同的 Span ID.
    • 購物車服務
    • 產品服務
    • 訂單服務
 
三、搭配 Elastic Stack
 
假設有已搭建的 Elastic Stack,並已將專案的日誌收容至 Elasticsearch,可以在 Kibana 使用 Trace ID 作為查詢條件,查看整個鏈路日誌記錄.
  1. 示例一:
  2. 示例二:
 
四、搭配 Zipkin
 
Spring Cloud Sleuth 最常被拿來與 Zipkin 搭配使用,Zipkin 是一個分散式追蹤系統,可以用來在服務架構中,採集時間資訊,以釐清時間延遲問題.
 
假設有已搭建的 Zipkin Server,欲搭配使用,需要新增依賴在 pom.xml,並且定義連線資訊在 application.yml.
  1. 新增依賴在 pom.xml
    • 增加 dependency
  2. 定義連線資訊在 application.yml
 
啟動專案並呼叫 Restful API 後,可以從 Zipkin UI 看到被採集的 Restful API 相關資訊,主要是可以查看呼叫者與被呼叫者的執行開始與結束時間,也可以查看服務之間的依賴關係.
  1. 示例一:
  2. 示例二:


  3. 另外,也可以查看服務之間的依賴關係.
 
五、使用 Annotations 管理 Span
 
  1. 如果想在程式碼中,建立新的 Span,則使用 @NewSpan 在方法上,可搭配 @SpanTag 來加入 Tag 資訊,使用示意如下:
    • 程式碼
    • 日誌紀錄
    • Kibana
    • Zipkin UI
  2. 如果想在程式碼中,在原來的 Span 基礎上增加紀錄資訊,則使用 @ContinueSpan 在方法上,亦可搭配 @SpanTag 來加入 Tag 資訊,使用示意如下:
    • 程式碼
    • 日誌紀錄
    • Kibana
    • Zipkin UI

 
六、結語
 
本文主要針對 Spring Cloud Sleuth 做基礎介紹,將其引用於 Spring Boot 專案中,說明常見搭配 Elastic Stack 及 Zipkin 的使用方式,並說明使用 Annotations 管理 Span 的方式.另外未提及但常見的設定,像是設定採集百分比、設定 MQ 作為採集傳遞機制等,都可於官方文件查閱.
Spring Cloud Sleuth 與 Zipkin 的搭配屬於侵入式的分散式追蹤管理,需在專案內引入使用,也可以直觀地對特定區塊程式碼做追蹤,相較其他強調無侵入式的工具 Pinpoint,Pinpoint 則無需更動專案內容,各有利弊,依專案需求做選擇.
 
七、參考資源
  1. Spring Cloud Sleuth Reference Documentation
  2. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
  3. Zipkin
 
戴佩涵 Hannah Tai