国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

根因分析初探:一種報警聚類算法在業務系統的落地實施

Loong_T / 1096人閱讀

摘要:圍繞上面描述的問題,以及對于報警聚類處理的分析假設,本文主要做了以下事情選定聚類算法,簡單描述了算法的基本原理,并給出了針對報警日志聚類的一種具體的實現方案。算法選擇聚類算法采用論文中描述的根因分析算法。聚類算法算法的執行,我們以圖來表示。

背景

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

錯誤日志是系統報警的一種,實際生產中,運維人員能夠收到的報警信息多種多樣。如果在報警流出現的時候,通過處理程序,將報警進行聚類,整理出一段時間內的報警摘要,那么運維人員就可以在摘要信息的幫助下,先對當前的故障有一個大致的輪廓,再結合技術知識與業務知識定位故障的根本原因。

圍繞上面描述的問題,以及對于報警聚類處理的分析假設,本文主要做了以下事情:

選定聚類算法,簡單描述了算法的基本原理,并給出了針對報警日志聚類的一種具體的實現方案。

在分布式業務服務的系統下構造了三種不同實驗場景,驗證了算法的效果,并且對算法的不足進行分析闡述。

目標

對一段時間內的報警進行聚類處理,將具有相同根因的報警歸納為能夠涵蓋報警內容的泛化報警(Generalized Alarms),最終形成僅有幾條泛化報警的報警摘要。如下圖1所示意。

我們希望這些泛化報警既要具有很強的概括性,同時盡可能地保留細節。這樣運維人員在收到報警時,便能快速定位到故障的大致方向,從而提高故障排查的效率。

設計

如圖2所示,異常報警根因分析的設計大致分為四個部分:收集報警信息、提取報警信息的關鍵特征、聚類處理、展示報警摘要。

算法選擇

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

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.

我們可以將這幾條報警抽象為:“全部服務器 網絡調用 故障”,該泛化報警包含的范圍較廣;也可以抽象為:“server_room_a服務器 網絡調用 產品信息獲取失敗”和“server_room_b服務器 RPC 獲取產品類型信息失敗”,此時包含的范圍較小。當然也可以用其他層次的抽象來表達這個報警集群。

我們可以觀察到,抽象層次越高,細節越少,但是它能包含的范圍就越大;反之,抽象層次越低,則可能無用信息越多,包含的范圍就越小。

這種抽象的層次關系可以用一些有向無環圖(DAG)來表達,如圖3所示:

為了確定報警聚類泛化的程度,我們需要先了解一些定義:

屬性(Attribute):構成報警日志的某一類信息,如機器、環境、時間等,文中用Ai表示。

值域(Domain):屬性Ai的域(即取值范圍),文中用Dom(Ai)表示。

泛化層次結構(Generalization Hierarchy):對于每個Ai都有一個對應的泛化層次結構,文中用Gi表示。

不相似度(Dissimilarity):定義為d(a1, a2)。它接受兩個報警a1、a2作為輸入,并返回一個數值量,表示這兩個報警不相似的程度。與相似度相反,當d(a1, a2)較小時,表示報警a1和報警a2相似。為了計算不相似度,需要用戶定義泛化層次結構。

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

對于兩個報警a1、a2,其計算方式為:

例如: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", "服務器") + d("server_room_a-biz_tag-online01", "服務器") + d("RPC", "Thrift") + d("RPC", "Pigeon") = 2 + 2 + 1 + 1 = 6。

我們用C表示報警集合,g是C的一個泛化表示,即滿足? a ∈ C, a ? g。以報警集合{"dx-trip-package-api02 Thrift get deal list error.", "dx-trip-package-api01 Thrift get deal list error."}為例,“dx服務器 thrift調用 獲取產品信息失敗”是一個泛化表示,“服務器 網絡調用 獲取產品信息失敗”也是一個泛化表示。對于某個報警聚類來說,我們希望獲得既能夠涵蓋它的集合又有最具象化的表達的泛化表示。為了解決這個問題,定義以下兩個指標:

H(C)值最小時對應的g,就是我們要找的最適合的泛化表示,我們稱g為C的“覆蓋”(Cover)。

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

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

算法描述

算法假設所有的泛化層次結構Gi都是樹,這樣每個報警集群都有一個唯一的、最頂層的泛化結果。

將L定義為一個原始的報警日志集合,算法選擇一個屬性Ai,將L中所有報警的Ai值替換為Gi中Ai的父值,通過這一操作不斷對報警進行泛化。

持續步驟2的操作,直到找到一個覆蓋報警數量大于min_size的泛化報警為止。

輸出步驟3中找到的報警。

算法偽代碼如下所示:

輸入:報警日志集合L,min_size,每個屬性的泛化層次結構G1,......,Gn
輸出:所有符合條件的泛化報警
T := L;              // 將報警日志集合保存至表T
for all alarms a in T do
    a[count] := 1;   // "count"屬性用于記錄a當前覆蓋的報警數量
while ?a ∈ T : a[count] < min_size do {
    使用啟發算法選擇一個屬性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行的啟發算法為:

首先計算Ai對應的Fi
fi(v) := SELECT sum(count) FROM T WHERE Ai = v   // 統計在Ai屬性上值為v的報警的數量
Fi := max{fi(v) | v ∈ Dom(Ai)}
選擇Fi值最小的屬性Ai

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

此外,關于min_size的選擇,如果選擇了一個過大的min_size,那么會迫使算法合并具有不同根源的報警。另一方面,如果過小,那么聚類可能會提前結束,具有相同根源的報警可能會出現在不同的聚類中。

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

需要注意的是,?-魯棒性與特定的報警日志相關。因此,給定的最小值,可能相對于一個報警日志來說是魯棒的,而對于另一個報警日志來說是不魯棒的。

實現 1. 提取報警特征

根據線上問題排查的經驗,運維人員通常關注的指標包括時間、機器(機房、環境)、異常來源、報警日志文本提示、故障所在位置(代碼行數、接口、類)、Case相關的特殊ID(訂單號、產品編號、用戶ID等等)等。

但是,我們的實際應用場景都是線上準實時場景,時間間隔比較短,因此我們不需要關注時間。同時,Case相關的特殊ID不符合我們希望獲得一個抽象描述的要求,因此也無需關注此項指標。

綜上,我們選擇的特征包括:機房、環境、異常來源、報警日志文本關鍵內容、故障所在位置(接口、類)共5個。

2. 算法實現

(1) 提取關鍵特征

我們的數據來源是日志中心已經格式化過的報警日志信息,這些信息主要包含:報警日志產生的時間、服務標記、在代碼中的位置、日志內容等。

故障所在位置

優先查找是否有異常堆棧,如存在則查找第一個本地代碼的位置;如果不存在,則取日志打印位置。

異常來源

獲得故障所在位置后,優先使用此信息確定異常報警的來源(需要預先定義詞典支持);如不能獲取,則在日志內容中根據關鍵字匹配(需要預先定義詞典支持)。

報警日志文本關鍵內容

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

提取“機房和環境”這兩個指標比較簡單,在此不做贅述。

(2) 聚類算法

算法的執行,我們以圖4來表示。

(3) min_size 選擇

考慮到日志數據中可能包含種類極多,且根據小規模數據實驗表明,min_size = 1/5 報警日志數量時,算法已經有較好的表現,再高會增加過度聚合的風險,因此我們取min_size = 1/5 報警日志數量,?參考論文中的實驗,取0.05。

(4) 聚類停止條件

考慮到部分場景下,報警日志可能較少,因此min_size的值也較少,此時聚類已無太大意義,因此設定聚類停止條件為:聚類結果的報警摘要數量小于等于20或已經存在某個類別的count值達到min_size的閾值,即停止聚類。

3. 泛化層次結構

泛化層次結構,用于記錄屬性的泛化關系,是泛化時向上抽象的依據,需要預先定義。

根據實驗所用項目的實際使用環境,我們定義的泛化層次結構如下:

“故障所在位置”此屬性無需泛化層次結構,每次泛化時直接按照包路徑向上層截斷,直到系統包名。

實驗

以下三個實驗均使用C端API系統。

1. 單依賴故障

實驗材料來自于線上某業務系統真實故障時所產生的大量報警日志。

環境:線上

故障原因:產品中心線上單機故障

報警日志數量:939條

部分原始報警日志如圖9所示,初次觀察時,很難理出頭緒。

經過聚類后的報警摘要如表1所示:

ID Server Room Error Source Environment Position (為保證數據安全,類路徑已做處理) Summary (為保證數據安全,部分類路徑已做處理) Count
1 所有機房 產品中心 Prod com.*.*.*.CommonProductQueryClient com.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getProductType execution timeout after waiting for 150ms. 249
2 所有機房 業務插件 Prod com.*.*.*.PluginRegistry.lambda java.lang.IllegalArgumentException: 未找到業務插件:所有產品類型 240
3 所有機房 產品中心 Prod com.*.*.*.TrProductQueryClient com.netflix.hystrix.exception.HystrixTimeoutException: TrQueryClient.listTrByDids2C execution timeout after waiting for 1000ms. 145
4 所有機房 對外接口(猜喜/貨架/目的地) Prod com.*.*.*.RemoteDealServiceImpl com.netflix.hystrix.exception.HystrixTimeoutException: ScenicDealList.listDealsByScenic execution timeout after waiting for 300ms. 89
5 所有機房 產品中心 Prod com.*.*.*.CommonProductQueryClient com.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.listTrByDids2C execution timeout after waiting for 1000ms. 29
6 所有機房 產品中心 Prod com.*.*.*.ActivityQueryClientImpl com.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms. 21
7 所有機房 產品中心 prod com.*.*.*.CommonProductQueryClient com.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms. 21
8 所有機房 對外接口(猜喜/貨架/目的地) Prod com.*.*.*.RemoteDealServiceImpl com.netflix.hystrix.exception.HystrixTimeoutException: HotelDealList.hotelShelf execution timeout after waiting for 500ms. 17
9 所有機房 產品中心 Prod com.*.*.*.TrProductQueryClient Caused by: java.lang.InterruptedException 16
10 所有機房 產品中心 Prod com.*.*.*.TrProductQueryClient Caused by: java.lang.InterruptedException 13

我們可以看到前三條報警摘要的Count遠超其他報警摘要,并且它們指明了故障主要發生在產品中心的接口。

2. 無相關的多依賴同時故障

實驗材料為利用故障注入工具,在Staging環境模擬運營置頂服務和A/B測試服務同時產生故障的場景。

環境:Staging(使用線上錄制流量和壓測平臺模擬線上正常流量環境)

模擬故障原因:置頂與A/B測試接口大量超時

報警日志數量:527條

部分原始報警日志如圖10所示:

經過聚類后的報警摘要如表2所示:

ID Server Room Error Source Environment Position (為保證數據安全,類路徑已做處理) Summary (為保證數據安全,部分類路徑已做處理) Count
1 所有機房 運營活動 Staging com.*.*.*.ActivityQueryClientImpl [hystrix]置頂失敗, circuit short is open 291
2 所有機房 A/B測試 Staging com.*.*.*.AbExperimentClient [hystrix] tripExperiment error, circuit short is open 105
3 所有機房 緩存 Staging com.*.*.*.CacheClientFacade com.netflix.hystrix.exception.HystrixTimeoutException: c-cache-rpc.common_deal_base.rpc execution timeout after waiting for 1000ms. 15
4 所有機房 產品信息 Staging com.*.*.*.queryDealModel Caused by: com.meituan.service.mobile.mtthrift.netty.exception.RequestTimeoutException: request timeout 14
5 所有機房 產品中心 Staging com.*.*.*.CommonProductQueryClient com.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms. 9
6 所有機房 產品中心 Staging com.*.*.*.getOrderForm java.lang.IllegalArgumentException: 產品無庫存 7
7 所有機房 彈性工程 Staging com.*.*.*.PreSaleChatClient com.netflix.hystrix.exception.HystrixTimeoutException: CustomerService.PreSaleChat execution timeout after waiting for 50ms. 7
8 所有機房 緩存 Staging com.*.*.*.SpringCacheManager Caused by: java.net.SocketTimeoutException: Read timed out 7
9 所有機房 產品信息 Staging com.*.*.*.queryDetailUrlVO java.lang.IllegalArgumentException: 未知的產品類型 2
10 所有機房 產品信息 Staging com.*.*.*.queryDetailUrlVO java.lang.IllegalArgumentException: 無法獲取鏈接地址 1

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

3. 中間件與相關依賴同時故障

實驗材料為利用故障注入工具,在Staging環境模擬產品中心服務和緩存服務同時產生超時故障的場景。

環境:Staging(使用線上錄制流量和壓測平臺模擬線上正常流量環境)

模擬故障原因:產品中心所有接口超時,所有緩存服務超時

報警日志數量:2165

部分原始報警日志如圖11所示:

經過聚類后的報警摘要如表3所示:

ID Server Room Error Source Environment Position (為保證數據安全,類路徑已做處理) Summary (為保證數據安全,部分類路徑已做處理) Count
1 所有機房 Squirrel Staging com.*.*.*.cache Timeout 491
2 所有機房 Cellar Staging com.*.*.*.cache Timeout 285
3 所有機房 Squirrel Staging com.*.*.*.TdcServiceImpl Other Exception 149
4 所有機房 評論 Staging com.*.*.*.cache Timeout 147
5 所有機房 Cellar Staging com.*.*.*.TdcServiceImpl Other Exception 143
6 所有機房 Squirrel Staging com.*.*.*.PoiManagerImpl 熔斷 112
7 所有機房 產品中心 Staging com.*.*.*.CommonProductQueryClient Other Exception 89
8 所有機房 評論 Staging com.*.*.*.TrDealProcessor Other Exception 83
9 所有機房 評論 Staging com.*.*.*.poi.PoiInfoImpl Other Exception 82
10 所有機房 產品中心 Staging com.*.*.*.client Timeout 74

從上表可以看到,緩存(Squirrel和Cellar雙緩存)超時最多,產品中心的超時相對較少,這是因為我們系統針對產品中心的部分接口做了兜底處理,當超時發生時后先查緩存,如果緩存查不到會穿透調用一個離線信息緩存系統,因此產品中心超時總體較少。

綜合上述三個實驗得出結果,算法對于報警日志的泛化是具有一定效果。在所進行實驗的三個場景中,均能夠定位到關鍵問題。但是依然存在一些不足,報警摘要中,有的經過泛化的信息過于籠統(比如Other Exception)。

經過分析,我們發現主要的原因有:其一,對于錯誤信息中關鍵字段的提取,在一定程度上決定了向上泛化的準確度。其二,系統本身日志設計存在一定的局限性。

同時,在利用這個泛化后的報警摘要進行分析時,需要使用者具備相應領域的知識。

未來規劃

本文所關注的工作,主要在于驗證聚類算法效果,還有一些方向可以繼續完善和優化:

日志內容的深度分析。本文僅對報警日志做了簡單的關鍵字提取和人工標記,未涉及太多文本分析的內容。我們可以通過使用文本分類、文本特征向量相似度等,提高日志內容分析的準確度,提升泛化效果。

多種聚類算法綜合使用。本文僅探討了處理系統錯誤日志時表現較好的聚類算法,針對系統中多種不同類型的報警,未來也可以配合其他聚類算法(如K-Means)共同對報警進行處理,優化聚合效果。

自適應報警閾值。除了對報警聚類,我們還可以通過對監控指標的時序分析,動態管理報警閾值,提高告警的質量和及時性,減少誤報和漏告數量。

參考資料

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...

作者簡介

劉玚,美團點評后端工程師。2017 年加入美團點評,負責美團點評境內度假的業務開發。

千釗,美團點評后端工程師。2017 年加入美團點評,負責美團點評境內度假的業務開發。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/8113.html

相關文章

  • 清華裴丹:AIOps 落地路線圖

    摘要:從那個時候開始,我就開始用一些機器學習人工智能的技術來解決的運維問題了,有不少智能運維的嘗試,并發表了不少先關論文和專利。而處理海量高速多樣的數據并產生高價值,正是機器學習的專長。也就是說,采用機器學習技術是運維的一個必然的走向。 大家上午好,非常榮幸,能有這個機會,跟這么多的運維人一起交流智能運維。最近這兩年運維里面有一個很火的一個詞叫做AIOps(智能運維)。我本人是老運維了,在2000...

    Aomine 評論0 收藏0
  • 阿里巴巴智能監控新場景探索

    摘要:摘要智能監控是智能運維的子領域,詳細分析。我和我的團隊在阿里內部的分工是橫向去看阿里巴巴業務指標的監控,我們就以這個話題展開。分享分為五個環節,從阿里巴巴不同的業態,特別是新的業態帶來的挑戰講起。 摘要:?智能監控是智能運維的子領域,詳細分析。 showImg(https://segmentfault.com/img/remote/1460000017348788); 作者簡介 王肇...

    wwq0327 評論0 收藏0
  • AI中臺:一種敏捷智能業務支持方案|宜信技術學院沙龍分享實錄

    摘要:因此數據中臺必須具備智能化能力,能夠為業務提供一定的智能數據分析能力。宜信作為一家金融科技公司,更多面對的是金融領域的智能業務需求。 showImg(https://segmentfault.com/img/bVbqQM0?w=1155&h=492); 內容來源:宜信技術學院第1期技術沙龍-線上直播|AI中臺:一種敏捷的智能業務支持方案 主講人介紹:井玉欣 宜信技術研發中心AI應用團隊...

    makeFoxPlay 評論0 收藏0
  • AI遇見SIEM,白山ATD革新企業安全大腦

    摘要:然而在中國,還處于比較初級的階段,很多企業對自身安全問題并沒有系統性的管理。年整個中國市場只有億人民幣的規模,這個數字相比中國經濟對全球經濟的占比是不相符的。 showImg(https://segmentfault.com/img/bV9xRN?w=865&h=950);作者簡介: 叢磊,白山合伙人兼工程副總裁2016年加入白山,主要負責云聚合產品的研發管理和云鏈產品體系構建等。20...

    gself 評論0 收藏0
  • AI遇見SIEM,白山ATD革新企業安全大腦

    摘要:然而在中國,還處于比較初級的階段,很多企業對自身安全問題并沒有系統性的管理。年整個中國市場只有億人民幣的規模,這個數字相比中國經濟對全球經濟的占比是不相符的。 showImg(https://segmentfault.com/img/bV9xRN?w=865&h=950);作者簡介: 叢磊,白山合伙人兼工程副總裁2016年加入白山,主要負責云聚合產品的研發管理和云鏈產品體系構建等。20...

    leanote 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<