雲效故障定位研究論文被ICSE 2021 SEIP track收錄

近期，由阿里云云效團隊聯合復旦大學CodeWisdom研究團隊、阿里技術風險部安全生產團隊，合作完成的論文《MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems》被ICSE 2021 SEIP track錄用。本文針對大規模微服務系統的三種可用性問題，提出了一種高效的根因定位方法MicroHECL。

MicroHECL基於動態構建的服務間的依賴圖，分析了所有可能的異常傳播鏈路，並基於相關性分析對候選根因進行了排序。本文將機器學習和統計方法相結合，並通過個性化的模型來檢測不同類型的服務異常（如性能異常、可靠性異常、流量異常）。爲了提高異常檢測的效率，在異常傳播鏈分析的過程中，MicroHECL採用了剪枝策略來消除不相關的服務調用。最後，通過實驗研究，證明了MicroHECL在可用性問題異常檢測的準確性和效率方面都顯著優於兩種先進的基線方法。MicroHECL已經在阿里巴巴內部落地實踐，截止2020年7月，實際top-3的命中率達到了68%，根因定位的時間從原來的30分鐘縮短到了5分鐘。

研究背景

微服務架構已經成爲構建雲原生應用的最新趨勢，越來越多的公司選擇從單體系統遷移到微服務架構。工業微服務系統通常包含成百上千的應用，這些系統是高度動態和複雜的，一個服務可以有幾個到幾千個實例運行在不同的容器和服務器上，而可用性問題一直是大規模微服務系統面臨的一個關鍵挑戰。在這些系統中，服務質量（如性能、可靠性）的任何異常都有可能沿着服務調用鏈傳播，並最終導致業務級別的可用性問題（如訂單成功率下跌），這也是企業普遍碰到的問題。當監控系統監控到可用性問題時，它的根因服務和異常類型需要在短時間（如3分鐘）內定位，以便開發人員快速解決問題。

 

阿里巴巴的電子商務系統每月活躍用戶超過8.46億人，它採用微服務架構，並且包含超過3萬多個服務，這些服務都配備了一個稱爲EagleEye的大型監控基礎設施。作爲業務的載體，系統需要保證高可用。因此這些系統都部署了一個業務監控平臺來及時的發出可用性問題報警。這些可用性問題通常表示業務運行中的問題，例如下單成功量下跌、交易成功率下跌等。這些可用性問題可能是由不同類型的異常引起的，異常可能從一個服務傳播到另一個服務，最終導致可用性問題。在本文中，我們重點關注以下三種導致阿里巴巴大部分可用性問題的異常類型：

1. 性能異常。性能異常表現爲響應時間（RT）的異常增加。它通常是由有問題的系統實現或不正確的環境配置（例如容器或虛擬機的CPU/內存配置）引起的。
2. 可靠性異常。可靠性異常表現爲錯誤數量（EC）的異常增加，例如服務調用失敗的次數。它通常由代碼缺陷或環境故障（例如服務器或網絡中斷）引起的異常。
3. 流量異常。流量異常表現爲每秒異常增加或減少的查詢數量（QPS）。流量的異常增加可能會導致服務中斷，而異常流量的減少可能表明許多請求無法到達服務。它通常是由不正確的流量配置（例如Nginx的限流）、DoS攻擊或意外的壓測等引起。

相關研究

現有的方法不能有效的支持大規模微服務系統可用性問題根因定位，業界開發人員通常還需要依賴可視化工具來分析日誌和鏈路，以識別可能的異常和異常傳播鏈路，從而找到根本原因。研究人員已經提出了使用鏈路分析或服務依賴圖的方法來自動定位微服務或更廣泛的基於服務的系統的異常根因。基於鏈路分析的方法需要昂貴的鏈路數據收集和處理，因此不能有效的用於大規模系統。基於服務依賴圖的方法是基於服務調用或因果關係來構造服務依賴圖。這些方法通過遍歷服務依賴圖並用服務的指標數據（如響應時間）檢測可能的異常來定位根因，然而這些方法由於對服務異常檢測的不準確以及對服務依賴圖的低效遍歷而使用受限，尤其是在有很多服務和依賴關係的大規模微服務系統中。

方法概述

MicroHECL是一種解決可用性問題的高效的根因定位方法。在我們的場景中，可用性問題通常是從業務視角觀測到的。例如，訂單成功量下跌，它可能是由不同類型的異常引起的。目前MicroHECL支持三種類型的異常（即性能異常、可靠性異常、流量異常）。在定位特定類型的異常時，MicroHECL考慮相應的服務調用指標以及異常的傳播方向。例如，在定位性能異常時，MicroHECL會主要考慮服務間調用的響應時間和異常傳播方向（即從下游向上遊傳播）。MicroHECL的方法概述如圖1所示，主要包括以下三個部分。

 

服務依賴圖構建

當運行時的監控系統檢測到可用性問題時，MicroHECL將啓動根因分析過程。它基於運行時監控系統採集到的服務調用關係和指標，動態的構建一定時間窗口（例如最近30分鐘）內的目標微服務系統的服務調用圖。服務調用圖是由一系列的服務節點S={S1, S2,..., Sn}組成，每一個節點都代表了該服務在最近30分鐘內發生過調用關係。邊Si-->Sj代表了在最近一個時間窗口內服務Si調用過服務Sj。爲了對可用性問題進行根因分析，服務調用圖上還記錄了各種度量指標，例如響應時間（RT）、錯誤數量（EC）和每秒請求數（QPS），這些監控到的數據都被存儲到了時間序列數據庫（TSDB）。爲了優化性能，服務調用關係是隨着異常調用鏈分析的過程按需並增量構建的，只有在異常傳播鏈分析過程中，到達了某個服務，纔會去拉取與它相關的指標數據。

異常傳播鏈分析

一個可用性問題最初是在某個服務（稱爲初始異常服務）上由監控系統發現的，但是異常的根因往往是它的上游或下游服務。根因服務和初始異常服務通常都處於由一系列的異常服務組成的異常傳播鏈上。異常傳播鏈分析的目的就是通過分析初始異常服務中可能的異常傳播鏈來確定一組候選的異常根因服務，在分析的過程中，會沿着異常傳播的相反方向。爲了提高效率，MicroHECL採用了一種剪枝策略來消除和當前異常傳播鏈不相關的服務調用。通過異常傳播鏈的分析，最終可以得到一系列的候選異常根因服務。

候選根因排序

MicroHECL根據導致給定可用性問題的可能性對候選根因進行排序。通過對監測數據的分析，我們發現初始異常服務的異常指標數據與根因服務的異常指標有相似的變化趨勢。注意這裏初始異常服務的指標是某種業務指標（例如：訂單成功量），而候選根因的異常指標是質量指標（如RT、EC、QPS）。因此我們使用皮爾遜相關性係數對這兩個異常指標（X，Y）的變化趨勢進行相關性分析，並基於相關性值P（X，Y）進行候選根因的排序。

 

異常傳播鏈分析

分析過程

可用性問題可能是由不同類型的異常引起的。對於不同的異常類型，服務異常檢測中考慮的指標和傳播鏈分析中考慮的異常傳播方向是不同的。如表1所示，性能異常、可靠性異常和流量異常考慮的主要指標分別是響應時間（RT）、錯誤數量（EC）和每秒請求數（QPS）。通常性能異常和可靠性異常的傳播方向都是從下游到上游的，而流量異常的傳播方向是從上游到下游的。

表1. 可用性問題的指標和異常傳播方向

 

2、異常傳播鏈路擴展

對於每個異常傳播鏈，通過從起始節點（即檢測到的初始異常服務的相鄰異常節點）沿着異常傳播方向進行迭代擴展。在每次迭代中，根據異常類型對當前節點的上下游節點進行異常檢測，並將檢測到的異常節點添加到當前異常傳播鏈中。當不能向鏈中添加更多節點時，異常傳播鏈的擴展結束。例如，對於S4的異常傳播鏈，擴展以S1結束，S1是S4的上游節點並且符合流量異常的傳播方向。相似的，對於S7的異常傳播鏈，擴展以S9和S10結束。

3、候選根因排序

當初始異常服務的所有異常傳播鏈分析結束時，將異常傳播鏈擴展結束位置的所有服務作爲候選的根因服務。例如，圖中所示的分析過程得出的候選根因包括S1、S9和S10。

服務異常檢測

在異常傳播鏈分析過程中，我們需要根據一些指標數據不斷的檢測一個服務是否存在某種類型的異常。例如，在圖2中，通過入口節點異常檢測，我們首先確定了S4和S7，然後通過服務異常檢測在異常傳播鏈擴展中識別出異常服務S1、S9、S10。根據不同的指標的特點，我們爲每種異常類型選擇了不同的分析模型，這些分析模型是根據相應指標類型的波動特徵和指標之間的關係設計的。

 

1、性能異常檢測

性能異常檢測是基於異常增加的響應時間（RT），這裏的挑戰是如何區分RT的異常波動和正常波動。圖3(a)和圖3(d)分別顯示了兩個小時和一週的響應時間波動。從中可以看出，在一天的不同時間段和一週的不同日子裏，RT都有周期性的波動。如果我們使用像3-sigma這樣的簡單規則，這些週期性波動很可能會被認爲是性能異常。爲了識別異常波動，我們不僅考慮了當前時間段的指標，還需要考慮前一天的同一時間段和前一週的同一時間段的指標。而且，在歷史數據中，響應時間大多數處於正常波動狀態，只有少量的異常波動。

 

基於RT數據的特點，我們選擇了OC-SVM（one class support vector machine）作爲RT異常波動的預測模型。OC-SVM僅使用特定類別（正常RT波動）的信息來學習出一個分類器，該分類器可以識別出屬於該類別的樣本，並將其他樣本識別爲異常值（異常RT波動）。OC-SVM具有建模簡單、可解釋性強、泛化能力強等優點。我們爲模型定義了以下4種特徵：

1. Number of Over-Max Values: 當前檢測窗口中Response Time的值大於給定比較時間窗口內Response Time的最大值的數量。
2. Delta of Maximum Values: 當前檢測窗口中Response Time的最大值與給定比較時間窗口內的Response Time最大值的差值。
3. Number of Over-Average Values: 當前檢測時間窗口中超過給定比較時間窗口中Response Time滑動平均值最大值的數量。
4. Ratio of Average Values: 當前檢測窗口中Response Time的平均值與給定時間窗口內Response Time的滑動平均值的最大值的比值。

我們把最後10分鐘作爲異常檢測的時間窗口。對於對比的時間段，我們考慮以下三種：當前檢測窗口之前的最後一小時，前一天相同的時間段，前一週同一天的相同時間段。因此，我們一共可以得到12個特徵值。

 

爲了訓練模型，我們在阿里巴巴的監控系統中從不同的系統收集到了100000個案例。我們也收集了600個正負比例1:1的案例用於模型的驗證。模型訓練結果如表2所示。

表2. 性能異常的模型訓練效果

 

3、流量異常檢測

流量異常檢測是基於QPS的異常波動。如圖3(c)和圖3(f)所示，QPS從短期和長期來看是比較符合正態分佈特點的。因此，我們選擇使用3-sigma規則來檢測異常的QPS波動。同樣採用最後10分鐘作爲異常檢測的時間窗口，並基於最近一個小時的QPS值，我們使用3-sigma規則來檢測當前檢測窗口中的異常值。

 

此外，經過觀察發現，單純使用3-sigma仍然會存在一定的誤報行爲。爲了進一步消除誤報，我們還計算了這些異常服務的QPS值和初始異常服務的業務指標之間的皮爾遜相關性係數，只有當相關性高於預定義的閾值（例如0.9）並且在當前檢測窗口中識別出3-sigma異常值，纔會認爲當前服務存在流量異常。

剪枝策略

異常傳播鏈路可能具有多個分支，並且分支的數量可以在異常傳播鏈擴展期間繼續增長。因此，異常傳播鏈分析的一個主要挑戰在於大規模服務依賴圖上異常傳播分支的數量可能成指數增長。而在這些分支中，一些異常服務和服務調用可能與當前可用性異常問題無關。爲了解決這一問題，提高分析效率，我們採用剪枝策略來消除不相關的異常服務調用。剪枝策略是基於假設異常傳播鏈中兩個連續的服務調用的邊具有相似的指標變化趨勢。例如，在圖2中，邊S1 -> S4上的QPS應該和邊S4->S5上的QPS具有相似的變化趨勢，否則S1->S4這條邊就應該被剪枝。類似的，S7->S9邊上的RT的指標變化應該和邊S5->S7上RT的指標變化具有相似的趨勢。

 

檢測策略在異常傳播鏈分析的擴展過程中被使用，我們只考慮相鄰兩條邊上相同異常類型的指標數據（例如RT、EC、QPS）在最近一個時間窗口(例如，最近60分鐘)內的相似性。相似性的計算使用公式1。如果相似度值低於閾值（如0.7），那麼當前異常邊會被剪枝掉。

實驗評估

爲了評估MicroHECL的有效性和效率，我們進行了一系列的實驗研究來回答下面三個研究問題：

1. RQ1（定位精確度）：MicroHECL在定位微服務系統的可用性問題的根因和特定異常類型的根因方面精確度如何？
2. RQ2（定位效率）：MicroHECL在根因定位過程中隨着服務數量的增加，定位效率和可擴展性會有怎樣的變化？
3. RQ3（剪枝效果）：MicroHECL在不同的相似度閾值下對定位的精確度和效率有何影響？

實驗設置

從2020年2月到6月，我們在阿里巴巴的大型電子商務系統的28個子系統中收集了75個可用性問題異常案例，這些子系統平均包含265（最小7，最大1687，中位數82）個服務。在這75個可用性問題案例中，有37個是由性能異常導致，有43個是由可靠性問題導致，有21個是由流量異常導致。我們把MicroHECL與其它兩種基線方法（MonitorRank、Microscope）進行了實驗對比，並使用公式2中HR@k 和MRR來評估方法根因定位的精確度。

 

定位精確度（RQ1）

表4顯示了MicroHECL和其它兩種基線方法的總體精確度評估結果，可以看出MicroHECL在HR@1、HR@3和HR@5的命中率分別爲0.48、0.67和0.72，MRR爲0.58。在所有這些指標方面，MicroHECL都顯著優於基線方法。

表4. 總體準確度評估

 

我們還評估了MicroHECL在不同異常類型方面的精確度。從表5可以看出，MicroHECL在這三種異常類型方面都優於基線方法。而且可以看出MicroHECL在性能異常方面的優勢最爲顯著，在流量異常方面的優勢不太顯著。

表5. 不同異常類型的準確度

 

定位效率（RQ2）

本文中的75個可用性問題異常案例來自28個子系統，這些子系統有不同的服務數量。爲了評估MicroHECL的效率和可擴展性，我們在這75個案例中分析了MicroHECL和兩種基線方法的異常檢測時間。並研究了異常檢測的時間如何隨目標系統的大小（服務數量）而變化，實驗結果如圖。請注意，從同一個子系統中收集的可用性問題可能有多個，每個可用性問題在圖中都用一個點表示。總體來說，MicroHECL的執行時間比Microscope少22.3%，比MonitorRank少了31.7%。在這三種方法中，對於不同大小的子系統和大多數的可用性問題，MicroHECL使用的時間都是最少的。

 

圖中的兩條曲線分別顯示了MicroHECL相對於兩種基線方法平均時間差的變化。可以看出，當服務數量小於250個時，MicroHECL的優勢並不顯著；當服務數量超過250個時，MicroHECL的優勢隨着服務數量的增加而越來越顯著。此外，MicroHECL（包括兩種基線方法）的執行時間隨着服務數量的增加而線性增加，表現出良好的可擴展性。

 

剪枝效果（RQ3）

剪枝策略是影響根因定位精確度和效率的關鍵。本文通過分析75個可用性問題的根因定位的精確度和時間消耗隨不同的相似度閾值的變化來評價剪枝策略的效果， 並選擇HR@3作爲精確度的評估指標。評估結果如圖5所示，從中可以看出，隨着閾值的增加，精確度和時間都會有所下降。而且當閾值從0增加到0.7時，精確度保持在0.67，而時間從75秒減少到了46秒。實驗結果驗證了剪枝策略在保證精確度的前提下，顯著提高異常定位效率的有效性，並且對於這些可用性案例，最佳相似度閾值爲0.7。

 

企業實踐

MicroHECL已經實現爲一個基於EagleEye和其它監控基礎設施的分佈式系統在阿里巴巴部署運行。在實際應用中，MicroHECL還支持更細粒度的故障定位，比如將中間件（數據庫，消息隊列，緩存服務）等作爲定位的目標，這些組件和交互的指標數據也會被記錄到服務調用圖上。在過去的5個多月裏，MicroHECL處理了超過600個可用性問題，平均可以在76s產出定位結果，開發人員通常可以在監控系統檢測到可用性問題後5分鐘內確認並開始故障修復。來自開發人員的反饋表明，大多數開發人員都比較信任系統的推薦，默認會把推薦的結果作爲異常的根因。

 

在實際應用中，除了一些系統因指標數據缺失導致無法準確定位之外，我們還分析了MicroHECL不能準確定位其它異常根因的案例，發現MicroHECL仍需要從多方面進行改進。例如，一些可用性異常被檢測到後，它的服務質量指標可能沒有任何異常。而且有一些異常可能是慢慢積累起來的，它的指標波動可能超過了異常監測的時間窗口。這些需要更先進的技術來改進目前的方法。

總結

本文針對微服務系統的可用性問題，提出了一種高效的根因定位方法MicroHECL, 它通過動態構造服務調用圖並分析可能的異常傳播鏈路。與現有方法不同，MicroHECL使用基於機器學習和統計方法的個性化模型來檢測不同類型的服務異常（即性能異常、可靠性異常、流量異常），並在異常傳播鏈分析中採用剪枝策略來消除不相關的服務調用。 實驗研究和阿里巴巴的實際應用都證實了MicroHECL的精確度和有效性，未來我們也會在雲效上提供風險預測定位的能力。

作者：Yvonne

原文鏈接 

本文爲阿里雲原創內容，未經允許不得轉載