首頁 > 易卦

【AIOps探索】基於CauseInfer方法的根因定位

作者:由 嘉為科技 發表于 易卦日期:2022-07-01

ps定位點怎麼移到中心

【AIOps探索】基於CauseInfer方法的根因定位

01

背景

近些年來,在需要支援多平臺的網際網路應用中,越來越多的公司選擇從單體系統遷移到微服務架構。微服務系統通常包含成百上千的應用,這些系統是高度動態和複雜的,一個服務可以有幾個到幾千個例項執行在不同的容器和伺服器上,而可用性問題一直是大規模微服務系統面臨的一個關鍵挑戰。在這些系統中,服務質量(如效能、可靠性)的任何異常都有可能沿著服務呼叫鏈傳播,由少量的根因節點影響到關聯節點,並最終導致業務級別的可用性問題(如訪問成功率下跌)。

【AIOps探索】基於CauseInfer方法的根因定位

針對運維中的難題,全球權威的IT研究與顧問諮詢公司 Gartner於2016年提出了AIOps(Artificial Intelligence for IT Operations)概念,即智慧運維。AIOps分析的運維資料主要有三種:指標、日誌、呼叫鏈(如上圖)。本文所探索的論文《CauseInfer:Automatic and Distributed Performance Diagnosis with Hierarchical Causality Graph in Large Distributed Systems》[1] 即以效能指標資料為依據,透過構建服務呼叫拓撲和指標因果拓撲,利用深度優先搜尋(DFS)遍歷搜尋根因效能指標,最終輸出根因指標的排序。

02

根因定位淺談

根因定位是智慧化運維中一項重要且難以實現的領域,看起來很龐大,很抽象,無從下手,也被稱之為運維的“終極命題”。目前行業內外有已有多種根因定位方案投入使用,但因為系統之間差異性及根因定位的複雜性,目前仍然沒有一套能在所有系統行之有效的方案。

因為針對不同的系統/業務,通常要針對性的使用方法,大多數人對要解決的問題都模糊不清,就想著有“尚方寶劍”一刀切的解決這個難題,這是不現實的。根因定位要具體情況具體分析,將複雜抽象的問題分解成具體明確的條件情況,下面列舉常見的根因定位場景:

搜尋定位類:

當多維KPI異常,如何定位到其根因維度,也叫指標下鑽分析,是2019年AIOps挑戰賽的賽題。

指標關聯類:

該類根因分析旨在分析海量的多維時間序列,找到故障時不同指標之間的關聯關係(因果關係)。

呼叫異常類:

該類根因分析一般具有明確的服務呼叫拓撲關係(圖),旨在捕捉服務鏈路上的異常,定位異常實體。

以上三個場景是研究人員常關注的問題,各有多篇相關論文闡述。

微服務相關的異常:可以分為效能異常(一般表現為響應時間增加,本文探討的即屬於此種),可靠性異常(一般表現為錯誤數量增加),流量異常(QPS異常)引起的微服務系統故障,此類根因定位方法關注的指標不盡相同。

針對不同的場景根因定位方法不同,針對相同的場景根因定位方法也會不同,目前大型公司使用的方法大致有以下幾種:基於呼叫鏈的根因定位方案,基於異常範圍搜尋的HotSpot演算法進行根因分析,知識圖譜方法,基於報警聚類的方法進行根因分析,基於時間序列相關性分析的演算法等等。

03

微服務架構異常診斷的難點

當出現業務級別的可用性問題時(黃金指標異常),透過指標異常檢測定位到異常的主機/節點並不難,難點在於如何從異常的節點集合中找到引起這次異常的根因節點/根因指標。通常來說,表現在以下幾個方面:

① 微服務的異常可能是由多方面的原因造成:比如網路的抖動,機器的效能故障,有時人為的操作變更也會引起微服務的故障,有效的根因定位通常需要考慮多方面的原因。

② 難以獲取固定的服務呼叫拓撲:不同的廠家微服務設計尚未規範化,且服務呼叫經常頻繁變化,基於靜態的異常定位方法難以解決動態的服務呼叫情況。

③ 當根因節點發生異常時,與其相關的其他節點的服務指標都會隨之發生抖動,形成了多節點異常,多節點內的多指標異常,如何“從萬軍之中取上將首級”地找到根因節點的根因指標,也是微服務根因定位的一大難點。

04

基於CauseInfer方法的根因定位

研究領域:

CauseInfer是針對微服務領域效能問題的根因定位方法,其主要考慮物理資源、邏輯資源(鎖)異常引起的微服務異常問題(如下圖)。

【AIOps探索】基於CauseInfer方法的根因定位

推理過程:

CauseInfer原型機可以輕量級的部署在每個節點中並分散式的工作,透過TCP請求延遲低時間複雜度的生成服務之間的拓撲關係,透過PC-Algotithm和D-Separate方法建立節點效能指標的因果拓撲圖。基於生成的服務呼叫因果圖和指標依賴因果圖,當SLO指標發生異常時,透過DFS演算法搜尋所有異常節點,並根據得分對根因進行排序輸出(如下圖)。

【AIOps探索】基於CauseInfer方法的根因定位

步驟詳情:

A。 資料收集:

從多個跨棧資料來源(app,程序,OS)收集高維資料流。在服務因果圖的構建階段,需要每個app的SLO,由於不是每個應用(比如mysql,hadoop)都有,且不同的應用的SLO不盡相同,因此作者提出統一用TCP請求延遲作為每個應用的SLO指標。

B。 異常點檢測:

對於線上的異常點檢測,CauseInfer使用Cusum的方法(此方法對噪聲敏感,在離線分析中很難檢測長期變化,會有較高誤報率),對於離線的長時間的時間序列資料,使用BCP(貝葉斯變點檢測)方法。兩個方法的效果對比如下圖。

【AIOps探索】基於CauseInfer方法的根因定位

C。 因果圖構建:

因果的定義:

變數X的變化會影響到變數Y的分佈,則稱X是Y的原因,記作X→Y,預設X、Y不會互相影響。所以要構建的目標因果圖是一個DAG。(有向無環圖)

服務因果圖:

各主機執行netstat命令獲取連線資訊列表。(包含協議、源、目標、連線狀態等)

提取TCP連線的部分構造成:source_ip:port→destination_ip:port的列表形式。

查詢埠對應的服務名,將上面的列表元素中埠替換成服務名,得到source_ip:service1→destination_ip:service2的列表。

透過Client、Server之間傳送流量的滯後相關性確認(ip,service)元組(比如(192。168。1。115,tomcat) — (192。168。1。117, httpd))之間的因果關係。假設服務A傳送的流量是(X1,X2,…。。XN),服務B傳送的流量是(B1,B2,…。。BN),則滯後相關性ρ(k)計算如下,k∈[-30,30],透過下面的計算公式找到|ρ|max時的K值,當K>0則說明A→B,否則B→A(下圖2說明k=4時,ρ最大且大於0,說明A→B。

【AIOps探索】基於CauseInfer方法的根因定位

【AIOps探索】基於CauseInfer方法的根因定位

指標因果圖:

n 基於PC-Algorithm生成,這是一種從一組變數的集合中建立DAG的演算法。G=(V,E),V表示變數集,E表示邊集。

n 基於條件交叉熵G2確認變數是否獨立(如下公式),m表示樣本集的大小,CE表示某種情況下的交叉熵,若G2>0。05,則說明(X,Y|Z)獨立。

【AIOps探索】基於CauseInfer方法的根因定位

透過PC演算法生成一個完全聯通的DAG,透過G2確定DAG中獨立的部分,從而獲得骨架圖。

使用D-Separate方法確認剩下變數的因果方向,即可得到指標因果圖。(基於PC演算法,根據是否有先驗因果關係可分成2種方法)

使用PC演算法生成的DAG可能包含多個孤立子圖,違反直覺的因果關係和雙向連結,透過以下方式選出最大子圖:

1)TCP延遲指標無子級

2)最終的影響指標在圖中從每條路徑都可抵達

3)預設的根因指標無父級

4)對於雙向鏈路,隨機取捨一個方向

根因判斷:

線上的異常點檢測:使用帶滑動視窗的雙邊Cusum方法判斷應用的SLO指標是否異常。

假設應用X指標為(X1,X2,…。。XN),視窗長度為60,透過檢測[XT-60,XT]的Cusum來判斷XT是否異常(設定上下閾值),若出現異常,則視窗暫停。

DFS深度優先演算法遍歷本應用的效能指標因果圖,當某個異常節點無異常子節點,則判斷此指標為根因指標,如果本服務效能指標正常,則對父服務SLO進行異常檢測,重複此步驟。

【AIOps探索】基於CauseInfer方法的根因定位

如果輸出的是根因節點的集合,則透過下面的公式計算得分,對根因進行排序輸出。

【AIOps探索】基於CauseInfer方法的根因定位

05

實踐

依照論文思路和實際情況,我們構建了模型,並用資料進行實驗

【AIOps探索】基於CauseInfer方法的根因定位

【AIOps探索】基於CauseInfer方法的根因定位

06

總結

當前,在大型Internet系統中,基於微服務架構的應用變得越來越普遍,而高度動態的實時執行環境使得微服務系統很容易出現效能和可用性問題。快速故障根因定位可以提高服務質量並減少收入損失。本文探索的CauseInfer方法可以自動構造兩層層次因果圖且推斷故障的原因,對於微服務系統下的效能診斷有著良好的借鑑意義。

【參考文獻】

P Chen,Y Qi,P Zheng,D Hou,CauseInfer: Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems,IEEE 2014