#研發解決方案介紹#Tracing（鷹眼）

時間 2019-11-13

標籤研發解決方案介紹 tracing 简体版

原文原文鏈接

分佈式系統爲何須要 Tracing？

先介紹一個概念： 分佈式跟蹤，或 分佈式追蹤。

電商平臺由數以百計的分佈式服務構成，每個請求路由過來後，會通過多個業務系統並留下足跡，併產生對各類Cache或DB的訪問，可是這些分散的數據對於問題排查，或是流程優化都幫助有限。對於這麼一個跨進程/跨線程的場景，彙總收集並分析海量日誌就顯得尤其重要。要能作到追蹤每一個請求的完整調用鏈路，收集調用鏈路上每一個服務的性能數據，計算性能數據和比對性能指標（SLA），甚至在更遠的將來可以再反饋到服務治理中，那麼這就是分佈式跟蹤的目標了。在業界，twitter 的 zipkin 和淘寶的鷹眼就是相似的系統，它們都起源於 Google Dapper 論文，就像歷史上 Hadoop 發源於 Google Map/Reduce 論文，HBase 源自 Google BigTable 論文同樣。

好了，整理一下，Google叫Dapper，淘寶叫鷹眼，Twitter叫ZipKin，京東商城叫Hydra，eBay叫Centralized Activity Logging (CAL)，大衆點評網叫CAT，咱們叫Tracing。

這樣的系統一般有幾個設計目標：

（1）低侵入性——做爲非業務組件，應當儘量少侵入或者無侵入其餘業務系統，對於使用方透明，減小開發人員的負擔；

（2）靈活的應用策略——能夠（最好隨時）決定所收集數據的範圍和粒度；

（3）時效性——從數據的收集和產生，到數據計算和處理，再到最終展示，都要求儘量快；

（4）決策支持——這些數據是否能在決策支持層面發揮做用，特別是從 DevOps 的角度；

（5）可視化纔是王道。

先來一個直觀感覺：

下面依次展現了 ZipKin、鷹眼、窩窩的調用鏈繪製界面。

圖1 twitter zipkin 調用鏈

圖2 淘寶鷹眼的調用鏈

圖3 京東商城hydra調用鏈

圖4 窩窩tracing調用鏈

鼠標移動到調用鏈的每一層點擊，能夠看到執行時長、宿主機IP、數據庫操做、傳入參數甚至錯誤堆棧等等具體信息。

淘寶如何實現的：

同一次請求的全部相關調用的狀況，在淘寶 EagleEye 裏稱做 調用鏈。同一個時刻某一臺服務器並行發起的網絡調用有不少，怎麼識別這個調用是屬於哪一個調用鏈的呢？能夠在各個發起網絡調用的中間件上下手。

在前端請求到達服務器時，應用容器在執行實際業務處理以前，會先執行 EagleEye 的埋點邏輯（相似 Filter 的機制），埋點邏輯爲這個前端請求分配一個全局惟一的調用鏈ID。這個ID在 EagleEye 裏面被稱爲 TraceId，埋點邏輯把 TraceId 放在一個調用上下文對象裏面，而調用上下文對象會存儲在 ThreadLocal 裏面。調用上下文裏還有一個ID很是重要，在 EagleEye 裏面被稱做 RpcId。RpcId 用於區分同一個調用鏈下的多個網絡調用的發生順序和嵌套層次關係。對於前端收到請求，生成的 RpcId 固定都是0。 html

當這個前端執行業務處理須要發起 RPC 調用時，淘寶的 RPC 調用客戶端 HSF 會首先從當前線程 ThreadLocal 上面獲取以前 EagleEye 設置的調用上下文。而後，把 RpcId 遞增一個序號。在 EagleEye 裏使用多級序號來表示 RpcId，好比前端剛接到請求以後的 RpcId 是0，那麼它第一次調用 RPC 服務A時，會把 RpcId 改爲 0.1。以後，調用上下文會做爲附件隨此次請求一塊兒發送到遠程的 HSF 服務器。前端

HSF 服務端收到這個請求以後，會從請求附件裏取出調用上下文，並放到當前線程 ThreadLocal 上面。若是服務A在處理時，須要調用另外一個服務，這個時候它會重複以前提到的操做，惟一的差異就是 RpcId 會先改爲 0.1.1 再傳過去。服務A的邏輯所有處理完畢以後，HSF 在返回響應對象以前，會把此次調用狀況以及 TraceId、RpcId 都打印到它的訪問日誌之中，同時，會從 ThreadLocal 清理掉調用上下文。如圖6-1展現了一個瀏覽器請求可能觸發的系統間調用。 mysql

圖6-1-一個瀏覽器請求可能觸發的系統間調用 redis

圖6-1描述了 EagleEye 在一個很是簡單的分佈式調用場景裏作的事情，就是爲每次調用分配 TraceId、RpcId，放在 ThreadLocal 的調用上下文上面，調用結束的時候，把 TraceId、RpcId 打印到訪問日誌。相似的其餘網絡調用中間件的調用過程也都比較相似，這裏再也不贅述了。訪問日誌裏面，通常會記錄調用時間、遠端IP地址、結果狀態碼、調用耗時之類，也會記錄與此次調用類型相關的一些信息，如URL、服務名、消息topic等。不少調用場景會比上面說的徹底同步的調用更爲複雜，好比會遇到異步、單向、廣播、併發、批處理等等，這時候須要妥善處理好 ThreadLocal 上的調用上下文，避免調用上下文混亂和沒法正確釋放。另外，採用多級序號的 RpcId 設計方案會比單級序號遞增更容易準確還原當時的調用狀況。 sql

最後，EagleEye 分析系統把調用鏈相關的全部訪問日誌都收集上來，按 TraceId 彙總在一塊兒以後，就能夠準確還原調用當時的狀況了。 mongodb

圖6-2-一個典型的調用鏈數據庫

如圖6-2所示，就是採集自淘寶線上環境的某一條實際調用鏈。調用鏈經過樹形展示了調用狀況。調用鏈能夠清晰地看到當前請求的調用狀況，幫助問題定位。如上圖，mtop應用發生錯誤時，在調用鏈上能夠直接看出這是由於第四層的一個(tair@1)請求致使網絡超時，使最上層頁面出現超時問題。這種調用鏈，能夠在 EagleEye 系統監測到包含異常的訪問日誌後，把當前的錯誤與整個調用鏈關聯起來。問題排查人員在發現入口錯誤量上漲或耗時上升時，經過 EagleEye 查找出這種包含錯誤的調用鏈採樣，提升故障定位速度。後端

調用鏈數據在容量規劃和穩定性方面的分析 瀏覽器

若是對同一個前端入口的多條調用鏈作彙總統計，也就是說，把這個入口URL下面的全部調用按照調用鏈的樹形結構所有疊加在一塊兒，就能夠獲得一個新的樹結構（如圖6-3所示）。這就是入口下面的全部依賴的調用路徑狀況。服務器

圖6-3-對某個入口的調用鏈作統計以後獲得的依賴分析

這種分析能力對於複雜的分佈式環境的調用關係梳理尤其重要。傳統的調用統計日誌是按固定時間窗口預先作了統計的日誌，上面缺乏了鏈路細節致使沒辦法對超過兩層以上的調用狀況進行分析。例如，後端數據庫就沒法評估數據庫訪問是來源於最上層的哪些入口；每一個前端系統也沒法清楚肯定當前入口因爲雙十一活動流量翻倍，會對後端哪些系統形成多大的壓力，須要分別準備多少機器。有了 EagleEye 的數據，這些問題就迎刃而解了。

下圖6-4展現了數據流轉過程。

圖6-4 鷹眼的數據收集和存儲

京東如何實現的：

京東商城引入了阿里開源的服務治理中間件 Dubbo，因此它的分佈式跟蹤 Hydra 基於 Dubbo 就能作到對業務系統幾乎無侵入了。

Hydra 的領域模型以下圖7所示：

圖7 hydra 領域模型以及解釋

hydra 數據存儲是 HBase，以下圖8所示：

圖8 hydra 架構

窩窩如何實現的：

2012年，逐漸看到自建分佈式跟蹤系統的重要性，但隨即意識到若是沒有對 RPC 調用框架作統一封裝，就可能侵入到每個業務工程裏去寫埋點日誌，因而推廣 Dubbo 也提上日程。2013年，肯定系統建設目標，開始動手。因爲 tracing 跟 DevOps 息息相關，因此數據聚合、存儲、分析和展現由運維部向榮牽頭開發，各個業務工程數據埋點和上報由研發部國璽負責。

通過後續向榮、劉卓、國璽、明斌等人的不斷改進，技術選型大體以下所示。

埋點

實現線程內 trace 上下文傳遞，即服務器內部的方法互調時不須要強制在方法形參中加 Message 參數；
實現 trace 埋點邏輯自動織入功能，即業務開發人員不須要在方法中打印 trace 日誌，只須要給該方法加註解標識；
原理：
- 利用 Javaagent 機制，執行 main 方法以前，會先執行 premain 方法，在該方法中將字節碼轉換器載入 instrumentation，然後 jvm 在加載 class 文件以前都會先執行字節碼轉換器。
- 字節碼轉換器中的邏輯爲，識別出注解 trace 的類及方法，並修改該方法字節碼，織入埋點邏輯。進入方法時會初始 trace 上下文信息，並存儲在線程的 threadLocals 中，退出方法會打印 trace 日誌並清空該方法的上下文。

數據聚合
- 應用層 trace 日誌經過 flume agents 實時發送至 flume collector；
數據存儲
- 服務端分別經過 hdfs-sink 和 hbase-sink，實時錄入至 hbase、hdfs；
- hdfs 有 tmp 臨時文件存放實時聚合過來的數據，每5分鐘生成一個 done 文件；
數據分析和統計
- load 程序每 4 分鐘檢查 done 文件並存放至 hive 表 hkymessage 指定分區；
- 分析程序每5分鐘執行一次, 將生成統計數據入庫, 結果集數據以下：
  數據格式：{5個分層的5個響應時段請求個數合集} {5個分層5-10s和大於10s散點數據合集} 當前5分鐘最後一次請求rootid 統計時間
數據展現
- 基於 Python 的 Django