湯泳，蘇寧科技集團智能監控與運維產研中心總監，中國商業聯合會智庫顧問，致力於海量數據分析、基於深度學習的時間序列分析與預測、自然語言處理和圖神經網絡的研究。在應用實踐中，通過基於 AI 的方式不斷完善智能監控體系的建設，對日常和大促提供穩定性保障。
概述
知識圖譜有較強的知識表達能力、直觀的信息呈現能力和較好的推理可解釋性，因此知識圖譜在推薦系統、問答系統、搜索引擎、醫療健康、生物製藥等領域有着廣泛的應用。運維知識圖譜構建相對於其他領域的知識圖譜構建而言，具有天然的優勢，網絡設備固有的拓撲結構、系統應用的調用關係可以快速的構成軟硬件知識圖譜中的實體和關係。歷史的告警數據蘊含着大量的相關、因果關係，使用因果發現算法，也可以有效的構建告警知識圖譜。基於知識圖譜上的權重進行路徑搜索，可以給出根因的傳播路徑，便於運維人員快速的做出干預決策。
蘇寧通過 CMDB、調用鏈等數據構建軟硬件知識圖譜，在此基礎上通過歷史告警數據構建告警知識圖譜，並最終應用知識圖譜進行告警收斂和根因定位。本文主要包括運維知識圖譜構建、知識圖譜存儲、告警收斂及根因定位等內容。
痛點及產品對策演進
痛點
- 蘇寧內部系統和服務的複雜性:
6000+ 系統，數量還在增加;
系統間調用方式複雜: 大部分使用 RSF，也有 HTTP、HESSIAN 等;
蘇寧業務的複雜: 既有線上新業務又有線下老業務，這些業務系統之間會有大量的關聯。
- 基礎環境的複雜性:
多數據中心，每個數據中心會劃分多個邏輯機房和部署環境;
服務器規模 30w+，例如，緩存服務器就有可能有上千臺服務器;
設備複雜性: 多品牌的交換機，路由器，負載均衡，OpenStack, KVM, k8s 下 docker，swarm 下的 docker 等。
基礎設施的複雜性導致每天平均產生 10w+ 的告警事件，峯值可達到 20w+ / 天。面對海量的運維監控數據，系統和指標間關聯關係越來越複雜，一個節點出現故障，極易引發告警風暴，波及更廣的範圍，導致定位問題費時費力。此時，單純依靠人肉和經驗分析，越來越難以爲繼。迫切需要一個工具，可以輔助我們分析系統和指標間關聯關係，可視化展示告警的傳播路徑和影響範圍等。
產品對策演進
針對上述痛點，我們採用領域知識結合 AI 的方法對告警進行收斂，以緩解告 警風暴。此外，爲便於一線運維人員快速的作出干預決策，我們同時對告警的傳播路徑和影響範圍進行分析。
- 基於交叉熵的告警聚類(1.0 版本)
按照告警的場景和規則，利用交叉熵對告警信息進行聚類，實現告警的收斂。 借鑑 moogsoft 的思想，將告警聚類結果生成 situation，同一個 situation 中包含同場景、有關聯的告警。
缺點:
-
收斂效果有限，該方法只能減少 30% 左右的告警，無法有效解決告警風暴問題;
-
無法提供根告警以及根因鏈路
-
弱解釋性
-
無法解決告警的根因問題。
- 基於 GRANO 算法的根因定位(2.0 版本)
根因定位是在告警收斂的基礎上進行的，採用 GRANO[2] 算法，基於告警收斂結果生成 situation，計算 situation 中每個告警節點的得分，然後排序來確定根因。
缺點:
- 這種方法的缺點是不會給出一條完整的根因鏈路，因此根因的可解釋性不強。
- 基於運維知識圖譜的告警收斂和根因定位(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: https://github.com/vesoft-inc/nebula-web-docker
4.2 告警知識圖譜構建
4.2.1 告警數據分類
原來的告警分類採用是交叉熵方法: 告警信息、分詞、統計詞頻、計算與各類別的相似度(交叉熵)，若相似度大於閾值，選擇相似度最高的那一類歸到該類，若相似度均小於閾值，則新增一個類別。
這樣做的缺點:
-
無法控制分類的數量，比如如果閾值設的較大，就會出現好多類別；如果設置的較小，很多告警又會歸到一類。
-
無法控制類別的具體含義，分類依賴於交叉熵的計算結果以及閾值的設置，無法確切知道每個類別的真正含義。
上述這種方法無法滿足我們構建因果圖的需要。
爲了讓構建的因果圖有更好的說服力和可解釋性，我們需要對各種告警信息進行人工分類，比如有的告警是對應於基礎設施，比如網卡流量，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 告警數據構建運維知識圖譜進行告警收 斂和根因定位，基礎設施層面的告警數據更簡單、規範，後續還要擴展到更復雜的非基礎設施層面的告警數據中。當前還沒有利用知識圖譜對異常檢測(時間序列數據)結果做根因定位的應用實踐，這需要對時間序列做因果關係的發現，構建時間序列之間的因果圖，從而打通知識圖譜與異常檢測的壁壘，這也是知識圖譜後續使用的擴展方向之一。
謝謝你讀完本文 (///▽///)
要來近距離體驗一把圖數據庫嗎？NebulaGraph 阿里雲計算巢現 30 天免費使用中，點擊鏈接 節省大量的部署安裝時間來搞定業務吧~
想看源碼的小夥伴可以前往 GitHub 閱讀、使用、(з)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用戶一起交流圖數據庫技術和應用技能，留下「你的名片」一起玩耍呢~