云效故障定位研究论文被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的大型監控基礎設施。作為業務的載體，系統需要保證高可用。因此這些系統都部署了一個業務監控平臺來及時的發出可用性問題報警。這些可用性問題通常表示業務運行中的問題，例如下單成功量下跌、交易成功率下跌等。這些可用性問題可能是由不同類型的異常引起的，異?？赡軓囊粋€服務傳播到另一個服務，最終導致可用性問題。在本文中，我們重點關注以下三種導致阿里巴巴大部分可用性問題的異常類型：
相關研究
現有的方法不能有效的支持大規模微服務系統可用性問題根因定位，業界開發人員通常還需要依賴可視化工具來分析日志和鏈路，以識別可能的異常和異常傳播鏈路，從而找到根本原因。研究人員已經提出了使用鏈路分析或服務依賴圖的方法來自動定位微服務或更廣泛的基于服務的系統的異常根因?；阪溌贩治龅姆椒ㄐ枰嘿F的鏈路數據收集和處理，因此不能有效的用于大規模系統。基于服務依賴圖的方法是基于服務調用或因果關系來構造服務依賴圖。這些方法通過遍歷服務依賴圖并用服務的指標數據（如響應時間）檢測可能的異常來定位根因，然而這些方法由于對服務異常檢測的不準確以及對服務依賴圖的低效遍歷而使用受限，尤其是在有很多服務和依賴關系的大規模微服務系統中。
方法概述
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種特征：
我們把最后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相關。
與性能異常檢測類似，我們把最后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的有效性和效率，我們進行了一系列的實驗研究來回答下面三個研究問題：
實驗設置
從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相對于兩種基線方法平均時間差的變化?？梢钥闯?#xff0c;當服務數量小于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產出定位結果，開發人員通?？梢栽诒O控系統檢測到可用性問題后5分鐘內確認并開始故障修復。來自開發人員的反饋表明，大多數開發人員都比較信任系統的推薦，默認會把推薦的結果作為異常的根因。
在實際應用中，除了一些系統因指標數據缺失導致無法準確定位之外，我們還分析了MicroHECL不能準確定位其它異常根因的案例，發現MicroHECL仍需要從多方面進行改進。例如，一些可用性異常被檢測到后，它的服務質量指標可能沒有任何異常。而且有一些異?？赡苁锹e累起來的，它的指標波動可能超過了異常監測的時間窗口。這些需要更先進的技術來改進目前的方法。
總結
本文針對微服務系統的可用性問題，提出了一種高效的根因定位方法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)。論文下載地址待正式發表后公布，請持續關注，敬請期待！
點擊了解更多云效
原文鏈接：https://developer.aliyun.com/article/781634?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的云效故障定位研究论文被ICSE 2021 SEIP track收录的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 边缘计算在天猫精灵云应用上的落地实践
- 下一篇： 滴滴 Flink-1.10 升级之路