分散式鏈路追蹤技術

• 2022 年 3 月 15 日
• 筆記
• 監控運維

概述

在微服務架構的系統中，請求在各服務之間流轉，調用鏈錯綜複雜，一旦出現了問題和異常，很難追查定位，這個時候就需要鏈路追蹤來幫忙了。鏈路追蹤系統能追蹤並記錄請求在系統中的調用順序，調用時間等一系列關鍵資訊，從而幫助我們定位異常服務和發現性能瓶頸。

微服務的監控主要包含一下三個方面：

• 通過收集日誌，對系統和各個服務的運行狀態進行監控
• 通過收集量度（Metrics），對系統和各個服務的性能進行監控
• 通過分散式追蹤，追蹤服務請求是如何在各個分布的組件中進行處理的細節

對於是日誌和量度的收集和監控，大家會比較熟悉。常見的日誌收集架構包含利用Fluentd對系統日誌進行收集，然後利用ELK或者Splunk進行日誌分析。而對於性能監控，Prometheus是常見的流行的選擇。

分散式鏈路跟蹤主要功能：

• 故障快速定位：可以通過調用鏈結合業務日誌快速定位錯誤資訊。
• 鏈路性能可視化：各個階段鏈路耗時、服務依賴關係可以通過可視化介面展現出來。
• 鏈路分析：通過分析鏈路耗時、服務依賴關係可以得到用戶的行為路徑，匯總分析應用在很多業務場景。

基本原理

目前常見的鏈路追蹤系統的原理基本都是根據2010年由Google發布的一篇《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》論文為原型實現的。

Trace

指一個請求經過所有服務的路徑，每一條局部鏈路都用一個全局唯一的traceid來標識。

Span

為了表達父子調用關係，引入了span

同一層級parent id相同，span id不同，span id從小到大表示請求的順序。

總結：通過事先在日誌中埋點，找出相同traceId的日誌，再加上parent id和span id就可以將一條完整的請求調用鏈串聯起來。

Annotations

Dapper中還定義了annotation的概念，用於用戶自定義事件，用來輔助定位問題。

通常包含以下四個Annotaion註解資訊，分別對應客戶端和服務端相應事件。

調用耗時可以通過T4-T1得到，客戶端發送數據包的網路耗時可以通過T2-T1實現。

鏈路資訊的還原依賴於帶內和帶外兩種數據。

帶外數據是各個節點產生的事件，如cs，ss，這些數據可以由節點獨立生成，並且需要集中上報到存儲端。

帶內數據如traceid,spanid,parentid，這些數據需要從鏈路的起點一直傳遞到終點。通過帶內數據的傳遞，可以將一個鏈路的所有過程串起來。

取樣和存儲

為了減少性能消耗，避免存儲資源的浪費，dapper並不會上報所有的span數據，而是使用取樣的方式。舉個例子，每秒有1000個請求訪問系統，如果設置取樣率為1/1000，那麼只會上報一個請求到存儲端。

鏈路中的span數據經過收集和上報後會集中存儲在一個地方，Dapper使用了BigTable數據倉庫，常用的存儲還有ElasticSearch, HBase, In-memory DB等。

Opentraceing 數據模型

Opentracing 是分散式鏈路追蹤的一種規範標準，是 CNCF（雲原生計算基金會）下的項目之一。只要某鏈路追蹤系統實現了 Opentracing 規定的介面（interface），符合Opentracing 定義的表現行為，那麼就可以說該應用符合 Opentracing 標準。

它的數據模型和GoogleDapper論文里的如出一轍。

span

Span 是一條追蹤鏈路中的基本組成要素，一個 Span 表示一個獨立的工作單元，比如可以表示一次函數調用，一次 HTTP 請求等等。Span 會記錄如下基本要素:

• 服務名稱(operation name)

• 服務的開始時間和結束時間

• K/V形式的Tags

  保存用戶自定義標籤，主要用於鏈路追蹤結果的查詢過濾。Span 中的 tag 僅自己可見，不會隨著 SpanContext 傳遞給後續 Span。

• K/V形式的Logs

  與 tags 不同的是，logs 還會記錄寫入 logs 的時間，因此 logs 主要用於記錄某些事件發生的時間。

• SpanContext

  SpanContext攜帶著一些用於跨服務通訊的（跨進程）數據，主要包含：

  • 足夠在系統中標識該span的資訊，比如：span_id,trace_id。
  • Baggage Items，為整條追蹤鏈保存跨服務（跨進程）的K/V格式的用戶自定義數據。

• References：該span對一個或多個span的引用（通過引用SpanContext）

trace

Trace表示一次完整的追蹤鏈路，trace由一個或多個span組成。

Inject/Extract

Opentracing 提供了 Inject/Extract 用於在請求中注入 SpanContext 或者從請求中提取出 SpanContext。

客戶端通過 Inject 將 SpanContext 注入到載體中，隨著請求一起發送到服務端。

服務端則通過 Extract 將 SpanContext 提取出來,進行後續處理。

常見框架

框架對比

Google Dapper論文發出來之後，很多公司基於鏈路追蹤的基本原理給出了各自的解決方案，具體如下：

• Twitter：Zipkin
• Uber：Jaeger
• Elastic Stack：Elastic APM
• Apache：SkyWalking（中國開源愛好者吳晟開源）
• Naver：Pinpoint（韓國公司開發）
• 阿里：鷹眼。
• 大眾點評：Cat。
• 京東：Hydra

為了便於各系統間能彼此兼容互通，OpenTracing組織制定了一系列標準，旨在讓各系統提供統一的介面。

中國這些基本都沒開源，主要的開源框架對比如下：

原理

Zipkin

Zipkin 相對成熟,開源於2012年，同時也比較簡單，Java 系大部分都會選擇 Zipkin。

在服務運行的過程中會產生很多鏈路資訊，產生數據的地方可以稱之為Reporter。將鏈路資訊通過多種傳輸方式如HTTP，RPC，kafka消息隊列等發送到Zipkin的採集器，Zipkin處理後最終將鏈路資訊保存到存儲器中。運維人員通過UI介面調用介面即可查詢調用鏈資訊。

Jaeger

Jaeger 則是 CNCF 旗下，對 K8s 有較好的兼容性，Go 語言系可能是個不錯的選擇。

Jaeger的原理和Zipkin二者的架構有些類似。都是由嵌入到程式碼中的client來收集數據，並傳輸到Collector端進行存儲，然後集中通過UI進行展示。

具體流程如下：

• 1）客戶端通過 6831 埠上報數據給 agent
• 2）agent通過 14250 埠將數據發送給 collector
• 3）collector 將數據寫入 kafka
• 4）Ingester 從 kafka中讀取數據並寫入存儲後端
• 5）query 從存儲後端查詢數據並展示

另外近兩年基於 ServiceMesh 的 」無」 侵入式鏈路追蹤也廣受歡迎，似乎是一個被看好的方向，其代表作之一 Istio 便是使用 CNCF 出身的 Jaeger，且 Jaeger 還兼容 Zipkin，在這點上 Jaeger 完勝。