打造立體化監控體系的最佳實踐

作者：云棲社區

原文：https://www.aliyun.com/aliware/news/monitoringsolution

摘要： 本文將從分布式系統調用的復雜現狀說起，具體分析調用鏈的三大使用場景，以及調用鏈的最佳實踐，簡述如何將調用鏈作為排查問題的核心，通過其可以將各類數據關聯在一起，提高問題排查能力。【最新快訊】EDAS上線方法追蹤新特性，打通應用診斷的"最后一公里"。

1. 分布式調用系統的現狀

當前，隨著互聯網架構的擴張，分布式系統變得日趨復雜，越來越多的組件開始走向分布式化，如微服務、消息收發、分布式數據庫、分布式緩存、分布式對象存儲、跨域調用，這些組件共同構成了繁雜的分布式網絡。

如上圖右側所示，當應用A發出某個請求時，其背后可能有數十個甚至更多的服務被調用，可謂是“牽一發而動全身”。 如果將分布式系統比作高速公路網，每個前端的請求就相當于高速上行駛的車輛，而處理請求的應用就是高速上的收費站，在收費站上將車輛通行信息記錄成日志，包括時間、車牌、站點、公路、價格等，如果將所有收費站上的日志整合在一起，便可以通過唯一的車牌號確定該車的完整通行記錄；分布式調用系統跟蹤和監控就是類比這種思想，對每一次請求進行跟蹤，進而明確每個請求所經過的應用、耗時等信息。

阿里巴巴的分布式調用跟蹤實現——鷹眼

阿里巴巴中分布式調用跟蹤是采用鷹眼（EagleEye）系統來實現的，鷹眼是基于日志的分布式調用跟蹤系統，其關鍵核心在于調用鏈，為每個請求生成全局唯一的ID（Traceld），通過它將不同系統的“孤立的”調用信息關聯在一起，還原出更多有價值的數據。

上圖是一條來自生成環境的調用鏈，在應用名列可以看到請求中間過程所經過的一系列應用，可以看到最先經過Buy應用，后續調用delivery、tee、inventoryplatform等，形成調用樹（樹上的縮進表示嵌套關系），從調用樹上很容易看到前端請求的完整處理過程。

另外值得注意的一點，上圖是由白色背景和藍色背景組成。其中藍色背景表示調用鏈經過消息之后，變成了異步的消息通道，其后續處理過程也都是異步處理過程；白色背景處表示同步過程。一般而言，對于前端的用戶等待的時間是不包含藍色背景內的耗時，也就是只包含了同步處理的時間。

在上圖所示的頁面中也清晰地展示了每塊應用處理請求得具體耗時，非常直觀地進行定位；此外，狀態信息也是值得關注的一點，如上圖所示，如果在調用過程中發生錯誤，就會出現異常（圖中紅色區域所標注），通過點擊狀態碼，用戶可以查看錯誤的具體信息。

鷹眼于2013年在阿里巴巴內部上線，目前支撐阿里集團泛電商、高德、優酷等業務，技術層面覆蓋前端網關接入層、遠端服務調用框架（RPC）、消息隊列、數據庫、分布式緩存、自定義組件（如支付、搜索SDK、本地方法埋點等）；2016年在阿里云的中間件云產品EDAS發布，對外提供服務；此外，鷹眼也支持專有云輸出。

2. 使用場景

下面來具體看一下調用鏈的具體使用場景。

定位異常、耗時問題

可以在業務異常日志的錯誤信息中找到Traceld（如圖中的TraceId=ac18287913742691251746923），之后在鷹眼系統中只需要輸入Traceld，就可以看到調用鏈中具體的情況，在調用鏈上更加直觀地定位到問題（如上圖所示），層層排查后確定問題的所在。

帶調用鏈下鉆的監控報表

對于分布式調用跟蹤系統而言，它并不僅僅提供了調用鏈這一功能，因為它對所有中間件的調用做埋點，所以中間件上的所有情況都可以監控的到。因此，在形成調用鏈的過程中也會形成一份詳細的調用監控報表，它與其他監控的不同之處在于：該監控報表是帶有上下鉆取功能的報表。因為調用鏈是詳細的底層統計，對上可以形成的報表維度是非常豐富的，在上圖所示的調用報表里，不僅可以看到服務的情況，還可以下鉆到它所調用服務的情況；另外從監控報表上還可以進行調用鏈的下鉆，查看清晰的調用鏈信息。

鏈路分析

鏈路與調用鏈不同，鏈路是一個統計學的概念，而調用鏈是單體調用的過程。分析鏈路的價值主要體現在以下幾點：

1. 拓撲形態分析：分析來源、去向，識別不合理來源；
2. 依賴梳理：識別易故障點/性能瓶頸、強依賴等問題；
3. 容量估算：根據鏈路調用比例、峰值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的雙向綁定。 常見的雙向綁定有三種實現方式：

1. 在調用鏈的Tags 或UserData 中放入業務事件id，從而建立調用鏈到業務事件id 的關聯；
2. 打通TraceId 到數據庫的數據變更的關聯，從而建立調用鏈到每次數據變更的關聯；
3. 在業務日志中記錄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. 應用運行時突然發現執行某一個業務邏輯耗時很長，此時希望能夠有一種方式定位運行時代碼各個部分的耗時，以確定耗時點在什么地方。

2. 應用運行時一切正常，絕大部分情況下，業務運行都非常順暢，但某一例用戶反饋，當傳入XXX參數時，業務響應非常緩慢。此時希望能夠有一種方式針對特定的方法入參來觀察代碼執行情況。

3. 一個比較復雜的程序方法，其中業務邏輯較為復雜，在真正運行時，無法確定具體調用了那些邏輯，以及調用時序。此時希望能夠有一種方式詳細的展現出方法執行的具體邏輯、時序等。

此外，以上的任何一種場景，都希望代碼無入侵，可以在應用運行時不停機的情況下，定位問題。 
EDAS 方法追蹤采用 JVM 字節碼增強的技術，對選中方法的所有方法調用增加必要的耗時與調用序列記錄的增強，從而達到觀看執行過程中的具體執行序列的目的。