基于微服務調用鏈雙向搜索的故障根因定位方法*

鄒丹丹，丁建兵，王希棟，葉曉舟，歐陽曄

（亞信科技（中國）有限公司 通信人工智能創新實驗室，北京 100193）

0 引言

隨著軟件體系結構的不斷優化和多樣化發展，微服務架構已經廣泛應用于通信、互聯網等各類大型企業的業務中。微服務是將軟件應用拆分所形成的多個相互協作的小服務，可極大提高開發及維護的效率。在傳統軟件系統中，使用較多的是將整個功能模塊和數據作為整體的單體架構。與之相比，微服務架構將業務按功能拆分，使其擁有較高的靈活性和容錯能力、良好的動態擴展性以及可持續的集成性[1]。與此同時，網絡云化技術的發展也推動了微服務分布式計算系統的發展，面向微服務的各類網絡云化方案逐步走上舞臺。隨著微服務技術和網絡設備云化技術的廣泛應用，應用程序中的服務數量激增且形成了負載龐大的網絡。

微服務系統具有與分布式系統相似的固有復雜性和服務依賴性。由于各級微服務間存在大量且復雜的調用依存關系，因此當某一微服務出現故障時，會帶來相應的雪崩效應，其依賴的各級服務會在短時間發出大量的告警信息，這些海量的告警信息會降低運維效率；因此，如何高效地檢測故障，實現異常檢測及根因定位成為亟待解決的問題。其中，故障是指服務無法執行其功能，而異常是指故障引發的可觀測現象。異常檢測是依據觀測到的異常現象，判斷故障類別的過程。根因定位是依托異常檢測，分析服務運行過程中可能發生的故障，定位到發生故障節點的過程。為了保障服務的安全性和可靠性，必須在微服務體系下實現高速響應的故障異常檢測和根因定位。

目前，研究人員已經提出了很多不同的方案，來解決微服務中故障的異常檢測和根因定位問題。異常檢測和根因定位主要依托于觀測到異常的時間附近所記錄的數據，這些數據包括和應用服務程序有關的關鍵性能指標（Key Performance Indicators，KPIs）、調用鏈、拓撲圖和日志等信息。按照使用數據的類別，異常檢測和根因定位可以分為基于日志、基于調用鏈和基于監測數據等不同的類別[3]。本文重點關注基于調用鏈實現的異常檢測及根因定位方案。

調用鏈是分布式系統中的重要數據，它表明了一個完整服務在分布式系統中的執行順序或流程。在分布式系統中，通常可采用無監督[4-5]、有監督[6]或跟蹤比較技術[7-8]來實現異常檢測。

根因定位可分為直接分析調用鏈和由調用鏈生成的拓撲圖驅動分析兩種方式。在直接分析調用鏈的早期，業務人員往往借助可視化工具來分析調用鏈，人工排查根因位置。人工排查的方法可以在系統中較為準確地定位根因，但是效率往往較低。后來，研究人員考慮對調用鏈中的服務響應時間進行分析來實現自動化方案[4,9]。此外，由調用鏈數據構成的拓撲圖也可以幫助實現根因分析，例如，在拓撲圖上執行隨機游走[10-12]或廣度優先搜索[13]進行探索。基于拓撲圖的方法無論是利用隨機游走還是搜索算法都存在耗時問題，而且在很多真實場景下，也會由于數據缺失等原因無法構建有效的拓撲圖，進而導致誤判，準確率無法得到保證。基于因果圖的廣度優先搜索方法[14-16]大多處于實驗階段。基于AI 的方案也是目前異常檢測和根因分析的主要研究方向，其中，基于機器學習、深度學習的方案在小樣本環境中精度高，但是在海量數據下則會相應增加較多的訓練耗時。上述各類方案距離落地仍存在一定距離。

在實際應用中，調用鏈根因定位方案通常由運維人員按照調用鏈順序自頂向下深度搜索，逐個排查故障，存在耗時較長和準確率不足等亟待解決的問題。而本文基于雙向搜索的思想，設計一種基于調用鏈雙向搜索的故障根因定位（Trace Bidirectional Search，TBS）算法。該算法先自頂向下搜索調用鏈，搜索過程中并不直接判別根因，簡化為僅統計故障節點及疑似故障節點的信息；再自底向上按層級檢索快速定位根因，其時間復雜度為常數階。所提算法已在某省級運營商實際上線，其Top 3 根因的準確率達到87%，平均定位耗時為15 s。本文算法在異常時刻前后一定時間周期內搜索相關的調用鏈，依據節點間的連接關系、節點延時和調用狀態來挖掘深層復雜的根因節點，有助于運維人員進一步解決根因定位問題。

1 微服務異常檢測及根因定位方案

微服務系統下的異常檢測及根因定位的流程如圖1 所示。

圖1 微服務異常檢測及根因定位方案流程

其中，數據庫中保存了日志、關鍵性能指標和調用鏈等各類數據。異常檢測模塊利用這些數據實時識別出當前時間段的服務是否存在故障。若判斷出存在異常，則輸出該段時間的全量調用鏈數據。調用鏈根因定位模塊則會對調用鏈數據依次進行清洗與預處理，自頂向下搜索異常節點和疑似異常節點，自底向上計算根因概率并在最后輸出概率排序最大的Top 3 根因節點。運維人員可以依據輸出的結果快速定位并修復相關節點，極大地提升了運維工作效率，保障了微服務的運行穩定。

本文重點關注根因定位模塊，對異常檢測模塊則采用了通用方法。目前已有大量成熟的異常檢測方案可以實時對這些數據進行故障檢測。為了達到滿足用戶需求的服務等級目標（Service Level Objective，SLO），通常利用服務水平指標（Service Level Indicator，SLI）來對應滿足設定的SLO。SLI表示業務服務質量的具體黃金指標，例如網絡延時、吞吐量等。在微服務場景下，數據庫中保存了大量歷史業務核心指標，利用這些歷史數據，可以使用通用的異常檢測方案[4-8]實現關鍵性能指標的異常檢測。本文方案通過對時延和成功率這兩種黃金指標的閾值判定，實現指標異常檢測。當時延高于閾值或成功率低于閾值的調用鏈比例達到設定的異常閾值時，判定該時刻為異常并觸發根因定位模塊。在閾值設定方面，考慮到隨著時間的增長業務的時延范圍存在漂移現象，即業務的平均時延會增加，以及業務人員也希望能夠通過閾值來控制報告異常的數量，因此采用人工可調的方式設定時延和成功率的判定閾值。

2 微服務調用鏈節點根因定位

當異常檢測模塊的輸出結果是某時刻存在異常時，則在該時刻前后的時間周期T內可能存在不止一條異常調用鏈。在微服務下存在大量錯綜復雜的服務調用關系，而生成的調用鏈是單向傳播的，調用鏈上層節點的故障異常往往受底層節點的故障影響。調用鏈節點根因定位算法的目的是，已知某一時刻系統服務存在異常，在該時刻前后時間長度為T的時間段內，根據調用鏈數據，查找到底層的故障發生位置，輸出這些調用鏈所使用過的微服務節點中最有可能發生故障的前K個根因節點，即定位到根本原因。

在實際業務中，評估根因定位模塊輸出的根因有準確率和召回率兩種指標。由于這兩種指標是互相制約的關系，因此需要權衡側重點。較大的召回率意味著根因定位模塊會反饋較多的根因，這會使業務人員疲于檢查，嚴重降低運維效率。此外，當某一底層微服務所在節點位置發生故障時，有可能導致告警風暴，即大量的告警和異常在同一時間爆發。考慮到更高的召回率會給服務器計算帶來極大的壓力，因此相比召回率，本文更加重視準確率，使算法輸出較為準確的結果。

2.1 數據清洗與預處理

在微服務系統中，業務調用的各個節點都會保存相關信息至日志中，將所有數據連接成鏈式結構就形成了一條調用鏈。每條調用鏈都擁有唯一的調用鏈序號TraceID。通常，調用鏈的方向都是自起點開始單向傳播的。調用鏈從頭節點起，會逐層調用不同節點，定義這里的層級為調用的深度。

在本文方案所應用的業務場景中，核心指標為節點延時和調用狀態是否異常。節點延時是指該節點運行相應服務的耗時，調用狀態表示該節點執行相應服務是否成功。

調用鏈數據預處理主要分為調用鏈抽取和數據處理兩個階段，具體如下文所示。

（1）調用鏈抽取：由于每條調用鏈都有唯一的TraceID，根據調用鏈TraceID 將屬于同一條鏈的所有數據抽取出來，再基于節點ID 和父節點PID構建父子關系進行拼接，將其串聯為一條完整的調用鏈。

（2）數據處理：預先計算并保留算法中需要用到的結果，以提升算法效率，例如，當前節點后續所有子節點實耗時間（ElapsedTime）的總和、子節點個數、子節點調用成功數等，如表1 所示。

表1 調用鏈數據

2.2 調用鏈搜索和定位算法

某一條調用鏈的調用邏輯如圖2 所示。調用鏈中不同的節點屬于不同的服務類型。頭節點依次向下調用其他子服務，或者調用自己本身，呈現單向的調用方式。各個節點數據包含了各自的延時數據和是否調用成功的信息。

圖2 微服務完整調用鏈樣例

定位算法流程如圖3 所示，可分為自頂向下調用鏈搜索和自底向上調用鏈定位兩部分。

圖3 調用鏈搜索和定位算法流程

2.2.1 自頂向下調用鏈搜索算法

本節的目的是以服務節點為對象，計算并統計算法認定該節點為異常節點和疑似異常節點的次數。采用遞歸算法，從調用鏈的頭節點往后逐步判斷，若判定為異常節點則繼續向后搜索，否則停止后續搜索。

算法通過以下4 個方面判斷該節點是否為異常節點：

（1）當前節點存在延時異常。通常認為節點的延時是正態分布的，因此采用3-sigma 準則，將當前延時大于平均值3 個標準差的節點定義為異常節點。

（2）當前節點調用狀態失敗。每個節點都有二值的調用狀態，可依據該字段判斷節點是否調用成功。

（3）當前節點后續子節點存在調用失敗情況。若后續節點異常，則必然會影響到當前節點。因此，當子節點的個數大于子節點調用成功數時，則認定當前節點為調用異常節點。

（4）當父節點異常時，當前節點延時tc占用父節點延時tp的一半及以上（只適用于非頭節點的判斷），具體如式（1）所示。在正常運行時，同一層級的節點往往在耗時上較為均衡，因此當前節點占用率過大即是異常節點。

然而，除了上述異常情況，在正常節點中存在這樣一種情況：當網絡出現較大波動時，當前節點傳輸到父節點的耗時會增大，這部分耗時會累加為父節點耗時的一部分。這些節點本身也有可能是異常的，但是并未在上述4 類異常定義中體現。為此，本文將這些正常節點定義為疑似異常節點。節點延時包含了自身耗時和后續調用的子節點耗時總和∑tc。若當前節點判斷為正常節點，但是該節點的父節點自身耗時tp-∑tc占用了自身延時tp的一半及以上（只適用于非頭節點的判斷），則記錄為疑似異常節點，與正常節點相同，也停止往后搜索，具體為：

自頂向下調用鏈搜索算法的偽代碼如下：

至此，異常檢測算法可以統計出在時間段T內，多條調用鏈所調用的服務節點的正常次數、異常次數和疑似異常次數。異常和疑似異常本質上兩者均為異常。基于上述搜索結果，各個節點異常率的計算式為：

式中：nnormal為正常節點個數；nsuspected為疑似異常節點個數；nabnormal為異常節點個數。與傳統順序搜索并判斷根因的方案相比，該部分方案更加簡潔，僅做統計而省略了逐個判斷根因的過程。

2.2.2 自底向上調用鏈定位算法

由于調用鏈底層節點為根因的概率更大，因此，采用自底層向上層搜索根因節點的方式更易于定位根因。從底層開始篩選，若存在異常則直接在該層定位。根因定位所依賴的評價標準主要是上一步驟中得到的故障次數和異常率，而單獨采用故障次數或異常率都會嚴重影響定位精度。因此，判定依據應采用故障次數和異常率相結合的方式。

然而，若調用次數較少（調用一次且故障率為100%）或異常率較低（調用大量次數且有偶發性故障），該層的節點并不一定為根因。圖4 表明了一個5 層的調用鏈中各層的調用次數分布情況，從上至下調用數量分別為721，6724，23716，6643，632，該結果近似于正態分布。在調用鏈的高層和底層都存在調用次數少的問題。因此需要設置閾值，對調用鏈數據進行篩選。

圖4 調用次數分布

判定順序如下：

（1）人為設定故障次數和異常率的閾值，篩選去除故障次數低于閾值和異常率低于閾值的數據；

（2）對當前層進行搜索，若該層存在單個異常節點，或者疑似異常節點，則直接作為根因節點；

（3）若存在多個異常節點，返回故障次數較多的節點作為根因；

（4）若存在多個異常節點且故障次數相同，則返回異常率較高的節點。

自底向上調用鏈定位算法的偽代碼如下：

由于搜索的根因絕大多數在底層，在Depth 循環中的前幾次判定就會返回，絕大多數在第1 次判定就直接返回結果。該部分的定位算法并未遍歷所有Depth，因此算法速度極快，時間復雜度為常數階。

3 效果評估

本文對某省級運營商自2021 年6 月份至10月份的微服務數據進行分析，獲取的數據量為 382 674 條。檢測區間為異常時刻前后各5 min（共計時間長度為10 min）的時間段。采用本文算法進行預測，輸出TopK的異常故障根因，并反饋給運維人員進行人工審核，判斷根因是否為真實故障節點并統計準確率。

圖5 表明了Top 3 準確率隨故障次數閾值的變化，其中橫坐標為故障次數閾值，從0 至100，間隔為10。圖中曲線表明，隨著閾值從0 增加至30，樣本中具有隨機性的小樣本根因節點被剔除，準確率有所上升。但是隨著閾值的繼續增大，真實的根因節點也會逐步被剔除，因此準確率會迅速下降。圖6 表明了Top 3 準確率隨異常率閾值的變化。當異常率閾值在0.05～0.15 之間時，隨著異常率閾值的提升，準確率不斷提升。這表明根因節點在底層，且異常率的提升過濾掉了一些干擾根因。但隨著異常率提升到0.2～0.4，準確率出現了明顯的下降，這是由于隨著異常率的提升，靠近底層的根因節點逐漸被錯誤過濾。

圖5 Top 3 準確率隨故障次數閾值的變化

圖6 Top 3 準確率隨異常率閾值的變化

對于選取的前K個結果，本文也進行了討論。表2 為在設定不同異常次數閾值和異常率閾值的情況下，選取不同數量的根因的準確率。結果表明，一方面，在異常次數和異常率的閾值設置為10 和0.15 時，在本數據集下效果最佳；另一方面，隨著選取的可能根因從Top 1 增加到Top 3，更大概率能命中相應的根因節點，根因的準確率有所提高。

表2 不同異常次數閾值和異常率閾值下的Top K 準確率

表3 為某省客戶管理系統（Customer Relation-ship Management，CRM）運營效果數據。其中，服務異常次數為異常檢測所檢測出的異常時刻的次數，平均定位耗時為執行一次算法程序所需的耗時。在算法效率優化方面，本文將串行搜索修改為多進程并行的方式。此外，還使用了更高效率的存儲結構來進行加速，極大提升了算法的運行效率。在提升準確率方面，結合實際運營效果進行閾值的調節，根據服務和閾值間的敏感性，來對應調整不同服務的閾值，以達到更好的定位效果。

表3 某省客戶管理系統運營效果數據

業務基準需求是準確率需達到0.7 以上并盡可能壓縮平均定位耗時。如表3 所示，2021 年6 月準確率未達到要求，平均定位耗時為3 min。經過5 個月的實際業務上線測試，并結合業務優化調節閾值至更合理的值，在2021 年10 月的數據集上，Top 3 準確率達到了0.87。程序修改為多進程，最終平均定位耗時壓縮到了15 s，準確率相較于首月提升了29.85%，耗時也從分鐘級提升至秒級。綜上，本文所提算法在調用鏈根因定位場景下，可以較為準確地定位根因，且在經過優化后，已能較好地滿足業務需求。

4 結語

本文提出了一種基于調用鏈雙向搜索的故障根因定位算法。基于微服務系統中故障時刻前后一定時間內的調用鏈數據，本文算法采用雙向搜索的思路實現了對異常根因節點的深度挖掘及精準定位。所提算法已在國內某省級運營商項目中上線，Top 3根因的準確率達到了0.87，平均定位耗時為15 s。為了更好地滿足運維工作人員的需求，上線版本對調用鏈搜索的統計結果進行了可視化。此外，所提算法雖然設計應用于微服務場景，但是也具備拓展到其他具有調用鏈故障定位場景的潛力。本文為微服務系統下的故障根因定位問題提供了更加快速有效的解決方案，也為智能運維領域拓展了新的研究思路。