李思毅，馬詩雨，崔麗月，張圣林，孫永謙，張玉志

南開大學，軟件學院，天津 300350

引 言

在移動互聯(lián)網(wǎng)背景下，互聯(lián)網(wǎng)等行業(yè)業(yè)務更新迭代速度加快，需求研發(fā)周期大大縮短，線上應用變更十分頻繁。與此同時，新冠疫情加速了傳統(tǒng)行業(yè)線上化和數(shù)字化轉型，超大規(guī)模云平臺作為關鍵基礎設施，為我國經(jīng)濟轉型升級提供了重要支撐，已廣泛應用于電信、互聯(lián)網(wǎng)、金融、政府、電力等多個行業(yè)，但這些行業(yè)線上業(yè)務體量龐大、監(jiān)管嚴格、對異常容忍度極低[1]。隨著互聯(lián)網(wǎng)技術的發(fā)展和各行業(yè)業(yè)務的多元化需求，將會有越來越多的傳統(tǒng)行業(yè)在數(shù)字化轉型和上云過程中采用云原生架構[2]，將原本的單體應用拆分成數(shù)百個微服務[3]應用，每個微服務應用部署到上千個容器實例上。一個微服務應用可以同時為多個業(yè)務鏈路提供服務，因此微服務應用之間存在復雜的調用關系。當一個微服務應用出現(xiàn)異常時，它將影響調用鏈路下游的多個微服務應用，最終影響整個業(yè)務鏈路的成功率。例如，對于金融行業(yè)實現(xiàn)合約簽訂、信用審核等微服務應用會被其他應用高頻次調用。當這類微服務應用出現(xiàn)異常時，異常會擴散至多個微服務應用，形成告警風暴，單純依賴人工故障定位很難滿足電信、互聯(lián)網(wǎng)、金融、政府、電力等行業(yè)對于系統(tǒng)穩(wěn)定性的要求，而對于這些行業(yè)來說，極短時間的故障也會產生巨大資損，給國家造成重大損失。因此，依賴費時費力、無法擴展的人工方式故障應急是不可行的。

鑒于此，本文總結了面向微服務架構的根因定位方法，探索在微服務架構下系統(tǒng)發(fā)生異常后自動、準確地定位引起異常的根因事件或異常組件，縮短異常修復時間，提高云上系統(tǒng)穩(wěn)定性。

1 研究背景及意義

1.1 微服務架構

微服務指將大型的單體軟件應用拆分成多個簡單應用，每個簡單應用描述一個細分業(yè)務或功能，系統(tǒng)中各個簡單應用可被獨立部署，且各個應用之間松耦合以實現(xiàn)系統(tǒng)的持續(xù)快速交付和運維[4]。微服務架構與傳統(tǒng)的單體架構相比，旨在通過將功能分解到各個離散的服務中，實現(xiàn)單個系統(tǒng)復雜度和耦合性降低，通過系統(tǒng)之間的輕量級通信機制實現(xiàn)相互協(xié)作，具有更細粒度的獨立部署、獨立擴展、跨語言編程等特點。微服務架構在帶來靈活性、開發(fā)敏捷性的同時也帶來了運維層面的挑戰(zhàn)，隨著應用服務數(shù)量的增加，微服務之間的通信、部署依賴、數(shù)據(jù)一致性、監(jiān)控以及安全性的管理成為新的挑戰(zhàn)。

云原生技術是基于微服務架構思想、以容器技術為載體的一種產品研發(fā)運營的全新模式。云原生技術是各行業(yè)在公有云、私有云或混合云中構建和運行可彈性擴展的應用的核心技術。云原生的代表技術包括服務網(wǎng)格（Service Mesh）[5]、基于Kubernetes[6]的容器技術、微服務、不可變基礎設施和聲明式API。

綜上，基于微服務架構的云原生系統(tǒng)將是未來一段時間各行業(yè)數(shù)字化轉型過程中技術上主要的發(fā)展趨勢。

1.2 微服務架構的運維

1.2.1 監(jiān)控指標

監(jiān)控中臺是微服務架構下的核心系統(tǒng)之一，面向微服務場景下的全功能監(jiān)控中臺包含關鍵業(yè)務鏈路監(jiān)控、應用監(jiān)控、基礎設施監(jiān)控和自定義監(jiān)控等功能，為系統(tǒng)監(jiān)控報警以及后續(xù)運維操作提供基礎。監(jiān)控中臺關注的主要包含如下指標：

（1）業(yè)務指標：包括關鍵業(yè)務鏈路的成功率、失敗數(shù)、平均耗時等描述業(yè)務穩(wěn)定性的指標。

（2）系統(tǒng)指標：包括POD 容器、應用容器、Sidecar 容器等多個維度的指標，主要有：CPU、LOAD（負載）、MEM（內存）、下游請求信息、上游請求信息、磁盤水位等。

監(jiān)控中臺在整合監(jiān)控數(shù)據(jù)的基礎上，同時集成了監(jiān)控指標的異常檢測能力，并通過異常事件中心等功能展示給運維工程師。

圖1 某金融系統(tǒng)交易成功量（業(yè)務指標）Fig.1 The number of successful transactions in the financial system (business indicator)

圖2 云平臺中某物理機CPU 使用量（系統(tǒng)指標）Fig.2 CPU usage of a physical machine in the cloud platform (system metrics)

1.2.2 CMDB

CMDB[7]的全稱是configuration management database(配置管理數(shù)據(jù)庫)。CMDB 是云上所有核心硬件、軟件及其關聯(lián)關系的邏輯體現(xiàn)。如圖3所示，CMDB 保存了機房、機柜、網(wǎng)絡位置、網(wǎng)絡設備、服務器、應用、應用分組、云資源實例等實體的物理拓撲和云上拓撲關系。CMDB 保存的運維元數(shù)據(jù)是異常處理的關鍵依據(jù)。

圖3 CMDB 中的實時拓撲關系Fig.3 Real-time topological relationships in CMDB

1.3 研究意義

當異常發(fā)生時，監(jiān)控中臺會根據(jù)已有的異常告警原則產生大量告警信息，短時間內產生的數(shù)量龐大的告警（告警風暴）給運維工程師異常處理帶來了極大的挑戰(zhàn)，在龐大的業(yè)務系統(tǒng)和海量的告警信息中迅速發(fā)現(xiàn)告警風暴背后的異常關聯(lián)關系并鎖定根因的難度非常大。本文調研了智能運維領域關于根因定位方法的相關文獻，對微服務架構下基于圖推理的根因定位方法進行總結，為大規(guī)模云平臺的智能根因定位系統(tǒng)建設提供參考。

2 根因定位系統(tǒng)框架

在大規(guī)模云平臺中，智能告警系統(tǒng)通過時間序列異常檢測算法結合人工設置的指標異常檢測規(guī)則實時監(jiān)測系統(tǒng)狀態(tài)，力求在最短時間內發(fā)現(xiàn)指標的異常情況。當系統(tǒng)發(fā)生異常，由于大型的網(wǎng)絡、云平臺內部設備眾多，關聯(lián)關系復雜，清晰的調用關系、設備與鏈接的相互連接關系是根因定位的重要基礎。除了CMDB 提供的網(wǎng)絡設備的物理拓撲之外，還存在指標間、協(xié)議間的關聯(lián)關系。上述關聯(lián)關系對異常的排查、止損與溯源起著至關重要的作用。根因定位系統(tǒng)在異常發(fā)生后基于相關運維元數(shù)據(jù)分析結合智能運維算法確定引發(fā)異常的根本原因。具體來講，根因定位系統(tǒng)主要分為兩個部分：系統(tǒng)首先通過關系學習方法構建異常指標、異常組件或異常事件之間的故障傳播圖，該圖描述了異常發(fā)生時刻設備實體及其關鍵指標、告警狀態(tài)間的關聯(lián)關系或依賴關系。之后，根因定位系統(tǒng)通過圖推理算法可以得出圖中節(jié)點的根因可能性排名，取Top N 作為推薦根因輸出。

3 根因定位方法綜述

本章介紹微服務架構下用于構建故障傳播圖的關系學習方法和對故障傳播圖進行節(jié)點重要性排序實現(xiàn)推薦異常根因的相關算法。

3.1 關系學習方法

當微服務架構下的線上系統(tǒng)發(fā)生異常，由于大型的網(wǎng)絡、云平臺內部設備眾多，關聯(lián)關系復雜，清晰的調用關系、設備與鏈接的相互連接關系是根因定位的重要基礎。除了網(wǎng)絡設備的物理拓撲之外，還存在不同的指標、協(xié)議等關聯(lián)關系。上述這些關聯(lián)關系都對異常的排查、止損與溯源起著至關重要的作用。根據(jù)異常時段的關聯(lián)關系構成的有向無環(huán)圖（Directed Acyclic Graph,DAG）即為故障傳播圖。在故障傳播圖中，異常會沿著模塊和設備間的依賴關系傳播，導致更大范圍的模塊和設備的異常。

圖4 微服務根因定位框架Fig.4 Root cause localization framework

由于實際生產環(huán)境多種多樣，不同系統(tǒng)架構下構建出的故障傳播圖也各不相同。故障傳播圖按節(jié)點類型主要分為三類：以異常指標為節(jié)點的故障傳播圖、以異常組件為節(jié)點的故障傳播圖和以異常事件為節(jié)點的故障傳播圖。相同屬性的節(jié)點多依賴算法挖掘和程序調用分析，不同屬性的節(jié)點多依賴CMDB 提供的拓撲關系，綜上，可以構建出描述異常發(fā)生時段內系統(tǒng)的故障傳播圖。

目前，已有的相關工作通過一些關系學習方法來構建故障傳播圖。關系學習方法主要有三種：系統(tǒng)信息構建、算法自動學習和兩者相結合。這一節(jié)將分別介紹三種關系學習方法。

3.1.1 系統(tǒng)信息

基于系統(tǒng)信息構建的故障傳播圖如圖5所示，根據(jù)系統(tǒng)設備、模塊之間明確的的部署、依賴、調用關系等系統(tǒng)信息可以直接構建故障傳播圖，其中節(jié)點為異常性能指標對應的系統(tǒng)設備、模塊，邊為上述節(jié)點之間的部署、依賴、調用關系。這里的系統(tǒng)信息主要包括靜態(tài)的物理設備之間的部署關系（通過CMDB 獲?。┮约皠討B(tài)的實時系統(tǒng)模塊之間的調用關系。通過配置數(shù)據(jù)采集模塊、日志分析工具、程序調用分析工具等手段獲取系統(tǒng)模塊之間的實時調用信息。

圖5 以異常組件為節(jié)點的故障傳播圖示例Fig.5 A example of a fault propagation graph with anomalous components as nodes

根據(jù)系統(tǒng)信息可以直接構建故障傳播圖，但在實際的生產環(huán)境中，收集額外的系統(tǒng)數(shù)據(jù)需要更改線上Web 服務的架構。由于更改線上系統(tǒng)架構十分困難，所以基于系統(tǒng)信息的構圖方法難以應用。

3.1.2 算法自動學習

采用算法自動學習的方法構建故障傳播圖的原理是通過對監(jiān)控指標數(shù)據(jù)的學習，按需提取監(jiān)控指標之間的依賴關系，以確定故障傳播圖中的異常節(jié)點及其關聯(lián)關系。其中，節(jié)點為監(jiān)控指標，邊為挖掘出的指標之間的依賴關系。

目前相關工作中最常用的思路為通過PC 算法[8]自動構建監(jiān)控指標之間的依賴關系來構建故障傳播圖。PC 算法主要分為兩步。首先，通過檢驗條件獨立性確定節(jié)點間的依賴關系，生成一個無向圖以構建骨架（skeleton）。PC 算法把上述過程轉化為d 分隔（d-separation）問題，采用了Fisher Z Test 作為條件獨立性檢驗方法對任意兩個節(jié)點進行條件獨立性檢驗以判斷d 分隔。然后，利用d 分隔的原理來確定圖中邊的依賴方向，把無向圖擴展為有向無環(huán)圖[8]。

除PC 算法之外，也可以通過相關性分析方法挖掘監(jiān)控指標數(shù)據(jù)之間的依賴關系從而構建故障傳播圖。然而，在生產環(huán)境中可能存在一些難以觀察和推導的隱變量，監(jiān)控指標數(shù)據(jù)和告警信息也可能存在誤報、漏報以及缺損，導致通過算法自動學習到的故障傳播圖準確度有限。

3.1.3 兩者結合

為了構建更完整、更準確的故障傳播圖，也有一些相關工作將系統(tǒng)信息和自動學習方法結合使用。

首先結合系統(tǒng)架構的物理拓撲關系和系統(tǒng)模塊之間的實時調用關系等系統(tǒng)信息構造系統(tǒng)模塊之間的故障傳播圖，通過PC 算法或者相關性分析方法挖掘單個系統(tǒng)模塊節(jié)點上不同監(jiān)控指標之間的因果關系，最后通過結合構造的系統(tǒng)模塊之間的故障傳播圖和單個系統(tǒng)模塊節(jié)點上的監(jiān)控指標之間的因果圖得到一個完整的全局故障傳播圖。

3.2 根因定位方法

3.1 中的故障傳播圖描述了系統(tǒng)異常時刻關鍵異常節(jié)點的關聯(lián)關系，依據(jù)故障傳播圖提供的節(jié)點類型、異常指標、拓撲關系等信息，對圖中節(jié)點進行重要性排序，排序結果可以作為本次異常事件的根因推薦，本章節(jié)將對相關算法進行介紹。

3.2.1 深度優(yōu)先搜索

深度優(yōu)先搜索算法[9]（Depth-First-Search，簡稱DFS）是一種用于遍歷或搜索樹或圖的算法。DFS會盡可能深地搜索樹的分支。當節(jié)點的所在邊都已被探尋過，搜索將回溯到發(fā)現(xiàn)節(jié)點的那條邊的起始節(jié)點。這一過程一直進行到已發(fā)現(xiàn)從源節(jié)點可達的所有節(jié)點為止。在根因定位領域，根據(jù)上述關系學習方法獲取的故障傳播圖表示了異常的傳播過程，因此對其進行深度優(yōu)先搜索是獲得此次異常根因的方法之一。

3.2.2 皮爾森相關系數(shù)

在統(tǒng)計學中，皮爾森相關系數(shù)[10]（Pearson correlation coefficient）用于度量兩個變量和之間的相關程度（線性相關）。兩個變量之間的皮爾森相關系數(shù)定義為兩個變量的協(xié)方差除以它們標準差的乘積，其值介于-1 與1 之間。

由于各種監(jiān)控都是以時間序列的形式存在，因此對于兩個異常的系統(tǒng)組件，可以分別選取其異常發(fā)生及前一段時間的監(jiān)控指標，計算兩個時間序列的皮爾森相關系數(shù)，表示異常組件的異常關聯(lián)強度。

3.2.3 PageRank 算法

PageRank 算法[11]是Google 公司所使用的對其搜索引擎搜索結果中的網(wǎng)頁進行排名的一種算法。其本質是一種以節(jié)點之間的連接個數(shù)和權值作為主要因素粗略地分析故障傳播圖中節(jié)點重要性的算法。

對于故障傳播圖中某個節(jié)點pi，其PageRank 值的計算公式如下：

一般情況下，云原生場景下的故障傳播圖是有向無環(huán)圖，因此對于已知的故障傳播圖可以通過PageRank 算法計算圖中節(jié)點的重要程度。有向無環(huán)圖中節(jié)點的重要性排名也可以作為各節(jié)點對該異常的影響排名。

3.2.4 隨機游走算法

隨機游走[12]（Random Walk，縮寫為 RW）是一種數(shù)學統(tǒng)計模型，它由一連串的軌跡所組成。在原生隨機游走算法中，每一次游走的方向都是隨機的?？梢越梃b其原理，設計故障傳播圖的游走策略并生成概率轉移矩陣。每一次游走因子從當前節(jié)點向更有可能是異常根因的節(jié)點轉移或繼續(xù)留在當前節(jié)點，重復此步驟上萬次，并記錄游走軌跡?；诠收蟼鞑D中每個節(jié)點被訪問的次數(shù)對節(jié)點進行排序，結果可作為各節(jié)點對異常的貢獻度排名，從而確定異常根因。隨機游走算法分為一階隨機游走和二階隨機游走。一階隨機游走是指假設下一個要訪問的節(jié)點只依賴于當前節(jié)點（馬爾科夫性），其缺點是無法捕獲高階依賴關系。一階隨機游走根據(jù)最后一個頂點的狀態(tài)選擇下一個頂點，它的轉移概率的計算方式為：

二階隨機游走在訪問下一個節(jié)點時依賴于當前節(jié)點和當前節(jié)點的前一個節(jié)點。因此，二階隨機游走建立了高階依賴關系，提高了應用的精度。二階隨機游走是根據(jù)最后兩個頂點和的狀態(tài)選擇下一個頂點，轉移概率是

4 根因定位方法應用

本章節(jié)介紹上述關系學習方法和基于圖推理的根因分析方法的實踐。

MonitorRank[13]首先通過收集微服務應用上配置的傳感器記錄微服務之間的調用關系，然后根據(jù)異常時間段的調用關系來構建故障傳播圖。其基本思想是：故障傳播圖的指標m和異常前端節(jié)點（負責接收用戶的請求以及進一步調用下游請求以完成用戶的請求的微服務）的指標的相關性表示了該節(jié)點是根因的可能性。為避免非根因節(jié)點和異常前端節(jié)點的指標有較高的相關性，需要分別考慮指標之間的相關性和服務節(jié)點之間的依賴關系。概率轉移矩陣的設計是隨機游走算法的關鍵，MonitorRank主要使用故障傳播圖中不同節(jié)點監(jiān)控指標的相關性來生成轉移概率。向量定義了每個節(jié)點和異常前端節(jié)點指標的相關性因此概率轉移矩陣可以定義為在實際情況中，每個微服務節(jié)點的異常根因并非一定由其下游調用節(jié)點導致，也可能是其自身節(jié)點或上游節(jié)點導致。綜上，MonitorRank 給出的轉移概率為：

因此完整的概率轉移矩陣的定義為：

MicroRCA[14]在構建故障傳播圖時同樣依賴微服務應用間的調用關系。與MonitorRank 不同的是，MicroRCA 同時會考慮微服務應用在宿主機上的部署關系。因為在實際的運維異常處理場景中，當一臺物理機宕機，的確會影響到該異常物理機上部署的全部微服務應用。MicroRCA 同樣基于皮爾森相關系數(shù)計算不同節(jié)點之間的相關性，用作Personalized PageRank 算法[15]中的權值來推斷異常根因。

與上述工作相似，TON18[16]通過OpenStack 開源云計算管理平臺中的系統(tǒng)接口和PreciseTracer 程序調用分析工具構建模塊之間的故障傳播圖，然后通過隨機游走算法分析故障傳播圖實現(xiàn)根因定位。

MicroHECL[17]基于監(jiān)控中臺的服務調用關系和指標動態(tài)構建一定時間窗口內的目標微服務系統(tǒng)的故障傳播圖。故障傳播圖上除了表示各個服務節(jié)點之間的調用關系外，還記錄了各種度量指標，例如響應時間（RT）、錯誤數(shù)量（EC）和每秒請求數(shù)（QPS）等信息。由于根因服務和初始異常服務通常都處于由一系列的異常服務組成的異常傳播鏈上，MicroHECL 分析了所有可能的異常傳播鏈路，并采用了剪枝策略來消除不相關的服務調用，從而得到候選異常根因服務集合。MicroHECL 認為初始異常服務的異常指標數(shù)據(jù)與根因服務的異常指標有相似的變化趨勢，因此使用皮爾森相關性系數(shù)進行相關性分析，基于相關性值對候選異常根因服務進行排序。

表1 基于圖推理的根因定位方法實踐Table 1 Practice of abnormal diagnosis method based on graph reasoning

Groot[18]首先從初始告警或者可疑服務開始通過分布式執(zhí)行軌跡和日志分析維護一個全局服務依賴圖G，服務依賴圖中的有向邊表示服務調用或其他形式的依賴。然后Groot 將G中的每個服務對應的異常情況映射成異常事件，總結了該系統(tǒng)中的各種類型的指標、日志的異常行為。結合SRE 的領域知識構建事件之間的因果關系，形成基于事件的實時因果關系圖。Groot 提出了改進的PageRank 算法GrootRank，使每條邊都與加權傳播的加權分數(shù)相關聯(lián)，對于誤報率高的警報，算法將其設置得較低。此外，由于葉子節(jié)點更可能是根本原因，GrootRank算法將個性化向量定制葉子節(jié)點和其余節(jié)點的分數(shù)，以增強葉子節(jié)點之間的傳播。Groot 基于事件類型構建因果關系圖有兩個顯著的優(yōu)點：

（1）使用監(jiān)控事件作為基本節(jié)點對比使用服務節(jié)點能夠獲得更準確的結果；

（2）因果關系圖支持各種事件類型，例如性能指標、狀態(tài)日志和系統(tǒng)變更等，并且允許SRE 和開發(fā)人員引入不同的異常事件類型，使得Groot 更加靈活，并支持更廣泛的事件類型。

CloudRanger[19]提出了一種動態(tài)因果關系分析方法，能夠在缺乏拓撲的情況下構建故障傳播圖，基于二階隨機游走的啟發(fā)式搜索算法來識別根因服務。CloudRanger 首先基于PC 算法自動構建監(jiān)控指標之間的故障傳播圖。之后，CloudRanger 利用二階隨機游走算法來識別根因服務。利用皮爾森相關性系數(shù)定義相關性特征以描述指標序列之間的相關性。給定一個服務集，以及對于任何一對服務定義指標數(shù)據(jù)矩陣，相關性，對與的相關性定義如下：

此外，CloudRanger 設置了兩種額外的轉換類型，即后向和自向，使算法能夠找到更多的路線并使其隨機游走更具啟發(fā)性。假設表示已經(jīng)被訪問過的節(jié)點，是從當前服務到它的鄰居的后向轉移概率，受后向常數(shù)限制，后向轉移概率計算如下：

給定故障傳播圖，CloudRanger 根據(jù)以上公式計算前向、后向、自我轉移概率隨機游走，記錄每個服務節(jié)點的訪問次數(shù)并將其降序排序輸出為根因識別結果。

與CloudRanger 相似的是，MSRank[20]、Service-Rank[21]也通過自動構建監(jiān)控指標之間的故障傳播圖去定位根因。它們首先利用PC 算法構造有向無環(huán)圖表示監(jiān)控指標間的依賴關系，然后使用不同的算法遍歷生成的故障傳播圖實現(xiàn)根因定位。其中，MSRank 使用了二階隨機游走算法去定位根因，ServiceRank 使用皮爾森相關系數(shù)進行相關性分析以實現(xiàn)根因定位。

MicroCause[22]在上述工作的基礎上提出一些改進。在PC 算法的基礎上提出PCTS(Path Condition Time Series)算法構建監(jiān)控指標間的依賴關系，使用TCORW(Temporal Cause Oriented Random Walk)算法去定位根因。當關鍵性能指標(Key Performance Indicator，簡稱KPI) 中檢測到在線異常 時，MicroCause 將被激活。發(fā)生異常微服務在異常前數(shù)小時的監(jiān)控指標數(shù)據(jù)將用作MicroCause 的輸入。MicroCause 利用PCTS 算法用于生成該異常的故障傳播圖。使用改進的PC 算法用于學習時間序列的因果圖。PCTS 算法假設，如果時間序列A 和時間序列B 在某個時間點中存在因果關系，那么在故障傳播圖中A 代表節(jié)點和B 代表節(jié)點間就會存在一條邊。因此，因果關系最終會被合并轉化為故障傳播圖。與此同時，異常檢測模塊檢測輸入數(shù)據(jù)集是否存在異常。故障傳播圖學習模塊和異常檢測模塊可以并行處理。MicroCause 還設計了面向時間因果的隨機游走（TCORW）。MicroCause 利用偏相關系數(shù)（Partial Correlation)來計算轉移概率矩陣。與Pearson 相關性不同的是，和異常KPI 因果性更強的系統(tǒng)指標將具有更高的偏相關系數(shù)，而皮爾森相關性更注重兩個指標之間的相關性，因此和異常KPI 因果性更強的系統(tǒng)指標將在隨機游走中獲得更高的訪問次數(shù)。然后隨機游走的結果和指標的異常程度對于異常的指標計算潛在根因得分，計算方式如下：

除PC 算法外，也有一些論文采用相關性分析的方法構建故障傳播圖。例如，BRCA[23]通過分析應用服務監(jiān)控指標數(shù)據(jù)中的告警信息去構造故障傳播圖，然后通過基于故障傳播圖設計排序算法實現(xiàn)根因定位。

另外也有一些算法結合系統(tǒng)信息和自動學習方法以構建更完整的故障傳播圖。Microscope[24]首先通過PC 算法和網(wǎng)絡IP 及端口信息構建了微服務內各子服務之間的故障傳播圖，然后通過一些預定義的規(guī)則去獲取候選根因列表，并使用皮爾森相關性系數(shù)對候選根因排序。CauseInfer[25]通過不同服務節(jié)點之間的網(wǎng)絡通信數(shù)據(jù)去構造服務節(jié)點之間的故障傳播圖，基于PC 算法去構造單個服務節(jié)點上不同監(jiān)控指標之間的因果圖，結合構造的服務節(jié)點之間的故障傳播圖和單個服務節(jié)點上的因果圖，通過DFS算法搜索所有異常節(jié)點，并根據(jù)得分對根因進行排序輸出。DFS 算法遍歷得到的故障傳播圖，當某個異常節(jié)點無異常子節(jié)點，則判斷此指標為根因指標。如果該節(jié)點指標正常，則對父節(jié)點指標進行異常檢測，重復此步驟。由于存在多條因果路徑，DFS 算法最終得到的是根因節(jié)點的集合?；趜-score 方法計算每個根因節(jié)點的得分，對其進行排序輸出。計算公式如下，其中和是平均值和標準滑動窗口的偏差。

5 結論與展望

本文介紹了云原生架構下面臨的運維挑戰(zhàn)，總結了通用的微服務架構根因定位框架，分別介紹了基于指標、系統(tǒng)拓撲關系、異常告警等信息構造故障傳播圖，以及異常根因推理的方法。文中介紹的微服務架構根因定位方案有以下特點：

（1）通用性強：基于圖推理的根因定位方法適用于云原生架構的多種類型異常。

（2）可解釋性強：本文闡述的故障傳播圖的構建方案能夠自動梳理告警風暴背后的邏輯關聯(lián)，直觀地將異常在系統(tǒng)中的傳播關系展現(xiàn)給運維工程師，且故障傳播圖的構建依賴準確的系統(tǒng)拓撲結構和應用調用日志，因此具有很強的可解釋性。

（3）自適應且輕量級：以上方案只需要少量人工干預，節(jié)約了大量人力，并且該框架可以適應網(wǎng)絡應用的動態(tài)變化（如線上系統(tǒng)的頻繁變更）。

現(xiàn)有的框架僅通過可捕獲的時空數(shù)據(jù)挖掘潛在的依賴關系，但這類挖掘方法的準確度有限。此外，現(xiàn)有的方法在挖掘到依賴關系后僅依賴故障傳播圖進行異常的定位，鎖定可能導致異常的關鍵指標、關鍵組件或關鍵異常事件，尚未有方法能夠給出對應止損策略。另外，如果能夠結合運維人員專家經(jīng)驗，就能構建出更準確、更精簡的故障傳播圖。在異常根因推理過程中，可以基于強化學習等方法提高定位的準確性，實現(xiàn)快速、準確的止損。

利益沖突說明

所有作者聲明不存在利益沖突關系。