摘要：圍繞上面描述的問題，以及對(duì)于報(bào)警聚類處理的分析假設(shè)，本文主要做了以下事情選定聚類算法，簡(jiǎn)單描述了算法的基本原理，并給出了針對(duì)報(bào)警日志聚類的一種具體的實(shí)現(xiàn)方案。算法選擇聚類算法采用論文中描述的根因分析算法。聚類算法算法的執(zhí)行，我們以圖來表示。

眾所周知，日志是記錄應(yīng)用程序運(yùn)行狀態(tài)的一種重要工具，在業(yè)務(wù)服務(wù)中，日志更是十分重要。通常情況下，日志主要是記錄關(guān)鍵執(zhí)行點(diǎn)、程序執(zhí)行錯(cuò)誤時(shí)的現(xiàn)場(chǎng)信息等。系統(tǒng)出現(xiàn)故障時(shí)，運(yùn)維人員一般先查看錯(cuò)誤日志，定位故障原因。當(dāng)業(yè)務(wù)流量小、邏輯復(fù)雜度低時(shí)，應(yīng)用出現(xiàn)故障時(shí)錯(cuò)誤日志一般較少，運(yùn)維人員一般能夠根據(jù)錯(cuò)誤日志迅速定位到問題。但是，隨著業(yè)務(wù)邏輯的迭代，系統(tǒng)接入的依賴服務(wù)不斷增多，引入的組件不斷增多，當(dāng)系統(tǒng)出現(xiàn)故障時(shí)（如Bug被觸發(fā)、依賴服務(wù)超時(shí)等等），錯(cuò)誤日志的量級(jí)會(huì)急劇增加。極端情況下甚至出現(xiàn)“瘋狂報(bào)錯(cuò)”的現(xiàn)象，這時(shí)候錯(cuò)誤日志的內(nèi)容會(huì)存在相互掩埋、相互影響的問題，運(yùn)維人員面對(duì)報(bào)錯(cuò)一時(shí)難以理清邏輯，有時(shí)甚至顧此失彼，沒能第一時(shí)間解決最核心的問題。

錯(cuò)誤日志是系統(tǒng)報(bào)警的一種，實(shí)際生產(chǎn)中，運(yùn)維人員能夠收到的報(bào)警信息多種多樣。如果在報(bào)警流出現(xiàn)的時(shí)候，通過處理程序，將報(bào)警進(jìn)行聚類，整理出一段時(shí)間內(nèi)的報(bào)警摘要，那么運(yùn)維人員就可以在摘要信息的幫助下，先對(duì)當(dāng)前的故障有一個(gè)大致的輪廓，再結(jié)合技術(shù)知識(shí)與業(yè)務(wù)知識(shí)定位故障的根本原因。

圍繞上面描述的問題，以及對(duì)于報(bào)警聚類處理的分析假設(shè)，本文主要做了以下事情：

選定聚類算法，簡(jiǎn)單描述了算法的基本原理，并給出了針對(duì)報(bào)警日志聚類的一種具體的實(shí)現(xiàn)方案。

在分布式業(yè)務(wù)服務(wù)的系統(tǒng)下構(gòu)造了三種不同實(shí)驗(yàn)場(chǎng)景，驗(yàn)證了算法的效果，并且對(duì)算法的不足進(jìn)行分析闡述。

對(duì)一段時(shí)間內(nèi)的報(bào)警進(jìn)行聚類處理，將具有相同根因的報(bào)警歸納為能夠涵蓋報(bào)警內(nèi)容的泛化報(bào)警（Generalized Alarms），最終形成僅有幾條泛化報(bào)警的報(bào)警摘要。如下圖1所示意。

我們希望這些泛化報(bào)警既要具有很強(qiáng)的概括性，同時(shí)盡可能地保留細(xì)節(jié)。這樣運(yùn)維人員在收到報(bào)警時(shí)，便能快速定位到故障的大致方向，從而提高故障排查的效率。

如圖2所示，異常報(bào)警根因分析的設(shè)計(jì)大致分為四個(gè)部分：收集報(bào)警信息、提取報(bào)警信息的關(guān)鍵特征、聚類處理、展示報(bào)警摘要。

算法選擇

聚類算法采用論文“Clustering Intrusion Detection Alarms to Support Root Cause Analysis [KLAUS JULISCH, 2002]”中描述的根因分析算法。該算法基于一個(gè)假設(shè)：將報(bào)警日志集群經(jīng)過泛化，得到的泛化報(bào)警能夠表示報(bào)警集群的主要特征。以下面的例子來說明，有如下的幾條報(bào)警日志：

server_room_a-biz_tag-online02 Thrift get deal ProductType deal error.
server_room_b-biz_tag-offline01 Pigeon query deal info error.
server_room_a-biz_tag-offline01 Http query deal info error.
server_room_a-biz_tag-online01 Thrift query deal info error.
server_room_b-biz_tag-offline02 Thrift get deal ProductType deal error.

我們可以將這幾條報(bào)警抽象為：“全部服務(wù)器 網(wǎng)絡(luò)調(diào)用 故障”，該泛化報(bào)警包含的范圍較廣；也可以抽象為：“server_room_a服務(wù)器 網(wǎng)絡(luò)調(diào)用 產(chǎn)品信息獲取失敗”和“server_room_b服務(wù)器 RPC 獲取產(chǎn)品類型信息失敗”，此時(shí)包含的范圍較小。當(dāng)然也可以用其他層次的抽象來表達(dá)這個(gè)報(bào)警集群。

我們可以觀察到，抽象層次越高，細(xì)節(jié)越少，但是它能包含的范圍就越大；反之，抽象層次越低，則可能無用信息越多，包含的范圍就越小。

這種抽象的層次關(guān)系可以用一些有向無環(huán)圖（DAG）來表達(dá)，如圖3所示：

為了確定報(bào)警聚類泛化的程度，我們需要先了解一些定義：

屬性（Attribute）：構(gòu)成報(bào)警日志的某一類信息，如機(jī)器、環(huán)境、時(shí)間等，文中用Ai表示。

值域（Domain）：屬性Ai的域（即取值范圍），文中用Dom(Ai)表示。

泛化層次結(jié)構(gòu)（Generalization Hierarchy）：對(duì)于每個(gè)Ai都有一個(gè)對(duì)應(yīng)的泛化層次結(jié)構(gòu)，文中用Gi表示。

不相似度（Dissimilarity）：定義為d(a1, a2)。它接受兩個(gè)報(bào)警a1、a2作為輸入，并返回一個(gè)數(shù)值量，表示這兩個(gè)報(bào)警不相似的程度。與相似度相反，當(dāng)d(a1, a2)較小時(shí)，表示報(bào)警a1和報(bào)警a2相似。為了計(jì)算不相似度，需要用戶定義泛化層次結(jié)構(gòu)。

為了計(jì)算d(a1, a2)，我們先定義兩個(gè)屬性的不相似度。令x1、x2為某個(gè)屬性Ai的兩個(gè)不同的值，那么x1、x2的不相似度為：在泛化層次結(jié)構(gòu)Gi中，通過一個(gè)公共點(diǎn)父節(jié)點(diǎn)p連接x1、x2的最短路徑長(zhǎng)度。即d(x1, x2) := min{d(x1, p) + d(x2, p) | p ∈ Gi, x1 ? p, x2 ? p}。例如在圖3的泛化層次結(jié)構(gòu)中，d("Thrift", "Pigeon") = d("RPC", "Thrift") + d("RPC", "Pigeon") = 1 + 1 = 2。

對(duì)于兩個(gè)報(bào)警a1、a2，其計(jì)算方式為：

例如：a1 = ("server_room_b-biz_tag-offline02", "Thrift"), a2 = ("server_room_a-biz_tag-online01", "Pigeon"), 則d(a1, a2) = d("server_room_b-biz_tag-offline02", "server_room_a-biz_tag-online01") + d(("Thrift", "Pigeon") = d("server_room_b-biz_tag-offline02", "服務(wù)器") + d("server_room_a-biz_tag-online01", "服務(wù)器") + d("RPC", "Thrift") + d("RPC", "Pigeon") = 2 + 2 + 1 + 1 = 6。

我們用C表示報(bào)警集合，g是C的一個(gè)泛化表示，即滿足? a ∈ C, a ? g。以報(bào)警集合{"dx-trip-package-api02 Thrift get deal list error.", "dx-trip-package-api01 Thrift get deal list error."}為例，“dx服務(wù)器 thrift調(diào)用 獲取產(chǎn)品信息失敗”是一個(gè)泛化表示，“服務(wù)器 網(wǎng)絡(luò)調(diào)用 獲取產(chǎn)品信息失敗”也是一個(gè)泛化表示。對(duì)于某個(gè)報(bào)警聚類來說，我們希望獲得既能夠涵蓋它的集合又有最具象化的表達(dá)的泛化表示。為了解決這個(gè)問題，定義以下兩個(gè)指標(biāo)：

H(C)值最小時(shí)對(duì)應(yīng)的g，就是我們要找的最適合的泛化表示，我們稱g為C的“覆蓋”(Cover)。

基于以上的概念，將報(bào)警日志聚類問題定義為：定義L為一個(gè)日志集合，min_size為一個(gè)預(yù)設(shè)的常量，Gi(i = 1, 2, 3......n) 為屬性Ai的泛化層次結(jié)構(gòu)，目標(biāo)是找到一個(gè)L的子集C，滿足 |C| >= min_size，且H(C)值最小。min_size是用來控制抽象程度的，極端情況下如果min_size與L集合的大小一樣，那么我們只能使用終極抽象了，而如果min_size = 1，則每個(gè)報(bào)警日志是它自己的抽象。找到一個(gè)聚類之后，我們可以去除這些元素，然后在L剩下的集合里找其他的聚類。

不幸的是，這是個(gè)NP完全問題，因此論文提出了一種啟發(fā)式算法，該算法滿足|C| >= min_size，使H(C)值盡量小。

算法假設(shè)所有的泛化層次結(jié)構(gòu)Gi都是樹，這樣每個(gè)報(bào)警集群都有一個(gè)唯一的、最頂層的泛化結(jié)果。

將L定義為一個(gè)原始的報(bào)警日志集合，算法選擇一個(gè)屬性Ai，將L中所有報(bào)警的Ai值替換為Gi中Ai的父值，通過這一操作不斷對(duì)報(bào)警進(jìn)行泛化。

持續(xù)步驟2的操作，直到找到一個(gè)覆蓋報(bào)警數(shù)量大于min_size的泛化報(bào)警為止。

輸出步驟3中找到的報(bào)警。

算法偽代碼如下所示：

輸入：報(bào)警日志集合L，min_size，每個(gè)屬性的泛化層次結(jié)構(gòu)G1,......,Gn
輸出：所有符合條件的泛化報(bào)警
T := L;              // 將報(bào)警日志集合保存至表T
for all alarms a in T do
    a[count] := 1;   // "count"屬性用于記錄a當(dāng)前覆蓋的報(bào)警數(shù)量
while ?a ∈ T : a[count] < min_size do {
    使用啟發(fā)算法選擇一個(gè)屬性Ai;
    for all alarms a in T do
        a[Ai] := parent of a[Ai] in Gi;
        while identical alarms a, a" exist do
            Set a[count] := a[count] + a"[count];
            delete a" from T;
}

其中第7行的啟發(fā)算法為:

首先計(jì)算Ai對(duì)應(yīng)的Fi
fi(v) := SELECT sum(count) FROM T WHERE Ai = v   // 統(tǒng)計(jì)在Ai屬性上值為v的報(bào)警的數(shù)量
Fi := max{fi(v) | v ∈ Dom(Ai)}
選擇Fi值最小的屬性Ai

這里的邏輯是：如果有一個(gè)報(bào)警a滿足 a[count]>= min_size，那么對(duì)于所有屬性Ai , 均能滿足Fi >= fi(a[Ai]) >= min_size。反過來說，如果有一個(gè)屬性Ai的Fi值小于min_size，那么a[count]就不可能大于min_size。所以選擇Fi值最小的屬性Ai進(jìn)行泛化，有助于盡快達(dá)到聚類的條件。

此外，關(guān)于min_size的選擇，如果選擇了一個(gè)過大的min_size，那么會(huì)迫使算法合并具有不同根源的報(bào)警。另一方面，如果過小，那么聚類可能會(huì)提前結(jié)束，具有相同根源的報(bào)警可能會(huì)出現(xiàn)在不同的聚類中。

因此，設(shè)置一個(gè)初始值，可以記作ms0。定義一個(gè)較小的值 ?(0 < ? < 1)，當(dāng)min_size取值為ms0、ms0 (1 - ?)、ms0 (1 + ?)時(shí)的聚類結(jié)果相同時(shí)，我們就說此時(shí)聚類是?-魯棒的。如果不相同，則使ms1 = ms0 * (1 - ?)，重復(fù)這個(gè)測(cè)試，直到找到一個(gè)魯棒的最小值。

需要注意的是，?-魯棒性與特定的報(bào)警日志相關(guān)。因此，給定的最小值，可能相對(duì)于一個(gè)報(bào)警日志來說是魯棒的，而對(duì)于另一個(gè)報(bào)警日志來說是不魯棒的。

根據(jù)線上問題排查的經(jīng)驗(yàn)，運(yùn)維人員通常關(guān)注的指標(biāo)包括時(shí)間、機(jī)器（機(jī)房、環(huán)境）、異常來源、報(bào)警日志文本提示、故障所在位置（代碼行數(shù)、接口、類）、Case相關(guān)的特殊ID（訂單號(hào)、產(chǎn)品編號(hào)、用戶ID等等）等。

但是，我們的實(shí)際應(yīng)用場(chǎng)景都是線上準(zhǔn)實(shí)時(shí)場(chǎng)景，時(shí)間間隔比較短，因此我們不需要關(guān)注時(shí)間。同時(shí)，Case相關(guān)的特殊ID不符合我們希望獲得一個(gè)抽象描述的要求，因此也無需關(guān)注此項(xiàng)指標(biāo)。

綜上，我們選擇的特征包括：機(jī)房、環(huán)境、異常來源、報(bào)警日志文本關(guān)鍵內(nèi)容、故障所在位置（接口、類）共5個(gè)。

(1) 提取關(guān)鍵特征

我們的數(shù)據(jù)來源是日志中心已經(jīng)格式化過的報(bào)警日志信息，這些信息主要包含：報(bào)警日志產(chǎn)生的時(shí)間、服務(wù)標(biāo)記、在代碼中的位置、日志內(nèi)容等。

故障所在位置

優(yōu)先查找是否有異常堆棧，如存在則查找第一個(gè)本地代碼的位置；如果不存在，則取日志打印位置。

異常來源

獲得故障所在位置后，優(yōu)先使用此信息確定異常報(bào)警的來源（需要預(yù)先定義詞典支持）；如不能獲取，則在日志內(nèi)容中根據(jù)關(guān)鍵字匹配（需要預(yù)先定義詞典支持）。

報(bào)警日志文本關(guān)鍵內(nèi)容

優(yōu)先查找是否有異常堆棧，如存在，則查找最后一個(gè)異常（通常為真正的故障原因）；如不能獲取，則在日志中查找是否存在“code=......,message=......” 這樣形式的錯(cuò)誤提示；如不能獲取，則取日志內(nèi)容的第一行內(nèi)容（以換行符為界），并去除其中可能存在的Case相關(guān)的提示信息

提取“機(jī)房和環(huán)境”這兩個(gè)指標(biāo)比較簡(jiǎn)單，在此不做贅述。

(2) 聚類算法

算法的執(zhí)行，我們以圖4來表示。

(3) min_size 選擇

考慮到日志數(shù)據(jù)中可能包含種類極多，且根據(jù)小規(guī)模數(shù)據(jù)實(shí)驗(yàn)表明，min_size = 1/5 報(bào)警日志數(shù)量時(shí)，算法已經(jīng)有較好的表現(xiàn)，再高會(huì)增加過度聚合的風(fēng)險(xiǎn)，因此我們?nèi)in_size = 1/5 報(bào)警日志數(shù)量，?參考論文中的實(shí)驗(yàn)，取0.05。

(4) 聚類停止條件

考慮到部分場(chǎng)景下，報(bào)警日志可能較少，因此min_size的值也較少，此時(shí)聚類已無太大意義，因此設(shè)定聚類停止條件為：聚類結(jié)果的報(bào)警摘要數(shù)量小于等于20或已經(jīng)存在某個(gè)類別的count值達(dá)到min_size的閾值，即停止聚類。

泛化層次結(jié)構(gòu)，用于記錄屬性的泛化關(guān)系，是泛化時(shí)向上抽象的依據(jù)，需要預(yù)先定義。

根據(jù)實(shí)驗(yàn)所用項(xiàng)目的實(shí)際使用環(huán)境，我們定義的泛化層次結(jié)構(gòu)如下：

“故障所在位置”此屬性無需泛化層次結(jié)構(gòu)，每次泛化時(shí)直接按照包路徑向上層截?cái)?，直到系統(tǒng)包名。

以下三個(gè)實(shí)驗(yàn)均使用C端API系統(tǒng)。

實(shí)驗(yàn)材料來自于線上某業(yè)務(wù)系統(tǒng)真實(shí)故障時(shí)所產(chǎn)生的大量報(bào)警日志。

環(huán)境：線上

故障原因：產(chǎn)品中心線上單機(jī)故障

報(bào)警日志數(shù)量：939條

部分原始報(bào)警日志如圖9所示，初次觀察時(shí)，很難理出頭緒。

經(jīng)過聚類后的報(bào)警摘要如表1所示：

我們可以看到前三條報(bào)警摘要的Count遠(yuǎn)超其他報(bào)警摘要，并且它們指明了故障主要發(fā)生在產(chǎn)品中心的接口。

實(shí)驗(yàn)材料為利用故障注入工具，在Staging環(huán)境模擬運(yùn)營(yíng)置頂服務(wù)和A/B測(cè)試服務(wù)同時(shí)產(chǎn)生故障的場(chǎng)景。

環(huán)境：Staging（使用線上錄制流量和壓測(cè)平臺(tái)模擬線上正常流量環(huán)境）

模擬故障原因：置頂與A/B測(cè)試接口大量超時(shí)

報(bào)警日志數(shù)量：527條

部分原始報(bào)警日志如圖10所示：

經(jīng)過聚類后的報(bào)警摘要如表2所示：

從上表可以看到，前兩條報(bào)警摘要符合本次試驗(yàn)的預(yù)期，定位到了故障發(fā)生的原因。說明在多故障的情況下，算法也有較好的效果。

實(shí)驗(yàn)材料為利用故障注入工具，在Staging環(huán)境模擬產(chǎn)品中心服務(wù)和緩存服務(wù)同時(shí)產(chǎn)生超時(shí)故障的場(chǎng)景。

環(huán)境：Staging（使用線上錄制流量和壓測(cè)平臺(tái)模擬線上正常流量環(huán)境）

模擬故障原因：產(chǎn)品中心所有接口超時(shí)，所有緩存服務(wù)超時(shí)

報(bào)警日志數(shù)量：2165

部分原始報(bào)警日志如圖11所示：

經(jīng)過聚類后的報(bào)警摘要如表3所示：

從上表可以看到，緩存（Squirrel和Cellar雙緩存）超時(shí)最多，產(chǎn)品中心的超時(shí)相對(duì)較少，這是因?yàn)槲覀兿到y(tǒng)針對(duì)產(chǎn)品中心的部分接口做了兜底處理，當(dāng)超時(shí)發(fā)生時(shí)后先查緩存，如果緩存查不到會(huì)穿透調(diào)用一個(gè)離線信息緩存系統(tǒng)，因此產(chǎn)品中心超時(shí)總體較少。

綜合上述三個(gè)實(shí)驗(yàn)得出結(jié)果，算法對(duì)于報(bào)警日志的泛化是具有一定效果。在所進(jìn)行實(shí)驗(yàn)的三個(gè)場(chǎng)景中，均能夠定位到關(guān)鍵問題。但是依然存在一些不足，報(bào)警摘要中，有的經(jīng)過泛化的信息過于籠統(tǒng)（比如Other Exception）。

經(jīng)過分析，我們發(fā)現(xiàn)主要的原因有：其一，對(duì)于錯(cuò)誤信息中關(guān)鍵字段的提取，在一定程度上決定了向上泛化的準(zhǔn)確度。其二，系統(tǒng)本身日志設(shè)計(jì)存在一定的局限性。

同時(shí)，在利用這個(gè)泛化后的報(bào)警摘要進(jìn)行分析時(shí)，需要使用者具備相應(yīng)領(lǐng)域的知識(shí)。

本文所關(guān)注的工作，主要在于驗(yàn)證聚類算法效果，還有一些方向可以繼續(xù)完善和優(yōu)化：

日志內(nèi)容的深度分析。本文僅對(duì)報(bào)警日志做了簡(jiǎn)單的關(guān)鍵字提取和人工標(biāo)記，未涉及太多文本分析的內(nèi)容。我們可以通過使用文本分類、文本特征向量相似度等，提高日志內(nèi)容分析的準(zhǔn)確度，提升泛化效果。

多種聚類算法綜合使用。本文僅探討了處理系統(tǒng)錯(cuò)誤日志時(shí)表現(xiàn)較好的聚類算法，針對(duì)系統(tǒng)中多種不同類型的報(bào)警，未來也可以配合其他聚類算法（如K-Means）共同對(duì)報(bào)警進(jìn)行處理，優(yōu)化聚合效果。

自適應(yīng)報(bào)警閾值。除了對(duì)報(bào)警聚類，我們還可以通過對(duì)監(jiān)控指標(biāo)的時(shí)序分析，動(dòng)態(tài)管理報(bào)警閾值，提高告警的質(zhì)量和及時(shí)性，減少誤報(bào)和漏告數(shù)量。

Julisch, Klaus. "Clustering intrusion detection alarms to support root cause analysis." ACM transactions on information and system security (TISSEC) 6.4 (2003): 443-471.

https://en.wikipedia.org/wiki...

劉玚，美團(tuán)點(diǎn)評(píng)后端工程師。2017 年加入美團(tuán)點(diǎn)評(píng)，負(fù)責(zé)美團(tuán)點(diǎn)評(píng)境內(nèi)度假的業(yè)務(wù)開發(fā)。

千釗，美團(tuán)點(diǎn)評(píng)后端工程師。2017 年加入美團(tuán)點(diǎn)評(píng)，負(fù)責(zé)美團(tuán)點(diǎn)評(píng)境內(nèi)度假的業(yè)務(wù)開發(fā)。