勇攀监控高峰-EMonitor之根因分析 背景
背景
阿里集團針對故障處理提出了“1/5/10”的目標(biāo)-- 1 分鐘發(fā)現(xiàn)、5 分鐘定位、10 分鐘恢復(fù)，這對我們的定位能力提出了更高的要求。
EMonitor?是一款集成?Tracing?和?Metrics，服務(wù)于餓了么所有技術(shù)部門的一站式監(jiān)控系統(tǒng)，其覆蓋了
- 前端監(jiān)控、接入層監(jiān)控；
- 業(yè)務(wù) Trace 和 Metric 監(jiān)控；
- 所有的中間件監(jiān)控；
- 容器監(jiān)控、物理機監(jiān)控、機房網(wǎng)絡(luò)監(jiān)控。
每日處理總數(shù)據(jù)量近 PB，每日寫入指標(biāo)數(shù)據(jù)量上百 T，日均幾千萬的指標(biāo)查詢量，內(nèi)含上萬個圖表、數(shù)千個指標(biāo)看板，并且已經(jīng)將所有層的監(jiān)控數(shù)據(jù)打通并串聯(lián)了起來。但是在故障來臨時，用戶仍然需要花費大量時間來查看和分析 EMonitor 上的數(shù)據(jù)
比如阿里本地生活的下單業(yè)務(wù)，涉及到諸多應(yīng)用，每個應(yīng)用諸多 SOA 服務(wù)之間錯綜復(fù)雜的調(diào)用關(guān)系，每個應(yīng)用還依賴 DB、Redis、MQ 等等資源，在下單成功率下跌時，這些應(yīng)用的負(fù)責(zé)人都要在 EMonitor 上查看指標(biāo)曲線以及鏈路信息來進(jìn)行人肉排障以自證清白，耗時耗力，所以自動化的根因分析必不可少。
根因分析建模
業(yè)界已經(jīng)有好多在做根因分析的了，但是大都準(zhǔn)確率不高，大部分還在 40% 到 70% 之間，從側(cè)面說明根因分析確實是一個難啃的骨頭。
根因分析看起來很龐大，很抽象，無從下手，從不同的角度（可能是表象）去看它，就可能走向不同的路。那如何才能透過表象來看到本質(zhì)呢？
我這里并不會一開始就給你列出高大上的算法解決方案，而是要帶你重新認(rèn)知根因分析要解決的問題到底是什么。其實好多人對要解決的問題都模糊不清，你只有對問題理解清楚了，才能有更好的方案來解決它。
要解決什么樣的問題
舉個例子：現(xiàn)有一個應(yīng)用，擁有一堆容器資源，對外提供了諸多 SOA 服務(wù)或者 Http 服務(wù)，同時它也依賴了其他應(yīng)用提供的服務(wù)，以及 DB 資源、Redis 資源、MQ 資源等等；那我們?nèi)绾尾拍軌蛉娴恼瓶剡@個應(yīng)用的健康狀況呢？
我們需要掌控：
- 掌控這個應(yīng)用的所有入口服務(wù)的「耗時」和「狀態(tài)」
- 掌控每個入口服務(wù)之后每種操作的「耗時」和「狀態(tài)」
一個應(yīng)用都有哪些入口？
- SOA 服務(wù)入口；
- Http 服務(wù)入口；
- MQ 消費消息入口；
- 定時 job 入口；
- 其他的一些入口。
進(jìn)入每個入口之后，都可能會有一系列的如下?5 種操作和?1 種行為（下面的操作屬性都是以阿里本地生活的實際情況為例，并且都包含所在機房的屬性）：
- DB 遠(yuǎn)程操作：有 dal group、table、operation（比如select、update、insert等）、sql 的操作屬性；
- Redis 遠(yuǎn)程操作：有 command 的操作屬性；
- MQ 遠(yuǎn)程操作（向MQ中寫消息）：有 exchange、routingKey、vhost 的操作屬性；
- RPC 遠(yuǎn)程操作：有 遠(yuǎn)程依賴的 appId、遠(yuǎn)程 method 的操作屬性；
- Local 操作（即除了上述4種遠(yuǎn)程操作之外的本地操作）: 暫無屬性；
- 拋出異常的行為：有異常 name 的屬性。
那我們其實就是要去統(tǒng)計每個入口之后的 5 種操作的耗時情況以及狀態(tài)情況，以及拋出異常的統(tǒng)計情況。
針對遠(yuǎn)程操作其實還要明細(xì)化，上述遠(yuǎn)程操作的每一次耗時是包含如下 3 大部分：
- 客戶端建立連接、發(fā)送請求和接收響應(yīng)的耗時；
- 網(wǎng)絡(luò)的耗時；
- 服務(wù)器端執(zhí)行的耗時。
有了上述三要素，才能去確定遠(yuǎn)程操作到底是哪出了問題，不過實際情況可能并沒有上述三要素。
故障的結(jié)論
有了上述數(shù)據(jù)的全面掌控，當(dāng)一個故障來臨的時候，我們可以給出什么樣的結(jié)論？
- 哪些入口受到影響了？
- 受影響的入口的本地操作受到影響了？
-
受影響的入口的哪些遠(yuǎn)程操作受到影響了？
- 具體是哪些遠(yuǎn)程操作屬性受到影響了？
- 是客戶端到服務(wù)器端的網(wǎng)絡(luò)受到影響了？
- 是服務(wù)器端出了問題嗎？
- 受影響的入口都拋出了哪些異常？
上述的這些結(jié)論是可以做到非常高的準(zhǔn)確性的，因為他們都是可以用數(shù)據(jù)來證明的。
然而第二類根因，卻是無法證明的：
- GC 問題；
- 容器問題。
他們一旦出問題，更多的表現(xiàn)是讓上述 5 種操作耗時變長，并且是沒法給出數(shù)據(jù)來明確證明他們和 5 種操作之間的關(guān)聯(lián)，只是以一種推測的方式來懷疑，從理論上來說這里就會存在誤定位的情況。
還有第三類更加無法證明的根因：
- 變更問題
昨天的變更或者當(dāng)前的變更到底和當(dāng)前的故障之間有沒有關(guān)聯(lián)，更是無法給出一個證明的，所以也只能是瞎推測。
我們可以明確的是 5 種操作的根因，還需要進(jìn)一步去查看是否是上述第二類根因或者第三類根因，他們只能作為一些輔助結(jié)論，因為沒法給出嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)證明。
根因分析實現(xiàn)
在明確了我們要解決的問題以及要求的故障結(jié)論之后，我們要采取什么樣的方案來解決呢？下面首先會介紹一個基本功能「指標(biāo)下鉆分析」。
指標(biāo)下鉆分析
一個指標(biāo)，有多個 tag，當(dāng)該指標(biāo)總體波動時，指標(biāo)下鉆分析能夠幫你分析出是哪些 tag 組合導(dǎo)致的波動。
比如客戶端的 DB 操作抖動了，利用指標(biāo)下鉆分析就可以分析出
- 哪個機房抖動了？
- 哪個 dal group 抖動了？
- 哪張表抖動了？
- 哪種操作抖動了？
- 哪個 sql 抖動了？
再比如遠(yuǎn)程 RPC 操作抖動了，利用指標(biāo)下鉆分析就可以分析出
- 哪個機房抖動了？
- 哪個遠(yuǎn)程 appId 抖動了？
- 哪個遠(yuǎn)程 method 抖動了？
其實這個就是去年 AIOPS 競賽的題目，詳細(xì)見：
http://iops.ai/competition_detail/?competition_id=8&flag=1
通常的方案：
我們的方案：
針對去年的決賽題目，我們的這個方案的跑分達(dá)到了 0.95 以上，應(yīng)該就在前三名了。
根因分析流程
有了指標(biāo)下鉆分析功能之后，我們來看如何進(jìn)行根因分析：
- 針對入口服務(wù)的響應(yīng)時間和成功率判斷是否異常，若無異常則無根因可分析；
- 針對入口服務(wù)的 5 種操作進(jìn)行指標(biāo)下鉆分析，得出異常波動的操作類型有哪些；
-
然后到對應(yīng)操作類型的指標(biāo)中再次進(jìn)行指標(biāo)下鉆分析，得出該操作下：
- 哪些入口受到該操作的波動影響了？
- 哪些操作屬性異常波動了？
- 假如該操作是遠(yuǎn)程操作，還要繼續(xù)深入服務(wù)器端進(jìn)行分析：
假如你有遠(yuǎn)程操作數(shù)據(jù)的 3 要素的話，那么是可以分析出：
- 客戶端建立連接、發(fā)送請求和接收響應(yīng)耗時問題； - 網(wǎng)絡(luò)耗時問題； - 服務(wù)器端耗時問題。
假如沒有相關(guān)數(shù)據(jù)的話，那就只能相對來說進(jìn)行推測了（準(zhǔn)確率也會受到影響）：
DAL 是我們的分庫分表的數(shù)據(jù)庫代理層，同時起到一些熔斷限流的作用，所以一條 SQL 執(zhí)行時間會包含在 DAL 代理層的停留時間、以及在 DB 層的執(zhí)行時間，利用指標(biāo)下鉆分析，可以分析出如下的一些根因：
- 某個 table 的所有操作耗時抖動？- 某條sql操作耗時抖動？- 某臺具體DB實例抖動？- SQL的停留時間 or 執(zhí)行時間抖動？ - 比如客戶端的 RPC 操作來說，可以繼續(xù)遞歸到遠(yuǎn)程 appId 的；- 針對受影響的這些入口使用指標(biāo)下鉆分析，哪些異常也抖動了（有些異常一直在拋，但是跟本次故障無關(guān)）；
- 再次查看上述抖動的操作是否是由 GC 問題、容器問題、變更問題等引起的。
落地情況
阿里本地生活的根因分析能力，1 個月內(nèi)從產(chǎn)生根因分析的想法到實現(xiàn)方案上線到生產(chǎn)（不包括指標(biāo)下鉆分析的實現(xiàn)，這個是之前就已經(jīng)實現(xiàn)好的了），1 個月內(nèi)在生產(chǎn)上實驗和優(yōu)化并推廣開來，總共 2 個月內(nèi)實現(xiàn)了從 0 到 1 并取得了如下成績
- 50 個詳細(xì)記載的案例中準(zhǔn)確定位 48 次，準(zhǔn)確率 96%；
- 最高一天執(zhí)行定位 500 多次；
- 平均定位耗時 1 秒；
- 詳細(xì)的定位結(jié)果展示。
我們對定位準(zhǔn)確性的要求如下：
- 要明確給出受到影響的入口服務(wù)有哪些；
- 每個受到影響的入口服務(wù)抖動的操作根因以及操作屬性都要正確；
每個入口服務(wù)抖動的根因很可能不一樣的，比如當(dāng)前應(yīng)用的 SOA1 是由于 Redis 操作抖動，當(dāng)前應(yīng)用的 SOA2 是由于遠(yuǎn)程 RPC 依賴的其他 SOA3 抖動導(dǎo)致，SOA3 是由于 Redis 操作抖動導(dǎo)致；
- 客戶端操作耗時抖動到底是客戶端原因還是服務(wù)器端原因要保證正確；
- 容器問題時，要保證不能定位到錯誤的容器上。
準(zhǔn)確率為什么這么高？
我認(rèn)為主要是以下 3 個方面：
數(shù)據(jù)的完整度
假如是基于采樣鏈路去分析，必然會存在因為漏采導(dǎo)致誤判的問題。
我們分析的數(shù)據(jù)是全量鏈路數(shù)據(jù)轉(zhuǎn)化成的指標(biāo)數(shù)據(jù)，不存在采樣的問題，同時在分析時可以直接基于指標(biāo)進(jìn)行快速分析，臨時查采樣的方式分析速度也是跟不上的。
建模的準(zhǔn)確性
你的建模方案能回答出每個 SOA 服務(wù)抖動的根因分別是什么嗎？
絕大部分的建模方案可能都給不出嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)證明，以 DB 是根因為例，他們的建模可能是 SOA 服務(wù)是一個指標(biāo)，DB 操作耗時是一個指標(biāo)，2 者之間是沒有任何關(guān)聯(lián)的，沒有數(shù)據(jù)關(guān)聯(lián)你就給不出嚴(yán)謹(jǐn)?shù)淖C明，即沒法證明 DB 的這點抖動跟那個 SOA 服務(wù)之間到底有沒有關(guān)聯(lián)，然后就只能處于瞎推測的狀態(tài)，這里就必然存在誤判的情況。
而我們上述的建模是建立了相關(guān)的關(guān)聯(lián)，我們會統(tǒng)計每個入口后的每種操作的耗時，是可以給到嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)證明。
異常判定的自適應(yīng)性
比如 1 次 SOA 服務(wù)整體耗時 1s，遠(yuǎn)程調(diào)用 RPC1 耗時 200ms，遠(yuǎn)程調(diào)用 RPC2 耗時 500ms，到底是哪個 RPC 調(diào)用耗時抖動呢？耗時最長的嗎？超過一定閾值的 RPC 嗎？
假如你有閾值、同環(huán)比的限制，那么準(zhǔn)確率一定不高的。我們的指標(biāo)下鉆分析在解決此類問題的時候，是通過當(dāng)前情況下的波動貢獻(xiàn)度的方式來計算，即使你耗時比較高，但是和之前正常情況波動不大，那么就不是波動的根因。
速度為什么這么快？
我認(rèn)為主要是以下 2 方面的原因：
業(yè)內(nèi)領(lǐng)先的時序數(shù)據(jù)庫 LinDB
根因分析需要對諸多指標(biāo)的全量維度數(shù)據(jù)進(jìn)行 group by 查詢，因此背后就需要依靠一個強大的分布式時序數(shù)據(jù)庫來提供實時的數(shù)據(jù)查詢能力。
LinDB 時序數(shù)據(jù)庫是我們阿里本地生活監(jiān)控系統(tǒng) E-Monitor 上一階段的自研產(chǎn)物，在查詢方面：
- 強悍的數(shù)據(jù)壓縮：時序數(shù)據(jù)原始數(shù)據(jù)量和實際存儲量之比達(dá)到 58:1，相同 PageCache 的內(nèi)存可以比別的系統(tǒng)容納更多的數(shù)據(jù)；
- 高效的索引設(shè)計：索引的預(yù)過濾，改造版的 RoaringBitmap 之間的 and or 操作來進(jìn)行高效的索引過濾；
- 單機內(nèi)充分并行化的查詢機制：利用 akka 框架對整個查詢流程異步化。
整體查詢效率是 InfluxDB 的幾倍到幾百倍，詳細(xì)見文章
分布式時序數(shù)據(jù)庫 - LinDB ??https://zhuanlan.zhihu.com/p/35998778
指標(biāo)下鉆分析算法的高效
- 我們不需要每個時間線都進(jìn)行預(yù)測；
- 實際要計算的方案個數(shù)非常之少；
- 方案算分上可以適應(yīng)于任何加減乘除之類的指標(biāo)計算上，比如根因定位中的平均響應(yīng)時間 = 總時間 / 總次數(shù)
SOA1 的平均響應(yīng)時間 t1 和 SOA2 的平均響應(yīng)時間 t2，SOA1 和 SOA2 的總體平均響應(yīng)時間并不是 t1 和 t2 的算術(shù)平均而是加權(quán)平均，如果是加權(quán)平均，那么久需要多存儲一些額外的信息，并且需要進(jìn)行額外的加權(quán)計算
實際案例
案例 1
故障現(xiàn)場如下，某個應(yīng)用的 SOA 服務(wù)抖動上升：
直接點擊根因分析，就可以分析到如下結(jié)果
AppId1 的 SOA 服務(wù)在某個機房下抖動了
-
依賴的 AppId2 的 SOA 服務(wù)抖動
-
依賴的 AppId3 的 SOA 服務(wù)抖動
- 依賴的 AppId5 的本地處理和 Redis 操作耗時抖動
- 依賴的 AppId6 的本地處理和 Redis 操作耗時抖動
- 依賴的 AppId4 的本地處理和 Redis 操作耗時抖動
-
這里的本地處理包含獲取 Redis 連接對象 Jedis 的耗時，這一塊沒有耗時打點就導(dǎo)致劃分到本地處理上了，后續(xù)會進(jìn)行優(yōu)化。這里沒有給出詳細(xì)的 Redis 集群或者機器跟我們的實際情況有關(guān)，可以暫時忽略這一點。
點擊上面的每個應(yīng)用，下面的表格都會列出所點擊應(yīng)用的詳細(xì)故障信息
- 受影響的 SOA 服務(wù)有哪些，比如 AppId1 的 3 個 SOA 服務(wù)受到影響；
- 每個 SOA 服務(wù)抖動的根因，比如 AppId1 的 3 個 SOA 服務(wù)都受到 AppId2 的 1 個 SOA 服務(wù)的抖動影響；
- 表格中每一個鏈接都可以跳轉(zhuǎn)到對應(yīng)的指標(biāo)曲線監(jiān)控面板上。
再比如點擊 AppId4，顯示如下：
AppId4 的 1 個 SOA 方法抖動
- 該方法的本地處理抖動（實際是獲取 Redis 連接對象 Jedis 的耗時抖動）；
- 該方法依賴的 Redis 操作抖動；
- 該方法拋出 Redis 連接異常；
案例2
故障現(xiàn)場如下，某個應(yīng)用的 SOA 服務(wù)抖動上升
點擊根因分析，就可以幫你分析到如下結(jié)果
AppId1 的 SOA 服務(wù)在某個機房下抖動了
-
依賴的 AppId2 的 SOA 服務(wù)抖動
- 依賴的 DB 服務(wù)抖動
-
依賴的 AppId3 的 SOA 服務(wù)抖動
-
依賴的 AppId2 的 SOA 服務(wù)抖動
- 依賴的 DB 服務(wù)抖動
-
點擊 AppId2，可以看下詳細(xì)情況，如下所示：
從表格中就可以看到，根因是 DB 的一臺實例抖動導(dǎo)致這個 dal group 所有操作抖動。
作者
李剛，網(wǎng)名乒乓狂魔，餓了么監(jiān)控組研發(fā)專家，餓了么內(nèi)部時序數(shù)據(jù)庫 LinDB 的項目負(fù)責(zé)人，餓了么根因分析項目負(fù)責(zé)人，目前致力于監(jiān)控的智能分析領(lǐng)域以及下一代全景監(jiān)控的體系化構(gòu)建；
林濱（予譜），餓了么監(jiān)控組前端工程師，現(xiàn)負(fù)責(zé)一站式監(jiān)控系統(tǒng) EMonitor 的前端開發(fā)，旨在將繁雜的數(shù)據(jù)以高可視化輸出。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的勇攀监控高峰-EMonitor之根因分析 背景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 训练机器人看脸读“心”，真的靠谱吗？
- 下一篇： Java代码精简之道