雲效故障定位研究論文被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所示，主要包括以下三個部分。

圖1. MicroHECL概述

服務依賴圖建構

當運作時的監控系統檢測到可用性問題時，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. 皮爾遜相關性系數計算公式

分析過程

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

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

1、入口節點異常檢測

初始異常服務視為異常檢測的入口節點。MicroHECL根據不同的異常類型和相應的名額資料，對入口節點相鄰的節點（即直接調用入口節點或被入口節點直接調用的服務）進行服務異常檢測。對于每個被檢測到的相鄰異常節點，如果其與入口節點的上下遊關系與檢測到的異常類型的異常傳播方向一緻，則從其開始進行異常傳播鍊的分析，并将檢測到的異常類型作為異常傳播鍊的異常類型。例如，對于圖中的入口節點S5，檢測到兩個相鄰的異常節點為S4和S7，并且它們的異常類型分别是流量異常和性能異常。由于S4是S5的上遊節點，其與流量異常的傳播方向一緻（ 從上遊到下遊），是以從S4開始進行業務異常的傳播鍊分析。同樣，性能異常的傳播鍊分析是從S7開始的。

圖2. 異常傳播鍊路分析過程

2、異常傳播鍊路擴充

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

3、候選根因排序

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

服務異常檢測

在異常傳播鍊分析過程中，我們需要根據一些名額資料不斷的檢測一個服務是否存在某種類型的異常。例如，在圖2中，通過入口節點異常檢測，我們首先确定了S4和S7，然後通過服務異常檢測在異常傳播鍊擴充中識别出異常服務S1、S9、S10。根據不同的名額的特點，我們為每種異常類型選擇了不同的分析模型，這些分析模型是根據相應名額類型的波動特征和名額之間的關系設計的。

圖3. 不同時段的名額波動

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. 性能異常的模型訓練效果

2、可靠性異常檢測

可靠性異常檢測是基于異常增加的錯誤數量（EC）。如圖3(b)和圖3(e)所示，EC的值大多數時候都是0，但在某些情況下，即使某些服務出現一些錯誤，但是由于對業務沒有造成影響，服務可能會在短時間内恢複正常。例如，當斷路器斷開時，服務調用失敗并引發錯誤數量上漲，但在系統負載降低和斷路器閉合後，服務将很快恢複正常。是以，我們不能使用性能異常檢測模型來檢測可靠性異常，一些二分類模型（如邏輯回歸（LR）或随機森林（RF）可以被使用。然而，由于線上隻搜集到少量的可靠性異常的案例，LR模型很可能會過拟合。

根據EC的特點，我們選擇了RF作為EC異常波動的預測模型。RF使用多個決策樹進行分類，可以有效的結合多種特征，避免過拟合。我們為模型定義了以下五種特征。請注意，有些特征結合了其它名額（例如RT、QPS），因為EC的異常增加經常與RT和QPS相關。

1. Previous Day Delta Outlier Value：計算最近一小時的Error Count值和前一天同一時間段的Error Count值的增量；使用3Sigma規則識别目前檢測視窗中可能存在的增量異常值；如果存在，則傳回異常值的平均值作為特征值，否則傳回0。
2. Previous Minute Delta Outlier Value： 計算最近一小時内Error Count值和每一個值的前一分鐘Error Count值的增量；使用3Sigma規則識别目前檢測視窗中可能存在的增量異常值；如果存在，則傳回異常值的平均值作為特征值，否則傳回0。
3. Response Time Over Threshold： 檢測視窗内的平均響應時間是否大于設定的門檻值（例如，在本文的線上系統中，門檻值設定為50ms）。
4. Maximum Error Rate：目前檢測視窗内最大錯誤率（通過Error Count和QPS計算得到）。
5. Correlation with Response Time：Response Time和Error Count在檢測時間視窗内的皮爾遜相關性值。

與性能異常檢測類似，我們把最後10分鐘作為異常檢測的時間視窗。為了訓練模型，我們同樣搜集了線上1000個打标的可靠性異常案例，其中正負比例1：3。我們也搜集了400個案例用于驗證模型的訓練效果，其中正負比例5:3。模型訓練結果如表3所示。

表3. 可靠性異常的模型訓練效果

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來評估方法根因定位的精确度。

公式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（包括兩種基線方法）的執行時間随着服務數量的增加而線性增加，表現出良好的可擴充性。

圖4. 檢測時間随服務節點數量的變化

剪枝效果（RQ3）

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

圖5. 剪枝政策的效果評估

企業實踐

MicroHECL已經實作為一個基于EagleEye和其它監控基礎設施的分布式系統在阿裡巴巴部署運作。在實際應用中，MicroHECL還支援更細粒度的故障定位，比如将中間件（資料庫，消息隊列，緩存服務）等作為定位的目标，這些元件和互動的名額資料也會被記錄到服務調用圖上。在過去的5個多月裡，MicroHECL處理了超過600個可用性問題，平均可以在76s産出定位結果，開發人員通常可以在監控系統檢測到可用性問題後5分鐘内确認并開始故障修複。來自開發人員的回報表明，大多數開發人員都比較信任系統的推薦，預設會把推薦的結果作為異常的根因。

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

總結

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

題目：MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems

作者：Dewei Liu(Fudan University) Chuan He(Fudan University)  Xin Peng(Fudan University)  Fan Lin(Alibaba Group)  Chenxi Zhang(Fudan University)  Shengfang Gong(Alibaba Group)  Ziang Li(Alibaba Group) Jiayu Ou（Alibaba Group） Zheshun Wu(Alibaba Group)。論文下載下傳位址待正式發表後公布，請持續關注，敬請期待！

點選了解更多雲效