蘇寧基於 AI 和圖技術的智慧監控體系的建設

湯泳，蘇寧科技集團智慧監控與運維產研中心總監，中國商業聯合會智庫顧問，致力於海量資料分析、基於深度學習的時間序列分析與預測、自然語言處理和圖神經網路的研究。在應用實踐中，透過基於 AI 的方式不斷完善智慧監控體系的建設，對日常和大促提供穩定性保障。

概述

知識圖譜有較強的知識表達能力、直觀的資訊呈現能力和較好的推理可解釋性，因此知識圖譜在推薦系統、問答系統、搜尋引擎、醫療健康、生物製藥等領域有著廣泛的應用。運維知識圖譜構建相對於其他領域的知識圖譜構建而言，具有天然的優勢，網路裝置固有的拓撲結構、系統應用的呼叫關係可以快速的構成軟硬體知識圖譜中的實體和關係。歷史的告警資料蘊含著大量的相關、因果關係，使用因果發現演算法，也可以有效的構建告警知識圖譜。基於知識圖譜上的權重進行路徑搜尋，可以給出根因的傳播路徑，便於運維人員快速的做出干預決策。

蘇寧透過 CMDB、呼叫鏈等資料構建軟硬體知識圖譜，在此基礎上透過歷史告警資料構建告警知識圖譜，並最終應用知識圖譜進行告警收斂和根因定位。本文主要包括運維知識圖譜構建、知識圖譜儲存、告警收斂及根因定位等內容。

痛點及產品對策演進

痛點

1. 蘇寧內部系統和服務的複雜性:
   6000+ 系統，數量還在增加;

系統間呼叫方式複雜: 大部分使用 RSF，也有 HTTP、HESSIAN 等;

蘇寧業務的複雜: 既有線上新業務又有線下老業務，這些業務系統之間會有大量的關聯。

1. 基礎環境的複雜性:
   多資料中心，每個資料中心會劃分多個邏輯機房和部署環境;

伺服器規模 30w+，例如，快取伺服器就有可能有上千臺伺服器;

裝置複雜性: 多品牌的交換機，路由器，負載均衡，OpenStack, KVM, k8s 下 docker，swarm 下的 docker 等。

基礎設施的複雜性導致每天平均產生 10w+ 的告警事件，峰值可達到 20w+ / 天。面對海量的運維監控資料，系統和指標間關聯關係越來越複雜，一個節點出現故障，極易引發告警風暴，波及更廣的範圍，導致定位問題費時費力。此時，單純依靠人肉和經驗分析，越來越難以為繼。迫切需要一個工具，可以輔助我們分析系統和指標間關聯關係，視覺化展示告警的傳播路徑和影響範圍等。

產品對策演進

針對上述痛點，我們採用領域知識結合 AI 的方法對告警進行收斂，以緩解告 警風暴。此外，為便於一線運維人員快速的作出干預決策，我們同時對告警的傳播路徑和影響範圍進行分析。

1. 基於交叉熵的告警聚類(1.0 版本)
   按照告警的場景和規則，利用交叉熵對告警資訊進行聚類，實現告警的收斂。 借鑑 moogsoft 的思想，將告警聚類結果生成 situation，同一個 situation 中包含同場景、有關聯的告警。

缺點:

• 收斂效果有限，該方法只能減少 30% 左右的告警，無法有效解決告警風暴問題;

• 無法提供根告警以及根因鏈路

• 弱解釋性

• 無法解決告警的根因問題。

1. 基於 GRANO 演算法的根因定位(2.0 版本)
   根因定位是在告警收斂的基礎上進行的，採用 GRANO[2] 演算法，基於告警收斂結果生成 situation，計算 situation 中每個告警節點的得分，然後排序來確定根因。

缺點:

• 這種方法的缺點是不會給出一條完整的根因鏈路，因此根因的可解釋性不強。

1. 基於運維知識圖譜的告警收斂和根因定位(3.0 版本)
   包括全域性視角下的軟硬體知識圖譜和告警知識圖譜，利用 NLP 技術對告警文 本資訊進行分類，然後將告警收斂到軟硬體知識圖譜的相關節點上，再結合具 有因果關係的告警知識圖譜，得出一條 “A –> B –> C –> D”的根因鏈路。

優點:

• 由於結合了領域相關知識，該方法收斂效果更好，而且提供了一條完整的根因鏈路，所以解釋性更強，可以更好的為 SRE / 運維人員提供指引。

思路與架構

分層建設思路

流程架構

運維知識圖譜構建

4.1 軟硬體知識圖譜構建

軟硬體知識圖譜是以全域性的視角展示系統內各應用、軟體、虛擬機器、物理機間 的內在邏輯，系統間的呼叫關係，網路裝置的物理連線關係。圖譜中的節點包 括系統、DU(部署單元)、group(主機例項組)、軟體、虛擬機器、物理機、接入交 換機、核心交換機、匯聚交換機、路由器等。關係包括 constitute(構成)、call (呼叫)、logical(邏輯連線)、cluster(匯聚)、ship(承載)、host(宿主)、connect(物 理連線)等。軟硬體知識圖譜的原型如下:

軟硬體知識圖譜構建的資料來源主要有 CMDB 資料、呼叫鏈資料和物理裝置網路連線資料。實踐中首先基於離線資料初始化軟硬體知識圖譜，隨著業務的變化和擴充會出現舊系統的下線和新系統的上線，然後根據變化定時或定期更新軟硬體知識圖譜。

4.1.1 CMDB 資料構建流程

透過 CMDB 資料可以構建 HOST->VM->SOFTWARE->GROUP 及 GROUP (WildFly) → GROUP(Nginx)的關係圖譜。

4.1.2 呼叫鏈 / 物理裝置網路連線資料

呼叫鏈資料主要用於獲取 DU 間呼叫關係、系統間呼叫關係、DU / IP 對映關係、中介軟體間的邏輯連線關係等，資料主要透過內部的一些 API 介面獲取。

物理裝置主要包括物理機、交換機、路由器等，資料主要透過運維平臺獲取。

4.1.3 合併圖譜

將前面得到的 CMDB、呼叫鏈和物理裝置圖譜透過 networkx 合併，然後存入圖資料庫 NebulaGraph 中，最終得到的單系統和系統間圖譜分別如下(NebulaGraph Studio 視覺化呈現):

其中藍色節點為系統，淺藍色節點為 DU，綠色節點為 group，紅色節點為軟體，橙色節點為虛擬機器，深藍色節點為物理機，黃色節點為接入交換機，淡黃色節點為匯聚交換機。

NebulaGraph Studio: 

4.2 告警知識圖譜構建

4.2.1 告警資料分類

原來的告警分類採用是交叉熵方法: 告警資訊、分詞、統計詞頻、計算與各類別的相似度(交叉熵)，若相似度大於閾值，選擇相似度最高的那一類歸到該類，若相似度均小於閾值，則新增一個類別。

這樣做的缺點:

1. 無法控制分類的數量，比如如果閾值設的較大，就會出現好多類別；如果設定的較小，很多告警又會歸到一類。

2. 無法控制類別的具體含義，分類依賴於交叉熵的計算結果以及閾值的設定，無法確切知道每個類別的真正含義。

上述這種方法無法滿足我們構建因果圖的需要。

為了讓構建的因果圖有更好的說服力和可解釋性，我們需要對各種告警資訊進行人工分類，比如有的告警是對應於基礎設施，比如網路卡流量，cpu 利用率，

有的告警對應於具體軟體，比如 mysql 延遲，wildfly 無法獲取連線。這樣，每個告警類別都有自己明確的含義。在此基礎上構建的因果圖才是有意義的。

我們首先對 zabbix 六個月全量告警資訊進行了整理，將所有告警分為了 183 類，然後使用有監督的方法，訓練分類模型。這樣新來的告警資訊也可以按照 我們預先設定的類別進行分類。

分類模型我們使用的是自然語言處理方法，先對告警資訊進行分詞，然後計算詞向量，然後將詞向量作為輸入訓練模型。我們分別訓練的 cnn 和 bow(ngr ams)分類模型，整體而言，分類準確率都很高，能滿足我們的要求。其中 cnn 效果好一點，但是預測時間也會比 bow 耗時長一點。

• cnn 模型(modelcnn20e__0813):

• -------------- train_list

predict total time= 12.386132

總告警數量: 20620 錯誤個數: 0 準確率= 1.0

• -------------- test_list

predict total time= 1.452978

總告警數量: 3620 錯誤個數: 0 準確率= 1.0

• -------------- 全部六個月告警資訊

總告警數量: 733637 預測錯誤數量: 9 準確率: 0.99998

• n bow 模型(model__bow__20e__0813)

• -------------- train_list

predict total time= 1.687823

總告警數量: 20620 錯誤個數: 1 準確率= 0.999952

• -------------- test_list

predict total time= 0.272725

總告警數量: 3620 錯誤個數: 1 準確率= 0.999724

• -------------- 全部六個月告警資訊

總告警數量: 733637 預測錯誤數量: 12 準確率: 0.99998

4.2.2 因果節點選取

因果節點不具體指一個物理機或虛擬機器 IP 上的告警，而是對所有告警型別的一個抽象總結，目前包含三層(結構如下): 物理機層面的告警、虛擬機器層面 的告警、軟體層面的告警。比如: 任何一臺物理機上的當機告警都歸類於因果圖上【物理機-當機】節點。

經過告警資料分類，我們初步將所有的告警分類都作為因果節點，在經過因果演算法輸出因果邊並人工篩查確認之後，選取最終的因果節點。

4.2.3 構建因果發現樣本

基於 6 個月的 zabbix 告警資料(如上圖，共 781288 條告警)構建樣本。

構建目標:

根據告警分類，已將每一條告警記錄歸類為一種告警型別(告警型別:物理機- xx 告警、虛擬機器-xx 告警、軟體-xx 告警)。以每條虛擬機器告警記錄為中心，給定一個告警時間切片(1min、2min 等)，尋找每條虛擬機器告警時間切片內的相關告警記錄(相關告警包括: 該虛擬機器隸屬的物理機上的告警，同隸屬該臺物理機上的其他虛擬機器上的告警)集合作為一個因果發現樣本。

舉例說明:

下面是一臺虛擬機器在某一個時間點的告警，以該告警構建樣本。

給定時間切片為 1 分鐘，以上面一條虛擬機器上的告警為例，尋找 1 分鐘內與該虛擬機器相關的物理機和虛擬機器上的告警，所有告警如下圖所示為一個因果樣本。

最終轉置每一個樣本，將告警型別作為列名，集合所有的樣本，若發生告警記為 1，不發生記為 0，生成最終的因果發現樣本(因果演算法的輸入)，如下所示:

4.2.4 因果演算法

採用已有的因果發現演算法工具包:CausalDiscoveryToolbox，其中包含的演算法有: PC、GES、CCDr、LiNGAM 等。

PC：是因果發現中最著名的基於分數的方法，該演算法對變數和變數集的進行 條件測試，以獲得可能的因果邊。
GES:Greedy Equivalence Search algorithm(貪婪干涉等價搜尋演算法),是一種 基於分數的貝葉斯演算法，透過在資料上計算似然分數最小化來啟發式地搜尋 圖，以獲得因果邊。

CCDr: Concave penalized Coordinate Descent with reparametrization(引數化的凹點懲罰座標下降法)， 這是一種基於分數的用來學習貝葉斯網路的快速結構學習演算法，該方法使用稀疏正則化和塊迴圈座標下降。

目標:

採用多種因果發現演算法訓練告警資料，基於各個演算法輸出的因果邊再結合人工審查篩選確定最終的因果邊(包含因果節點)，邊確定了，相應的因果節點也確定了。

舉例說明:
以 PC 和 GES 兩個演算法為例:

PC 演算法輸出的可能因果節點和邊:

GES 演算法輸出的可能因果節點和邊:

兩個演算法都發現了【host-伺服器當機】導致【vm-伺服器當機】和【host-服務 器當機】導致【software-網頁訪問失敗】等相同的因果邊，經人工確認物理機當機確實會導致其對應的虛擬機器當機和伺服器上的軟體訪問失敗，所以確定這兩條邊為因果邊。

4.2.5 因果邊的權重計算

因果邊的權重採用條件機率計算，即:基於因果發現樣本資料和因果發現演算法給出的因果邊(包括兩個因果節點)，【因節點發生告警的條件下果節點發生告警的次數】與【因節點總共發生的告警次數】的比值作為該因果邊的權重。

舉例:

擷取部分的因果邊及其權重:【host-伺服器當機】導致【vm-伺服器當機】的因果邊權重為 0.99。

4.2.6 構建告警知識圖譜

經過【告警的分類】–>【構建因果發現樣本】–>【因果演算法發現因果邊】–> 【因果邊權重計算】，最終生成所有的因果邊及其權重。

基於 zabbix 的 781288 條告警資料，最終確定了 213 條因果邊(如上圖所 示)，根據 213 條因果邊的指向和權重，構建告警知識圖譜(部分結構如下圖所示)，並將告警知識圖譜寫入圖資料庫以便持久化讀取，後續的根因定位需從圖資料庫讀取所構建的告警知識圖譜進行分析。

知識圖譜儲存

5.1 圖資料庫引入

圖資料庫是以圖資料結構儲存和查詢資料，圖包含節點和邊。構建運維知識圖譜做根因告警分析等場景時，為了實時查詢知識圖譜，我們引入了圖資料庫，並將知識圖譜持久化儲存到圖資料庫中。另外，引入圖資料庫還有以下優勢:

(1) 圖資料庫在處理關聯資料時的速度快，而關係型資料庫在處理反向查詢以及多層次關係查詢的時候通常開銷較大，無法滿足我們的要求。

(2) 圖資料庫可解釋性好。圖資料庫基於節點和邊，以一種直觀的方式表示這些關係，具有天然可解釋性。

(3) 圖資料庫查詢語句表達性好，比如查詢一跳，兩跳資料，不需要像關係型資料庫那樣做複雜的表關聯。

(4) 圖資料庫更靈活。圖這種通用結構可以對各種場景進行建模，如社交網路、道路系統等。不管有什麼新的資料需要儲存，都只需要考慮節點屬性和邊屬性。不像關係型資料庫中，需要更新表結構，還要考慮和其他表的關聯關係 等。

5.2 圖資料庫選型

Neo4j 開源版本不支援分散式，無法滿足我們對多副本的需求; ArangoDB 是 多模態資料庫，支援 graph, document, key/value 和 search，支援分散式部署，查詢速度快; NebulaGraph 一款是國產的開源圖資料庫，支援分散式部署且部署方式比 ArangoDB 更輕便，查詢速度快，騰訊、京東等公司內部也在使用。

在充分比較了以上圖資料庫的效能，以及社群的活躍性以及開放性後，我們最終選擇 NebulaGraph。針對上述的三個圖資料庫，我們做了一個詳細的效能 Benchmark 對比:  https://discuss.nebula-graph.com.cn/t/topic/1466

告警收斂及根因定位

6.1 流程

針對告警資料的收斂和根因定位，可以分為以下主要幾個步驟。

多模態資料庫

設定時間切片粒度: 實時獲取時間切片內(1min、5min 等)的告警數 據;

告警分類: 針對原始的告警資料，結合具體的告警資訊和監控項等資訊，根據訓練好的分類模型對原始的告警資料從 HOST、VM、SOFTW ARE 三個方面進行分類，例如: vm_網路卡流量大、host_磁碟使用率過高、software_網頁訪問失敗等。

告警收斂:查詢軟硬體知識圖譜將告警以系統為單位進行收斂，收斂格式如下，格式如下:

系統 1: {軟硬體知識圖譜節點 1:[告警型別 1，告警型別 2…]， 軟硬體知識圖譜節點 2:[告警型別 1，告警型別 2…]

告警因果圖構建: 基於告警收斂結果，在圖資料庫中按照系統級別查詢每個系統下的所有節點之間的連線子圖，並將得到的結果輸入到 networkx 中，得到某個系統下的各節點之間的最終連線關係，即告警因果圖。

根因路徑: 基於上述生成的告警因果圖，以及權重來計算疑似路徑，排序給出根因路徑。

6.2 告警收斂

基於上述的主要流程，我們現以時間粒度為前後 5min 內的告警資料建立時間切片樣本，並取告警數量最多的前 100 個時間片的樣本作為主要分析的內容，其中第一個時間切片中的各個系統下各節點的告警收斂結果如下:

6.3 根因定位

對於上述第一個時間切片中的某個系統，在圖資料庫中查詢該系統下的所有節點構成的子圖，以 “蘇寧 XXX 系統”這個系統為例，查詢得到在“一跳”範圍內與該系統下的所有節點之間有關聯的節點的關係大致如下(紅色表示物理機節點，棕色表示虛擬機器節點，綠色表示軟體節點):

上圖中出現的所有節點中，既包括有告警資訊的，也包括沒有告警訊息的，因此將上述因果圖輸入到 netwokx 後，可以得到最終經過精簡後的有告警訊息發出的各節點的因果圖，其中一部分的因果圖展示如下:

可以解釋為: “192.168.xxx.xxx-host-伺服器當機”導致 “10.104.xxx.xxx-vm-服 務器當機”，進而導致“software-網頁訪問失敗”。

進一步的，根據上述生成的因果圖，再結合因果圖中每條邊的權重，就可以計算出該時間切片下的單個系統層面上的所有疑似根因路徑，經過排序後即可得到最終的根因路徑。本例中最終得到的幾條根因路徑如下:

從上圖可以看出，程式最終給出了幾條疑似的根因路徑，其中包括最長的一 條，可以解釋為: ip 為 192.168.xxx.xxx 這臺物理機由於網路卡 overruns 的

原因，導致了這臺物理機的當機，從而使得這臺物理機上的 ip 為 10.104.xx x.xxx 的虛擬機器當機，最終導致這臺虛擬機器上的相關的網頁訪問失敗。

效果及最佳化方向

在告警收斂方面，經過驗證，基於運維知識圖譜可縮減至少 50% 的告警量，最高可達到 60% 以上，有效率的緩解了告警風暴的壓力; 另外，在時效性方面，基於 1、2、5min 不同長度的時間切片進行告警收斂，耗時可以控制在 6 s 以內，滿足告警通知的時效性要求。

在根因定位方面，經一線運維人員驗證，每個告警時間段提供的可能根因傳播路徑集合基本包含了真實的根因，有效縮短了運維人員的干預時間;另外在耗時上，根因定位可以控制在 3s 以內，速度較快，滿足時效性要求。

但目前透過因果發現演算法自動構建的告警知識圖譜準確率有待進一步提升，繼續調研評估其他告警知識圖譜構建方式。繼續完善軟硬體和呼叫鏈告警知識圖譜，當前僅是基於 CMDB 和 Zabbix 告警資料構建運維知識圖譜進行告警收 斂和根因定位，基礎設施層面的告警資料更簡單、規範，後續還要擴充套件到更復雜的非基礎設施層面的告警資料中。當前還沒有利用知識圖譜對異常檢測(時間序列資料)結果做根因定位的應用實踐，這需要對時間序列做因果關係的發現，構建時間序列之間的因果圖，從而打通知識圖譜與異常檢測的壁壘，這也是知識圖譜後續使用的擴充套件方向之一。