分佈式追蹤系統
- 使用 Zipkin 和 Brave 實現分佈式系統追蹤（基礎篇） - 推酷
- OpenZipkin · A distributed tracing system
- Twitter zipkin 分佈式跟蹤系統的設計與實現 - 馬宏的世界 - 博客頻道 - CSDN.NET
- openzipkin/brave: Java distributed tracing implementation compatible with Zipkin backend services.
- openzipkin/zipkin: Zipkin is a distributed tracing system
- zipkin - liaokailin的專欄 - 博客頻道 - CSDN.NET
- #研發解決方案介紹#Tracing（鷹眼） - 旁觀者 - 博客園
淘寶如何實現的：
在前端請求到達服務器時，應用容器在執行實際業務處理以前，會先執行 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-一個瀏覽器請求可能觸發的系統間調用git
圖6-1描述了 EagleEye 在一個很是簡單的分佈式調用場景裏作的事情，就是爲每次調用分配 TraceId、RpcId，放在 ThreadLocal 的調用上下文上面，調用結束的時候，把 TraceId、RpcId 打印到訪問日誌。相似的其餘網絡調用中間件的調用過程也都比較相似，這裏再也不贅述了。訪問日誌裏面，通常會記錄調用時間、遠端IP地址、結果狀態碼、調用耗時之類，也會記錄與此次調用類型相關的一些信息，如URL、服 務名、消息topic等。不少調用場景會比上面說的徹底同步的調用更爲複雜，好比會遇到異步、單向、廣播、併發、批處理等等，這時候須要妥善處理好 ThreadLocal 上的調用上下文，避免調用上下文混亂和沒法正確釋放。另外，採用多級序號的 RpcId 設計方案會比單級序號遞增更容易準確還原當時的調用狀況。github
最後，EagleEye 分析系統把調用鏈相關的全部訪問日誌都收集上來，按 TraceId 彙總在一塊兒以後，就能夠準確還原調用當時的狀況了。redis
圖6-2-一個典型的調用鏈sql
如圖6-2所示，就是採集自淘寶線上環境的某一條實際調用鏈。調用鏈經過樹形展示了調用狀況。調用鏈能夠清晰地看到當前請求的調用狀況，幫助問題定 位。如上圖，mtop應用發生錯誤時，在調用鏈上能夠直接看出這是由於第四層的一個(tair@1)請求致使網絡超時，使最上層頁面出現超時問題。這種調用鏈，能夠在 EagleEye 系統監測到包含異常的訪問日誌後，把當前的錯誤與整個調用鏈關聯起來。問題排查人員在發現入口錯誤量上漲或耗時上升時，經過 EagleEye 查找出這種包含錯誤的調用鏈採樣，提升故障定位速度。mongodb
調用鏈數據在容量規劃和穩定性方面的分析數據庫
若是對同一個前端入口的多條調用鏈作彙總統計，也就是說，把這個入口URL下面的全部調用按照調用鏈的樹形結構所有疊加在一塊兒，就能夠獲得一個新的樹結構（如圖6-3所示）。這就是入口下面的全部依賴的調用路徑狀況。後端
圖6-3-對某個入口的調用鏈作統計以後獲得的依賴分析
這種分析能力對於複雜的分佈式環境的調用關係梳理尤其重要。傳統的調用統計日誌是按固定時間窗口預先作了統計的日誌，上面缺乏了鏈路細節致使沒辦法對超過兩層以上的調用狀況進行分析。例如，後端數據庫就沒法評估數據庫訪問是來源於最上層的哪些入口；每一個前端系統也沒法清楚肯定當前入口因爲雙十一活動流量翻倍，會對後端哪些系統形成多大的壓力，須要分別準備多少機器。有了 EagleEye 的數據，這些問題就迎刃而解了。
- 埋點
- 實現線程內 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