郭正 郭寧 黃蘊思

（中國移動通信集團廣東有限公司 廣東省廣州市 510000）

1 概述

隨著云計算的深入發(fā)展和IT技術(shù)架構(gòu)的大變革，企業(yè)數(shù)字化轉(zhuǎn)型（云化）已經(jīng)步入深水區(qū)。例如，政務(wù)云可以為政府行業(yè)提供基礎(chǔ)設(shè)施、軟件支持等功能[1]；工業(yè)云可以為企業(yè)提供工業(yè)軟件、知識庫等云服務(wù)[2]；金融云為銀行、證券、保險等機構(gòu)提供服務(wù)，用來承載應(yīng)用和高并發(fā)業(yè)務(wù)[3]。

在開展業(yè)務(wù)系統(tǒng)云化、容器化的過程中，產(chǎn)生了很多新的運維痛點，最典型的痛點是故障定位[4]。在云計算中會大規(guī)模地共享計算資源，盡管單個計算節(jié)點的可靠性可以達到很高，但是當計算節(jié)點的規(guī)模很大時，不可避免地會經(jīng)常出現(xiàn)計算節(jié)點故障的問題。這將帶來如下運維痛點現(xiàn)象：告警量大，告警處理工作激增；故障定位大部分依賴人工，對人員的專業(yè)水平要求較高，時效性得不到保障。因此，對故障發(fā)生的根因進行自動化的分析就顯得非常具有價值。

實際上，系統(tǒng)故障定位是有跡可循的。云應(yīng)用系統(tǒng)的網(wǎng)元組件通過相互協(xié)作正常運行，當系統(tǒng)發(fā)生故障時，系統(tǒng)下的網(wǎng)元內(nèi)部的某些性能指標同樣會發(fā)生異常。使用異常檢測、固定閾值等方法對系統(tǒng)內(nèi)部網(wǎng)元下的性能指標進行監(jiān)測，以告警的方式將各種性能指標異常變化反映出來?？梢允褂孟到y(tǒng)一段時間的歷史指標異常告警數(shù)據(jù)，基于歷史告警數(shù)據(jù)，采用關(guān)聯(lián)規(guī)則FP-growth算法分析告警事件之間的關(guān)聯(lián)關(guān)系，判斷同時出現(xiàn)的概率，以此分析出當前系統(tǒng)下某些網(wǎng)元的某些指標發(fā)生異常告警，是另外一些網(wǎng)元的異常告警的根本原因[5-10，13-15]。

本論文設(shè)計了一個基于多維度數(shù)據(jù)挖掘的自學(xué)習(xí)故障根因定位系統(tǒng)。該系統(tǒng)注意到組件和主機之間存在部署環(huán)境依賴的關(guān)系。這些關(guān)系構(gòu)成了一個系統(tǒng)復(fù)雜的網(wǎng)絡(luò)拓撲結(jié)構(gòu)圖，當系統(tǒng)內(nèi)部某些組件出現(xiàn)故障時，從調(diào)用關(guān)系上觀察會看到存在調(diào)用依賴關(guān)系的上游組件也表現(xiàn)出異常，從時間上觀察會看到在短時間內(nèi)產(chǎn)生大量告警。因此，該系統(tǒng)以系統(tǒng)拓撲結(jié)構(gòu)、告警時間這兩個維度為切入口，以系統(tǒng)歷史故障告警為基礎(chǔ)數(shù)據(jù)?；跉v史告警數(shù)據(jù)，使用機器學(xué)習(xí)相關(guān)性分析算法，分析出存在傳導(dǎo)關(guān)系的故障告警規(guī)則。 然后告知運維人員對這些規(guī)則進行關(guān)系確認和人工標記，借助XGBoost算法[11]學(xué)習(xí)擴展規(guī)則庫，最后通過知識圖譜實現(xiàn)根因定位，降低故障排障時間成本。

2 基于多維度數(shù)據(jù)挖掘的自學(xué)習(xí)故障根因檢測系統(tǒng)

2.1 系統(tǒng)和數(shù)據(jù)集介紹

本論文研究的應(yīng)用系統(tǒng)來自于數(shù)據(jù)中心的實際運維場景，其基本組成單位稱為網(wǎng)元，網(wǎng)元之間相互協(xié)作以對外提供特定的功能。如圖1所示，代理服務(wù)器1和2（簡稱haproxy1、haproxy2）、web服務(wù)器（簡稱webcore1、webcore2、webcore3）、數(shù)據(jù)庫服務(wù)器（Mysql、Redis1）、主 機1到4（簡 稱（Host1、Host2、Host3、Host4）均為網(wǎng)元。由此可見，不同的網(wǎng)元實現(xiàn)不同的功能，網(wǎng)元可以進一步分為應(yīng)用系統(tǒng)和實際物理系統(tǒng)，例如haproxy1、haproxy2、webcore1、webcore2、webcore3、Mysql、Redis1是提供某種特定功能的軟件系統(tǒng)，Host1、Host2、Host3、Host4是物理機器。

圖1：網(wǎng)元關(guān)系

網(wǎng)元之間的關(guān)系可以分為網(wǎng)元的調(diào)用關(guān)系（又稱網(wǎng)絡(luò)調(diào)用拓撲關(guān)系）和部署關(guān)系。圖1(a)給出了一個網(wǎng)元調(diào)用關(guān)系的拓撲圖的例子，例如Webcore3調(diào)用了Redis緩存組件,那么它們之間就畫一條邊表示它們之間存在調(diào)用關(guān)系，每一個調(diào)用關(guān)系由源網(wǎng)元id、目標網(wǎng)元id、具體網(wǎng)元調(diào)用關(guān)系等內(nèi)容構(gòu)成。網(wǎng)元的部署關(guān)系描述了網(wǎng)元之間的部署位置之間的關(guān)系，如圖1(b)所示，如果Mysql部署在主機4上，則在Mysql和主機4之間畫一條邊表示它們之間的部署關(guān)系。

在系統(tǒng)運維中，通過監(jiān)測軟件對網(wǎng)元進行監(jiān)控并上報的各項性能數(shù)據(jù)，這些性能數(shù)據(jù)也稱為指標，監(jiān)控系統(tǒng)按照一定的時間周期、數(shù)據(jù)格式對網(wǎng)元的各項指標進行采集上報，指標可以反映網(wǎng)元在某個時間節(jié)點的狀態(tài)。系統(tǒng)故障會導(dǎo)致指標異常，如果指標異常超過某個閾值或者不符合某個固定規(guī)則時，該指標會觸發(fā)告警。

問題的難點在于：在正常情況下，由于業(yè)務(wù)的隨機性會導(dǎo)致多個指標發(fā)生異常報警；在于當一個故障發(fā)生的時候，會導(dǎo)致這個組件以及與這個組件有調(diào)用關(guān)系的組件上的眾多指標發(fā)生異常。如何識別是否有故障發(fā)生以及故障發(fā)生了如何定位到導(dǎo)致故障的原因。本論文研究基于告警信息和指標歷史數(shù)據(jù)的根因分析和故障定位[12]。

本論文使用的告警信息格式如表1所示。這個表的不同列分別表示告警時間、告警指標、 網(wǎng)元對象id、告警類型、告警內(nèi)容等字段。其中告警類型表示告警發(fā)生的網(wǎng)元的類型是主機或軟件實例。

表1：告警數(shù)據(jù)格式

2.2 系統(tǒng)整體結(jié)構(gòu)

如圖2所示，定位系統(tǒng)由告警知識圖譜和根因定位兩部分構(gòu)成，圖2(a)給出了告警知識圖譜構(gòu)建的過程，首先對訓(xùn)練數(shù)據(jù)集進行提取和構(gòu)建，然后采用FP-Growth從告警數(shù)據(jù)集合中發(fā)現(xiàn)相關(guān)的告警規(guī)則，再通過人工經(jīng)驗標注樣本訓(xùn)練XGBoost有監(jiān)督學(xué)習(xí)模型自動擴張告警規(guī)則,最后根據(jù)前面步驟得到的告警對構(gòu)建告警知識圖譜。根因定位部分如圖2(b)所示，接收到告警數(shù)據(jù)后，首先把告警數(shù)據(jù)入庫，然后從知識圖譜上獲得告警子樹，并根據(jù)得到的告警子樹實現(xiàn)根因定位。

圖2：系統(tǒng)整體結(jié)構(gòu)

2.3 訓(xùn)練數(shù)據(jù)集的構(gòu)建

本節(jié)構(gòu)建用于后續(xù)FP-Growth的告警數(shù)據(jù)集合。本節(jié)的目的是盡可能的把相關(guān)的告警數(shù)據(jù)分類到相同的數(shù)據(jù)集合中，便于FPGrowth發(fā)現(xiàn)關(guān)聯(lián)告警，進而形成具有因果關(guān)系的知識圖譜。如前所述，故障可能導(dǎo)致告警信號沿著兩個維度傳播：沿著具有調(diào)用關(guān)系的網(wǎng)元拓撲傳播和沿著時間軸傳播。同樣地，告警訓(xùn)練集合的構(gòu)建也應(yīng)該沿著這兩個方向進行構(gòu)建：基于拓撲的訓(xùn)練數(shù)據(jù)集的構(gòu)建；基于時間的訓(xùn)練數(shù)據(jù)集的構(gòu)建。前者適用于能夠獲得拓撲關(guān)系和部署關(guān)系的場景，后者則適用于一般的場景。

2.3.1 基于拓撲的訓(xùn)練數(shù)據(jù)集的構(gòu)建

首先，根據(jù)如圖1(a)所示的系統(tǒng)拓撲關(guān)系對數(shù)據(jù)和圖1(b)所示的部署關(guān)系對，獲得所有的可能的調(diào)用關(guān)系對和部署關(guān)系對。不失一般性，稱一個關(guān)系對中的兩個網(wǎng)元分別為A和B。

遍歷每一個關(guān)系對，對于每一個關(guān)系對產(chǎn)生一個告警訓(xùn)練數(shù)據(jù)集合，細節(jié)如下：從歷史告警數(shù)據(jù)集合中過濾出從現(xiàn)在開始計算的一個時間窗口內(nèi)包括有A或者B網(wǎng)元ID的告警記錄。然后把這些包括有A或者B網(wǎng)元ID的告警記錄并入到訓(xùn)練數(shù)據(jù)集合。時間窗口是算法的一個參數(shù)，本文的時間窗口是一個月。例如在圖1(a)中haproxy1和webcore1存在調(diào)用關(guān)系，則從歷史數(shù)據(jù)中過濾出最近一個月內(nèi)包含有haproxy1或者webcore1的告警信息，并把這些告警并入到訓(xùn)練數(shù)據(jù)集合中。

然后，進行告警集合過濾。由上一步可以產(chǎn)生很多訓(xùn)練數(shù)據(jù)集合，每一個集合中包括了對應(yīng)具有調(diào)用關(guān)系的兩個網(wǎng)元的所有指標的告警信息。同一個集合中的不同指標之間的可能存在因果關(guān)系，也可能不存在因果關(guān)系。為了便于后續(xù)因果關(guān)系的挖掘，需要把那些互相之間不存在因果關(guān)系的指標過濾掉。對于每一個訓(xùn)練數(shù)據(jù)集合，執(zhí)行如下步驟：

步驟1：統(tǒng)計得到該集合內(nèi)告警總數(shù)量。

步驟2：按照網(wǎng)元、告警指標兩個維度對集合進行劃分，每一個劃分成為一個類別。

步驟3：用告警總數(shù)量除以類別數(shù)目，得到平均告警數(shù)量。

步驟4：對每一個類別進行如下判斷：如果該類別的告警數(shù)量小于平均告警數(shù)量，則認為該類別的告警對于故障定位沒有意義，則把該類別中的告警從訓(xùn)練數(shù)據(jù)集合中刪除。

2.3.2 基于時間方式的訓(xùn)練數(shù)據(jù)集的構(gòu)建

當無法獲得如圖1所示的調(diào)用和部署關(guān)系圖時，則采用基于時間的訓(xùn)練數(shù)據(jù)集的構(gòu)建方式。對于每一個訓(xùn)練數(shù)據(jù)集合，執(zhí)行如下步驟：

步驟1：從歷史記錄中獲取最近一天的歷史告警數(shù)據(jù)，該集合中包括所有網(wǎng)元的所有指標，把該集合作為訓(xùn)練數(shù)據(jù)集合。然后執(zhí)行2.3.1節(jié)中的步驟1-4，對訓(xùn)練數(shù)據(jù)集進行過濾。

步驟2：獲取歷史一個月告警數(shù)據(jù)集合，重復(fù)2.3.1節(jié)中的步驟1-4，把2.3.1節(jié)中的步驟4得到的需要過濾的網(wǎng)元、指標列表，從本節(jié)步驟1得到的訓(xùn)練集合中過濾掉出現(xiàn)在該列表中的告警。

2.4 FP-Growth算法告警指標相關(guān)性分析

將2.2節(jié)獲得的訓(xùn)練數(shù)據(jù)集合輸入至FP-growth算法當中，通過FP-growth算法發(fā)現(xiàn)具有強關(guān)聯(lián)性的告警指標組，并給出告警指標組的可信度度量。

具體步驟如下：

步驟1：按照時間維度將訓(xùn)練數(shù)據(jù)集合分為不同的項集。項集即頻繁項集中的購物籃，每一個告警消息相當于購物籃模型中的商品。本文采用2分鐘的時間間隔對訓(xùn)練數(shù)據(jù)集合進行劃分，每一個劃分是一個項集。采用2分鐘間隔的原因如下：從業(yè)務(wù)層面解釋來看，單個告警發(fā)生基本上會在2分鐘之內(nèi)影響其它指標。

步驟2：使用FP-growth算法對以上數(shù)據(jù)進行頻繁項挖掘。在本文中，結(jié)合實際運維領(lǐng)域知識，將項集的大小限制為2，即僅分析指標A—>B之間的關(guān)聯(lián)關(guān)系，以減少計算復(fù)雜度。

步驟3：根據(jù)置信度和提升度對規(guī)則進行過濾?；趯嶋H運維業(yè)務(wù)經(jīng)驗，本文僅保留置信度大于0.9且提升度大于1的規(guī)則，刪去其它規(guī)則。

最終，F(xiàn)P-growth算法輸出的關(guān)聯(lián)規(guī)則樣式如表2所示。

表2：FP-Growth算法輸出數(shù)據(jù)示例

2.5 人工審核及自動規(guī)則標記

FP-growth算法得到的規(guī)則存在如下問題：由于噪聲的影響，可能有的規(guī)則在業(yè)務(wù)邏輯上不正確；其次，可能輸出的規(guī)則與實際故障經(jīng)驗傳導(dǎo)關(guān)系方向相反；規(guī)則的數(shù)量有限。

針對前兩個問題，采用人工審核的方法對規(guī)則進行審核并做標記。即將FP-growth算法輸出的告警指標相關(guān)性規(guī)則列表，交由運維人員進行標記，對于符合運維人員經(jīng)驗的規(guī)則，標記為1，反之標記為0。

對于輸出的規(guī)則與實際故障經(jīng)驗傳導(dǎo)關(guān)系方向相反，例如(對象1+指標A—>對象1+指標B, 1)方向相反，則調(diào)整規(guī)則的傳導(dǎo)關(guān)系方向，可得(對象1+指標B—>對象1+指標A, 1)。

對于規(guī)則數(shù)量有限這個問題，則采用如下方法解決：人工審核后的規(guī)則本身即可作為后續(xù)系統(tǒng)故障產(chǎn)生后告警合并于根因分析的依據(jù)，但系統(tǒng)下告警分析出來的規(guī)則是慢慢積累，并非一蹴而就的。對于某些規(guī)則來說在相同的場景但不同的網(wǎng)元上是通用的，例如Host1 下的磁盤讀寫速度延遲高導(dǎo)致Host1下CPU使用率高這個規(guī)則對于Host2也是適用的。但是有可能Host1的規(guī)則生成過一段時間內(nèi)Host2規(guī)則才會產(chǎn)生。為了縮短規(guī)則的產(chǎn)生時間和節(jié)約人工打標的工作量，本文采用有監(jiān)督的分類算法實現(xiàn)規(guī)則的自動標記。

具體來說，本文采用XGBoost實現(xiàn)有監(jiān)督學(xué)習(xí)的分類。在訓(xùn)練階段，把經(jīng)過人工審核的規(guī)則及標記結(jié)果輸入到XGBoost訓(xùn)練模型，在預(yù)測階段，輸入的格式規(guī)則如表2所示，XGBoost輸出該規(guī)則是否成立。

2.6 根因規(guī)則知識圖譜的構(gòu)建

在2.5節(jié)獲得規(guī)則列表后，需構(gòu)建用于根因定位的根因規(guī)則知識圖譜，具體方法如下：以告警指標作為圖的節(jié)點，如果兩個規(guī)則告警指標之間存在規(guī)則，則在對應(yīng)的兩個節(jié)點之間增加一個連邊，例如，如果存在如下規(guī)則：（Host1，告警指標A）—> （Host1，告警指標B），則FD（Host1，告警指標A），（Host1，告警指標B）作為圖中的兩個節(jié)點v1和v2，并從v1向節(jié)點v2增加一條有向邊。最終得到樹形結(jié)構(gòu)的知識圖譜，如圖3所示。

圖3：根因規(guī)則知識圖譜結(jié)構(gòu)

2.7 根因定位

當系統(tǒng)故障時，獲取從故障時刻點起半個小時之內(nèi)的告警數(shù)據(jù)。然后，對每一個發(fā)生的告警，在2.6節(jié)獲得的知識圖譜樹中標記該告警對應(yīng)的節(jié)點。如果這些標記的節(jié)點構(gòu)成一個樹，這顆樹的根節(jié)點就是根因。如果得到多個樹，就存在多個根因。

3 實驗結(jié)果

3.1 實驗數(shù)據(jù)集

有部署關(guān)系的原始告警數(shù)據(jù)集（一共33242條原始告警,詳情見附件：./data/有部署關(guān)系-原始告警.csv）

無部署關(guān)系的原始告警數(shù)據(jù)集（一共33018 條原始告警，詳情見附件：：./data/有部署關(guān)系-原始告警.csv）

3.2 實驗流程

（1）對原始告警數(shù)據(jù)基于時間段(n-min)進行分片處理；

（2）將每個桶內(nèi)的告警進行去重處理得到關(guān)聯(lián)規(guī)則算法的基礎(chǔ)項集；

（3）配置支持度、置信度、提升度等過濾關(guān)聯(lián)規(guī)則的指標，配置（最小支持度閾值minSupport：0.01，最小置信度閾值minConfidence：0.9，最小提升度閾值minLift:1）如果輸出的關(guān)聯(lián)規(guī)則均滿足上述要求，則認為該規(guī)則具有較高的可信度和有效度；

（4）將第2步驟的基礎(chǔ)項集數(shù)據(jù)和第3步驟配置的過濾閾值參數(shù)輸入關(guān)聯(lián)規(guī)則算法，輸出關(guān)聯(lián)規(guī)則結(jié)果集,關(guān)聯(lián)規(guī)則形式如: （實例類**webcore1**jvm內(nèi)存使用率高 —>實例類**webcore1**jvmgc次數(shù)告警, 置信度:1，提升度：8.89）；

（5）對實驗得到的上述關(guān)聯(lián)規(guī)結(jié)果集則進行人工標注，校驗每條規(guī)則是否符合運維經(jīng)驗知識，計算以下參數(shù)下的Precision、Recall、F1值。

（6）針對時間切片單位n-min中的n-min分別采取 [1min,2min,5min,10min] 不同的值，重復(fù)整個實驗，得到 [1min,2min,5min,10min]四種不同實驗條件下的關(guān)聯(lián)規(guī)則結(jié)果的Precision、Recall、F1值。

3.3 實驗結(jié)果

表3、表4分別為對有部署關(guān)系和無部署關(guān)系的歷史告警數(shù)據(jù)在控制件條件(最小支持度閾值minSupport：0.01，最小置信度閾值minConfidence：0.9，最小提升度閾值minLift:1）)下，采用[1min,2min,5min,10min]不同的時間切片進行關(guān)聯(lián)規(guī)則分析，并對產(chǎn)生的關(guān)聯(lián)規(guī)則進行效果驗證的結(jié)果。

表3：有部署關(guān)系的實驗結(jié)果

表4：無部署關(guān)系的實驗結(jié)果

把關(guān)聯(lián)規(guī)則集合A中的規(guī)則數(shù)記為n，其中符合運維專家經(jīng)驗的規(guī)則數(shù)記為m1，歷史告警數(shù)據(jù)中實際包含的正確有效的規(guī)則數(shù)記為m2。

Precision為關(guān)聯(lián)規(guī)則集合A中符合運維專家經(jīng)驗的規(guī)則數(shù)的占比，計算如下：

Recall為符合運維專家經(jīng)驗的規(guī)則數(shù)在歷史告警數(shù)據(jù)中實際全部有效規(guī)則數(shù)的占比，計算如下：

F1為結(jié)合Precision和Recall評估指標的綜合評價指標，計算如下：

實驗結(jié)果最終采取綜合的評估指標F1值最優(yōu)，以及如果F1一致，則才取n-min最小的原則，對[1min,2min,5min,10min]不同的時間切片下的結(jié)果進行對比發(fā)現(xiàn)有部署關(guān)系和無部署關(guān)系情況下的歷史告警數(shù)據(jù)，取得最優(yōu)的結(jié)果的都是采用2min的時間段進行切片，可以解釋為一般的原因告警事件會在2min內(nèi)引發(fā)結(jié)果告警事件的發(fā)生，符合實際運維場景中的經(jīng)驗知識。

4 結(jié)束語

隨著云計算的深入發(fā)展和IT技術(shù)架構(gòu)的大變革，越來越多的企業(yè)開始了數(shù)字化轉(zhuǎn)型，開啟了“云服務(wù)”的時代，但與此同時也涌現(xiàn)了許多運維痛點。本文設(shè)計并實現(xiàn)了一種基于多維數(shù)據(jù)挖掘的自學(xué)習(xí)故障根因檢測系統(tǒng)，包括根因規(guī)則知識圖譜的構(gòu)建過程和故障根因的預(yù)測分析過程。通過該系統(tǒng)可以實現(xiàn)多維度自動提取運維知識、沉淀專家規(guī)則、自動對學(xué)習(xí)到的規(guī)則進行打標以及對新來的告警進行故障根因的預(yù)測。使用的架構(gòu)具備通用性，根因規(guī)則輸出模型和自動打標模型可以持續(xù)訓(xùn)練，為運維工作提高效率的同時也大幅減小了成本。