打造立體化監(jiān)控體系的最佳實踐

作者：云棲社區(qū)

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

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

1. 分布式調(diào)用系統(tǒng)的現(xiàn)狀

當(dāng)前，隨著互聯(lián)網(wǎng)架構(gòu)的擴(kuò)張，分布式系統(tǒng)變得日趨復(fù)雜，越來越多的組件開始走向分布式化，如微服務(wù)、消息收發(fā)、分布式數(shù)據(jù)庫、分布式緩存、分布式對象存儲、跨域調(diào)用，這些組件共同構(gòu)成了繁雜的分布式網(wǎng)絡(luò)。

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

阿里巴巴的分布式調(diào)用跟蹤實現(xiàn)——鷹眼

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

上圖是一條來自生成環(huán)境的調(diào)用鏈，在應(yīng)用名列可以看到請求中間過程所經(jīng)過的一系列應(yīng)用，可以看到最先經(jīng)過Buy應(yīng)用，后續(xù)調(diào)用delivery、tee、inventoryplatform等，形成調(diào)用樹（樹上的縮進(jìn)表示嵌套關(guān)系），從調(diào)用樹上很容易看到前端請求的完整處理過程。

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

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

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

2. 使用場景

下面來具體看一下調(diào)用鏈的具體使用場景。

定位異常、耗時問題

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

帶調(diào)用鏈下鉆的監(jiān)控報表

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

鏈路分析

鏈路與調(diào)用鏈不同，鏈路是一個統(tǒng)計學(xué)的概念，而調(diào)用鏈?zhǔn)菃误w調(diào)用的過程。分析鏈路的價值主要體現(xiàn)在以下幾點：

1. 拓?fù)湫螒B(tài)分析：分析來源、去向，識別不合理來源；
2. 依賴梳理：識別易故障點/性能瓶頸、強(qiáng)依賴等問題；
3. 容量估算：根據(jù)鏈路調(diào)用比例、峰值QPS評估容量；

下面來具體分析這四點。

A. 拓?fù)湫螒B(tài)分析：分析來源、去向，識別不合理來源

上圖是全局調(diào)用拓?fù)鋱D，可以明顯的看到不同的應(yīng)用之間存在復(fù)雜的調(diào)用關(guān)系，也可以查看某個應(yīng)用和其他應(yīng)用之間的調(diào)用關(guān)系以及調(diào)用的頻次；圖中紅點表示在調(diào)用過程中出現(xiàn)錯誤。 通過該拓?fù)鋱D，架構(gòu)師可以清楚地觀察到系統(tǒng)上的調(diào)用情況，此外，點擊全局調(diào)用拓?fù)鋱D上的某個節(jié)點，可以下鉆到下圖所示的單應(yīng)用鏈路拓?fù)鋱D。

在以某應(yīng)用為中心的單應(yīng)用鏈路拓?fù)鋱D，可以查看該應(yīng)用在調(diào)用鏈上下游的應(yīng)用之間的具體調(diào)用關(guān)系。

B. 依賴梳理和容量估算

鏈路分析除了進(jìn)行拓?fù)湫螒B(tài)分析之外，還能進(jìn)行依賴梳理：識別易故障點、性能瓶頸、強(qiáng)依賴等問題；也可以根據(jù)鏈路調(diào)用比例、峰值QPS 評估容量。

上圖是一份單鏈路報表，單鏈路報表是指同一HTTP入口的調(diào)用鏈疊加形成、包含所有依賴情況的調(diào)用關(guān)系。上圖左側(cè)模糊部分是一棵調(diào)用樹，它表現(xiàn)了應(yīng)用之間的依賴關(guān)系，與調(diào)用鏈不同的是，這種依賴關(guān)系是統(tǒng)計學(xué)意義上的依賴，因此在該報表上包含了QPS和統(tǒng)計QPS統(tǒng)計類型的數(shù)據(jù)。在進(jìn)行容量預(yù)估時，可以很容易分析上游應(yīng)用對下游造成的壓力。

在該報表上，還可以進(jìn)行依賴梳理方面的工作，根據(jù)出錯率確定易故障點；此外，那些存在強(qiáng)依賴、錯誤阻塞的地方都是潛在故障點；最后，還可以根據(jù)耗時比例進(jìn)行相關(guān)的性能優(yōu)化。

3.最佳實踐

調(diào)用鏈作為排查問題的核心，通過其可以將各類數(shù)據(jù)關(guān)聯(lián)在一起，提高問題排查能力。下面來看一下調(diào)用鏈的最佳實踐——全息排查。

全息排查

在實際問題排查中經(jīng)常會遇到上圖所示的問題，這些問題都具有明確的業(yè)務(wù)含義，這些問題盡管看上去和調(diào)用鏈并無關(guān)系，但可以用調(diào)用鏈得到很好的解決。如上圖右側(cè)所示，A-E五個節(jié)點在調(diào)用鏈上承載的調(diào)用關(guān)系實際上都是一些具體的業(yè)務(wù)，例如節(jié)點A處理HTTP請求表示賣家abc點擊下單；在調(diào)用B時其實在計算賣家xyz在該路線的運費等等。在排查問題時，最有價值的切入點在于先從業(yè)務(wù)問題出發(fā)，再進(jìn)一步在調(diào)用鏈中確認(rèn)問題所在之處。

我們可以根據(jù)業(yè)務(wù)時間ID反查調(diào)用鏈，從而順藤摸瓜找到更多的上下游業(yè)務(wù)信息。例如一個交易訂單（2135897412389123）發(fā)現(xiàn)存在問題，我們可以根據(jù)訂單號查到與之綁定的TraceId，根據(jù)TraceId不僅可以查看系統(tǒng)調(diào)用的事件，還可以看到與業(yè)務(wù)相關(guān)的事件，如用戶下單、當(dāng)前庫存情況等，也就是說根據(jù)交易ID可以在調(diào)用鏈上查看交易、商品庫存以及支付等信息，大大提升錯誤排查速度。

回到剛才提到的三個問題：要分析由哪筆訂單操作引起的調(diào)用異常其實是TraceId到OrderId的一次關(guān)聯(lián)；要分析異常訂單是否由賣家對所在商品的運費模板的某些異常操作導(dǎo)致其實是根據(jù)OrderId關(guān)聯(lián)ItemId再關(guān)聯(lián)TemplateId，最后關(guān)聯(lián)到TraceId；對于第三個問題，通常是由UserId關(guān)聯(lián)到TraceId再關(guān)聯(lián)到MyBizld。

根據(jù)這些問題及其解決方案可以看到，全息排查的關(guān)鍵在于：業(yè)務(wù)時間id與TraceId/RpcId的雙向綁定。 常見的雙向綁定有三種實現(xiàn)方式：

1. 在調(diào)用鏈的Tags 或UserData 中放入業(yè)務(wù)事件id，從而建立調(diào)用鏈到業(yè)務(wù)事件id 的關(guān)聯(lián)；
2. 打通TraceId 到數(shù)據(jù)庫的數(shù)據(jù)變更的關(guān)聯(lián)，從而建立調(diào)用鏈到每次數(shù)據(jù)變更的關(guān)聯(lián)；
3. 在業(yè)務(wù)日志中記錄TraceId、業(yè)務(wù)事件id 等信息，從而建立調(diào)用鏈與業(yè)務(wù)事件日志的關(guān)聯(lián)。

目前，基于阿里云ARMS集成了上述三種雙向綁定實現(xiàn)方式，用戶可以在產(chǎn)品上輕松配置搞定。

全息排查全景圖

上圖是阿里巴巴內(nèi)部的全息排查全景圖。該圖的核心部分是鷹眼最初覆蓋的的后端系統(tǒng)，包括服務(wù)、消息和緩存；在前端層面涉及前端用戶訪問日志，具有關(guān)聯(lián)TraceId的能力；在移動端也具有關(guān)聯(lián)TraceId的能力；通過對TraceId進(jìn)行關(guān)聯(lián)，可以打通用戶訪問日志；在數(shù)據(jù)庫層面，通過SQL語句將TraceId傳到數(shù)據(jù)庫的binlog中，在數(shù)據(jù)復(fù)制和數(shù)據(jù)分發(fā)時可以非常容易獲取到每次數(shù)據(jù)變更的記錄與TraceId的關(guān)聯(lián)；另外，業(yè)務(wù)通過自身的業(yè)務(wù)日志和異常堆棧也可以打印TraceId；這樣一來，業(yè)務(wù)層、移動端、前端、數(shù)據(jù)層所有的組件都與TraceId進(jìn)行了關(guān)聯(lián)，再關(guān)聯(lián)上業(yè)務(wù)中的訂單號、用戶號、商品號、物流單號、交易單號，最后形成一個非常強(qiáng)大的生態(tài)——從一個調(diào)用鏈可以看到上下游相關(guān)的訂單、用戶的詳細(xì)信息，同時可以根據(jù)訂單查到與該訂單相關(guān)的業(yè)務(wù)ID，再根據(jù)業(yè)務(wù)ID擴(kuò)展到與其相關(guān)的更多ID，甚至是TraceId，最后形成TraceId-->業(yè)務(wù)ID-->新的TraceId的網(wǎng)狀結(jié)構(gòu)，將排查問題轉(zhuǎn)化為從網(wǎng)狀結(jié)構(gòu)中尋找需要的整段信息。

通過EDAS+ARMS打造的立體化監(jiān)控體系

目前，通過阿里云提供的EDAS結(jié)合ARMS可以打造立體化監(jiān)控體系，其中EDAS用于應(yīng)用管控層面，用于控制鏈路和應(yīng)用；而ARMS更關(guān)注業(yè)務(wù)運營層面，如電商交易、車聯(lián)網(wǎng)、零售；實際上，監(jiān)控需要全方位關(guān)注業(yè)務(wù)、鏈路、應(yīng)用、系統(tǒng)，通過ARMS與EDAS相互補全，形成了立體化監(jiān)控體系。

【最新快訊】EDAS上線方法追蹤新特性，打通應(yīng)用診斷的"最后一公里"

EDAS 方法追蹤能夠幫助用戶在應(yīng)用運行時出現(xiàn)問題時，進(jìn)行快速的問題排查。

典型的場景

1. 應(yīng)用運行時突然發(fā)現(xiàn)執(zhí)行某一個業(yè)務(wù)邏輯耗時很長，此時希望能夠有一種方式定位運行時代碼各個部分的耗時，以確定耗時點在什么地方。

2. 應(yīng)用運行時一切正常，絕大部分情況下，業(yè)務(wù)運行都非常順暢，但某一例用戶反饋，當(dāng)傳入XXX參數(shù)時，業(yè)務(wù)響應(yīng)非常緩慢。此時希望能夠有一種方式針對特定的方法入?yún)碛^察代碼執(zhí)行情況。

3. 一個比較復(fù)雜的程序方法，其中業(yè)務(wù)邏輯較為復(fù)雜，在真正運行時，無法確定具體調(diào)用了那些邏輯，以及調(diào)用時序。此時希望能夠有一種方式詳細(xì)的展現(xiàn)出方法執(zhí)行的具體邏輯、時序等。

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