1012
打造立體化監控體係的最佳實踐——分布式調用跟蹤和監控時間
摘要： 本文將從分布式係統調用的複雜現狀說起，具體分析調用鏈的三大使用場景，以及調用鏈的最佳實踐，簡述如何將調用鏈作為排查問題的核心，通過其可以將各類數據關聯在一起，提高問題排查能力。
【**最新快訊**】EDAS上線方法追蹤新特性，打通應用診斷的"最後一公裏"。
1. 分布式調用係統的現狀
當前，隨著互聯網架構的擴張，分布式係統變得日趨複雜，越來越多的組件開始走向分布式化，如微服務、消息收發、分布式數據庫、分布式緩存、分布式對象存儲、跨域調用，這些組件共同構成了繁雜的分布式網絡。
如上圖右側所示，當應用A發出某個請求時，其背後可能有數十個甚至更多的服務被調用，可謂是“牽一發而動全身”。 如果將分布式係統比作高速公路網，每個前端的請求就相當於高速上行駛的車輛，而處理請求的應用就是高速上的收費站，在收費站上將車輛通行信息記錄成日誌，包括時間、車牌、站點、公路、價格等，如果將所有收費站上的日誌整合在一起，便可以通過唯一的車牌號確定該車的完整通行記錄；分布式調用係統跟蹤和監控就是類比這種思想，對每一次請求進行跟蹤，進而明確每個請求所經過的應用、耗時等信息。
阿裏巴巴的分布式調用跟蹤實現——鷹眼
阿裏巴巴中分布式調用跟蹤是采用鷹眼（EagleEye）係統來實現的，鷹眼是基於日誌的分布式調用跟蹤係統，其關鍵核心在於調用鏈，為每個請求生成全局唯一的ID（Traceld），通過它將不同係統的“孤立的”調用信息關聯在一起，還原出更多有價值的數據。
上圖是一條來自生成環境的調用鏈，在應用名列可以看到請求中間過程所經過的一係列應用，可以看到最先經過Buy應用，後續調用delivery、tee、inventoryplatform等，形成調用樹（樹上的縮進表示嵌套關係），從調用樹上很容易看到前端請求的完整處理過程。
另外值得注意的一點，上圖是由白色背景和藍色背景組成。其中藍色背景表示調用鏈經過消息之後，變成了異步的消息通道，其後續處理過程也都是異步處理過程；白色背景處表示同步過程。一般而言，對於前端的用戶等待的時間是不包含藍色背景內的耗時，也就是隻包含了同步處理的時間。
在上圖所示的頁麵中也清晰地展示了每塊應用處理請求得具體耗時，非常直觀地進行定位；此外，狀態信息也是值得關注的一點，如上圖所示，如果在調用過程中發生錯誤，就會出現異常（圖中紅色區域所標注），通過點擊狀態碼，用戶可以查看錯誤的具體信息。
鷹眼於2013年在阿裏巴巴內部上線，目前支撐阿裏集團泛電商、高德、優酷等業務，技術層麵覆蓋前端網關接入層、遠端服務調用框架（RPC）、消息隊列、數據庫、分布式緩存、自定義組件（如支付、搜索SDK、本地方法埋點等）；2016年在阿裏雲的中間件雲產品EDAS發布，對外提供服務；此外，鷹眼也支持私有雲輸出。
2. 使用場景
下麵來具體看一下調用鏈的具體使用場景。
定位異常、耗時問題
可以在業務異常日誌的錯誤信息中找到Traceld（如圖中的TraceId=ac18287913742691251746923），之後在鷹眼係統中隻需要輸入Traceld，就可以看到調用鏈中具體的情況，在調用鏈上更加直觀地定位到問題（如上圖所示），層層排查後確定問題的所在。
帶調用鏈下鑽的監控報表
對於分布式調用跟蹤係統而言，它並不僅僅提供了調用鏈這一功能，因為它對所有中間件的調用做埋點，所以中間件上的所有情況都可以監控的到。因此，在形成調用鏈的過程中也會形成一份詳細的調用監控報表，它與其他監控的不同之處在於：該監控報表是帶有上下鑽取功能的報表。因為調用鏈是詳細的底層統計，對上可以形成的報表維度是非常豐富的，在上圖所示的調用報表裏，不僅可以看到服務的情況，還可以下鑽到它所調用服務的情況；另外從監控報表上還可以進行調用鏈的下鑽，查看清晰的調用鏈信息。
鏈路分析
鏈路與調用鏈不同，鏈路是一個統計學的概念，而調用鏈是單體調用的過程。分析鏈路的價值主要體現在以下幾點：
- 拓撲形態分析：分析來源、去向，識別不合理來源；
- 依賴樹立：識別易故障點/性能瓶頸、強依賴等問題；
- 容量估算：根據鏈路調用比例、峰值QPS評估容量；
下麵來具體分析這四點。
A. 拓撲形態分析：分析來源、去向，識別不合理來源
上圖是全局調用拓撲圖，可以明顯的看到不同的應用之間存在複雜的調用關係，也可以查看某個應用和其他應用之間的調用關係以及調用的頻次；圖中紅點表示在調用過程中出現錯誤。 通過該拓撲圖，架構師可以清楚地觀察到係統上的調用情況，此外，點擊全局調用拓撲圖上的某個節點，可以下鑽到下圖所示的單應用鏈路拓撲圖。
在以某應用為中心的單應用鏈路拓撲圖，可以查看該應用在調用鏈上下遊的應用之間的具體調用關係。
B. 依賴梳理和容量估算
鏈路分析除了進行拓撲形態分析之外，還能進行依賴梳理：識別易故障點、性能瓶頸、強依賴等問題；也可以根據鏈路調用比例、峰值QPS 評估容量。
上圖是一份單鏈路報表，單鏈路報表是指同一HTTP入口的調用鏈疊加形成、包含所有依賴情況的調用關係。上圖左側模煳部分是一棵調用樹，它表現了應用之間的依賴關係，與調用鏈不同的是，這種依賴關係是統計學意義上的依賴，因此在該報表上包含了QPS和統計QPS統計類型的數據。在進行容量預估時，可以很容易分析上遊應用對下遊造成的壓力。
在該報表上，還可以進行依賴梳理方麵的工作，根據出錯率確定易故障點；此外，那些存在強依賴、錯誤阻塞的地方都是潛在故障點；最後，還可以根據耗時比例進行相關的性能優化。
3.最佳實踐
調用鏈作為排查問題的核心，通過其可以將各類數據關聯在一起，提高問題排查能力。下麵來看一下調用鏈的最佳實踐——全息排查。
全息排查
在實際問題排查中經常會遇到上圖所示的問題，這些問題都具有明確的業務含義，這些問題盡管看上去和調用鏈並無關係，但可以用調用鏈得到很好的解決。如上圖右側所示，A-E五個節點在調用鏈上承載的調用關係實際上都是一些具體的業務，例如節點A處理HTTP請求表示賣家abc點擊下單；在調用B時其實在計算賣家xyz在該路線的運費等等。在排查問題時，最有價值的切入點在於先從業務問題出發，再進一步在調用鏈中確認問題所在之處。
我們可以根據業務時間ID反查調用鏈，從而順藤摸瓜找到更多的上下遊業務信息。例如一個交易訂單（2135897412389123）發現存在問題，我們可以根據訂單號查到與之綁定的TraceId，根據TraceId不僅可以查看係統調用的事件，還可以看到與業務相關的事件，如用戶下單、當前庫存情況等，也就是說根據交易ID可以在調用鏈上查看交易、商品庫存以及支付等信息，大大提升錯誤排查速度。
回到剛才提到的三個問題：要分析由哪筆訂單操作引起的調用異常其實是TraceId到OrderId的一次關聯；要分析異常訂單是否由賣家對所在商品的運費模板的某些異常操作導致其實是根據OrderId關聯ItemId再關聯TemplateId，最後關聯到TraceId；對於第三個問題，通常是由UserId關聯到TraceId再關聯到MyBizld。
根據這些問題及其解決方案可以看到，全息排查的關鍵在於：業務時間id與TraceId/RpcId的雙向綁定。 常見的雙向綁定有三種實現方式：
- 在調用鏈的Tags 或UserData 中放入業務事件id，從而建立調用鏈到業務事件id 的關聯；
- 打通TraceId 到數據庫的數據變更的關聯，從而建立調用鏈到每次數據變更的關聯；
- 在業務日誌中記錄TraceId、業務事件id 等信息，從而建立調用鏈與業務事件日誌的關聯。
目前，基於阿裏雲ARMS集成了上述三種雙向綁定實現方式，用戶可以在產品上輕鬆配置搞定。
全息排查全景圖
上圖是阿裏巴巴內部的全息排查全景圖。該圖的核心部分是鷹眼最初覆蓋的的後端係統，包括服務、消息和緩存；在前端層麵涉及前端用戶訪問日誌，具有關聯TraceId的能力；在移動端也具有關聯TraceId的能力；通過對TraceId進行關聯，可以打通用戶訪問日誌；在數據庫層麵，通過SQL語句將TraceId傳到數據庫的binlog中，在數據複製和數據分發時可以非常容易獲取到每次數據變更的記錄與TraceId的關聯；另外，業務通過自身的業務日誌和異常堆棧也可以打印TraceId；這樣一來，業務層、移動端、前端、數據層所有的組件都與TraceId進行了關聯，再關聯上業務中的訂單號、用戶號、商品號、物流單號、交易單號，最後形成一個非常強大的生態——從一個調用鏈可以看到上下遊相關的訂單、用戶的詳細信息，同時可以根據訂單查到與該訂單相關的業務ID，再根據業務ID擴展到與其相關的更多ID，甚至是TraceId，最後形成TraceId-->業務ID-->新的TraceId的網狀結構，將排查問題轉化為從網狀結構中尋找需要的整段信息。
通過EDAS+ARMS打造的立體化監控體係
目前，通過阿裏雲提供的EDAS結合ARMS可以打造立體化監控體係，其中EDAS用於應用管控層麵，用於控製鏈路和應用；而ARMS更關注業務運營層麵，如電商交易、車聯網、零售；實際上，監控需要全方位關注業務、鏈路、應用、係統，通過ARMS與EDAS相互補全，形成了立體化監控體係。
**
【最新快訊】EDAS上線方法追蹤新特性，打通應用診斷的"最後一公裏"
EDAS 方法追蹤能夠幫助用戶在應用運行時出現問題時，進行快速的問題排查。**
典型的場景
1. 應用運行時突然發現執行某一個業務邏輯耗時很長，此時希望能夠有一種方式定位運行時代碼各個部分的耗時，以確定耗時點在什麼地方。
應用運行時一切正常，絕大部分情況下，業務運行都非常順暢，但某一例用戶反饋，當傳入XXX參數時，業務響應非常緩慢。此時希望能夠有一種方式針對特定的方法入參來觀察代碼執行情況。
一個比較複雜的程序方法，其中業務邏輯較為複雜，在真正運行時，無法確定具體調用了那些邏輯，以及調用時序。此時希望能夠有一種方式詳細的展現出方法執行的具體邏輯、時序等。
此外，以上的任何一種場景，都希望代碼無入侵，可以在應用運行時不停機的情況下，定位問題。
EDAS 方法追蹤采用 JVM 字節碼增強的技術，對選中方法的所有方法調用增加必要的耗時與調用序列記錄的增強，從而達到觀看執行過程中的具體執行序列的目的。
EDAS基礎版：使用方法追蹤新特性；EDAS高級版：使用鏈路監控
最後更新：2017-05-31 09:01:24