復(fù)雜場景下基于規(guī)則引擎的監(jiān)控告警收斂算法

上海浦東發(fā)展銀行 徐衛(wèi)

監(jiān)控告警系統(tǒng)作為數(shù)據(jù)中心運(yùn)維之眼，良好的監(jiān)控告警系統(tǒng)幫助運(yùn)維人員快速發(fā)現(xiàn)定位問題，提高故障處理速度，減輕運(yùn)維工作的壓力。一般場景下，為了實現(xiàn)告警收斂，運(yùn)維人員在監(jiān)控告警系統(tǒng)服務(wù)端預(yù)埋靜態(tài)規(guī)則，維護(hù)海量的規(guī)則探針。在復(fù)雜場景下，如果繼續(xù)沿用這種方法，由于系統(tǒng)缺少先決知識庫，收斂效果會折扣。為了解決該問題，本文研究發(fā)現(xiàn)受控節(jié)點機(jī)器上的agent-Plugins 插件有可編輯、可彈性擴(kuò)展的特點，根據(jù)場景需要下發(fā)特定場景的業(yè)務(wù)處理腳本，從而在場景執(zhí)行中動態(tài)產(chǎn)生收斂規(guī)則。兼顧高靈活性、容易掌控、可重用性的需求，引入Java 成熟的規(guī)則引擎Drools 實現(xiàn)海量收斂規(guī)則快速匹配，實現(xiàn)告警的快速收斂的能力。在筆者維護(hù)的生產(chǎn)系統(tǒng)中引入該算法，并付諸技術(shù)實現(xiàn)。全文跟蹤浦發(fā)銀行數(shù)據(jù)中心2021 年1 ～12 月生產(chǎn)脫敏告警數(shù)據(jù)，并從多評價維度檢驗算法投入前后的告警收斂效果。從實驗數(shù)據(jù)看，新算法適用浦發(fā)銀行數(shù)據(jù)中心的多種運(yùn)維應(yīng)用場景，有著廣泛的應(yīng)用前景。

隨著移動互聯(lián)的發(fā)展，IT 網(wǎng)絡(luò)基礎(chǔ)設(shè)施維護(hù)和管理成本的與日俱增，面對隨時可能發(fā)生的各類商業(yè)應(yīng)用活動、網(wǎng)絡(luò)服務(wù)故障，運(yùn)維監(jiān)控系統(tǒng)已逐漸覆蓋各大金融機(jī)構(gòu)和互聯(lián)網(wǎng)企業(yè)。爆發(fā)式增長的應(yīng)用、網(wǎng)絡(luò)服務(wù)致使運(yùn)維監(jiān)控系統(tǒng)的告警數(shù)量增長迅速，這給移動金融產(chǎn)品的可用性、可靠性和用戶體驗帶來巨大挑戰(zhàn)。運(yùn)維監(jiān)控系統(tǒng)已成為產(chǎn)品可用性和良好用戶體驗的有力保證，并對留存用戶、保證用戶權(quán)益、保證企業(yè)收益和維護(hù)企業(yè)品牌有著重要的意義。

告警收斂是運(yùn)維監(jiān)控領(lǐng)域的重要研究方向，一個監(jiān)控指標(biāo)的變化可能觸發(fā)告警的蝴蝶效應(yīng)，引發(fā)重大告警風(fēng)暴，給運(yùn)維管理員帶來嚴(yán)重災(zāi)難。如何實現(xiàn)告警收斂，已經(jīng)成為擺在金融科技運(yùn)維從業(yè)人員面前較緊迫的研究任務(wù)。

1 算法改進(jìn)點

為了實現(xiàn)告警收斂，同業(yè)的監(jiān)控系統(tǒng)一般采取在監(jiān)控系統(tǒng)的服務(wù)端預(yù)埋規(guī)則，包括組合業(yè)務(wù)風(fēng)暴窗口，告警指標(biāo)，告警連續(xù)峰值次數(shù)判斷等維度，減少告警量，從而實現(xiàn)告警收斂。

一般場景下，在監(jiān)控系統(tǒng)的服務(wù)端預(yù)埋配置規(guī)則，簡單直觀，容易管理。但是，近年來隨著移動互聯(lián)網(wǎng)崛起，在商戶營銷、手機(jī)權(quán)益、紅包秒殺等復(fù)雜業(yè)務(wù)場景下，對于運(yùn)維管理員提出更高的要求，需要應(yīng)用運(yùn)維管理員配置“大而重”的規(guī)則，有時甚至二次開發(fā)，管理員工作重心太多放到預(yù)埋規(guī)則的配置和個性化維護(hù)上。筆者分析，預(yù)埋規(guī)則面臨很多技術(shù)挑如下，為了簡化表述，這里算法名取名“老算法”。

（1）預(yù)埋規(guī)則難以找到平衡點。預(yù)埋規(guī)則粒度較粗可能帶來大量的冗余告警，粒度較細(xì)可能造成運(yùn)維人員維護(hù)量較大。

（2）預(yù)埋規(guī)則對于后續(xù)的告警根因分析中數(shù)據(jù)不完整。完成一筆業(yè)務(wù)可能需要橫跨多個應(yīng)用系統(tǒng)，應(yīng)用鏈路上每個IT 單元出現(xiàn)問題都會引發(fā)業(yè)務(wù)故障，強(qiáng)制放棄鏈路中的某個IT 單元數(shù)據(jù)可能造成最終分析來源數(shù)據(jù)不完整。

（3）預(yù)埋規(guī)則內(nèi)生沖突。規(guī)則之間存在數(shù)據(jù)重疊度和業(yè)務(wù)沖突，無法通過技術(shù)校驗，最終發(fā)生無需收斂的反而收斂，需要收斂的未收斂的情況。

（4）預(yù)埋規(guī)則維護(hù)工作量較大。隨著數(shù)字業(yè)務(wù)擴(kuò)展，服務(wù)器數(shù)量迅速增長，對于服務(wù)器的各類預(yù)埋規(guī)則的維護(hù)將同步增長。運(yùn)維人員投入、硬件內(nèi)存開銷都不小。

為了幫助運(yùn)維管理員降低配置維護(hù)工作量，本文經(jīng)過研究發(fā)現(xiàn)，挖掘受控節(jié)點機(jī)器上的agent-Plugins 插件有可編輯、可彈性擴(kuò)展的特點，當(dāng)受控節(jié)點有重大變更行為的時候（比如數(shù)據(jù)庫HA 切換，發(fā)起重大跑批任務(wù)），agent-Plugins 將事件組裝成標(biāo)準(zhǔn)報文，以接口調(diào)用的方式發(fā)送消息監(jiān)控系統(tǒng)的服務(wù)端，從而確保服務(wù)端感知變化，形成動態(tài)規(guī)則從而實現(xiàn)后續(xù)告警的進(jìn)一步收斂。這種策略將原先集中于監(jiān)控系統(tǒng)服務(wù)端靜態(tài)規(guī)則配置并匹配的任務(wù)進(jìn)行分而治之，由分布式的受控節(jié)點側(cè)的agent-Plugins 并行完成，對傳統(tǒng)的預(yù)埋配置規(guī)則的方案有較大程度改善，為了簡化表述，這里算法名取名“新算法”，主要優(yōu)勢如下。

（1）利用受控節(jié)點主動上報自身狀態(tài)，在復(fù)雜場景下提高了收斂精準(zhǔn)率；（2）利用受控節(jié)點間關(guān)聯(lián)拓?fù)潢P(guān)系提高告警收斂效率，降低不必要的告警消息；（3）利用報文接口通用的技術(shù)優(yōu)勢，滿足受控節(jié)點上報自身狀態(tài)接口開發(fā)符合語言門檻多樣性的需求；（4）利用受控節(jié)點上報自身狀態(tài)的數(shù)據(jù)大集中優(yōu)勢，經(jīng)過機(jī)器學(xué)習(xí)，可一定程度上豐富服務(wù)端預(yù)埋規(guī)則庫，提高后續(xù)告警收斂的精準(zhǔn)率。

對新、老算法進(jìn)行理論上的比較，包括收斂規(guī)則匹配時間復(fù)雜度、規(guī)則維護(hù)時間復(fù)雜度、復(fù)雜場景支持。假設(shè)監(jiān)控節(jié)點數(shù)量為n，老算法采用規(guī)則逐筆匹配，因此匹配時間復(fù)雜度為O(n), 新算法的規(guī)則引擎底層算法是平衡二叉排序樹算法，因此n 個節(jié)點的二叉排序樹的高度為log(n+1)，匹配時間復(fù)雜度為O(logn)。注：從時間復(fù)雜度表達(dá)式進(jìn)行比較，無具體計量單位。詳細(xì)如表1 所示。

表1 兩種算法的指標(biāo)比較分析表Tab.1 Comparison and analysis of indicators of the two algorithms

2 算法框架流程

本文算法提到的規(guī)則引擎采用Java 版的開源規(guī)則引擎，適用Rete 算法對所寫的規(guī)則求值。為了詳細(xì)闡述算法框架流程，這里用流程圖方式表述（如圖1 所示）。

圖1 收斂算法規(guī)則引擎推理架構(gòu)圖Fig.1 Reasoning architecture of convergence algorithm rule engine

規(guī)則引擎推理步驟如下：

（1）管理員通過平臺向受控節(jié)點下發(fā)agent-Plugins插件，專用于特定業(yè)務(wù)場景；（2）受控節(jié)點特定業(yè)務(wù)場景開始時，向監(jiān)控系統(tǒng)（服務(wù)端）發(fā)送通知報文，用于表明節(jié)點狀態(tài)或事件；（3）監(jiān)控系統(tǒng)（服務(wù)端）調(diào)用規(guī)則引擎的External Component 組件，重新建告警收斂規(guī)則；（4）規(guī)則引擎更新規(guī)則庫（Rules Repository）；（5）監(jiān)控系統(tǒng)（服務(wù)端）產(chǎn)生告警，通過獨立通道上報告警消息；（6）將初始數(shù)據(jù)(Fact)輸入到工作內(nèi)存模塊（Working Memory）；（7）適用Pattern Matcher 匹配器將規(guī)則庫(Rules Repository)的規(guī)則(Rule)和數(shù)據(jù)(Fact)比較；（8）如果執(zhí)行規(guī)則存在沖突（Conflict）,同時激活了多個規(guī)則，將沖突的規(guī)則放入沖突集合；（9）解決沖突，將激活的規(guī)則有序存入Agenda；（10）執(zhí)行Agenda 的規(guī)則；（11）重復(fù)（7）～（10），直到執(zhí)行完畢Agenda 的所有規(guī)則。

3 實驗數(shù)據(jù)

本文以浦發(fā)數(shù)據(jù)中心原始脫敏告警數(shù)據(jù)為研究對象，數(shù)據(jù)時間分布為2021 年1 ～6 月，7 ～12 月（注：手工剔除新增業(yè)務(wù)、投產(chǎn)服務(wù)器帶來的告警數(shù)），并從日均告警量（如圖2 所示，橫坐標(biāo)表示月份，其中7 ～12 月份采用新算法，1 ～6 月份采用老算法，縱坐標(biāo)標(biāo)識日均告警筆數(shù)），日均電話通知告警量（如圖3 所示，橫坐標(biāo)表示月份，其中7 ～12 月份采用新算法，1 ～6 月份采用老算法，縱坐標(biāo)標(biāo)識日均通知電話通數(shù)）兩個統(tǒng)計維度進(jìn)行比對，以下是實驗數(shù)據(jù)柱狀圖。

圖2 單位月內(nèi)日均告警量（以“萬筆”計，保留2 位小數(shù)）Fig.2 Average daily alarm volume per unit month (calculated by "10000 strokes", with 2 decimal places reserved)

圖3 單位月內(nèi)日均電話通知量（以“通”計）Fig.3 Average daily telephone notification volume per unit month (calculated by "communication")

為了進(jìn)行數(shù)據(jù)分析，對周期內(nèi)（半年）日均電話通知量平均值、日均告警量平均值演算過程如表2 所示。

表2 數(shù)據(jù)計算過程表Tab.2 Data calculation process

從計算統(tǒng)計結(jié)果看，考慮到統(tǒng)計學(xué)中的可接受誤差5%，得到單位月內(nèi)日均告警量下降15%～20%，單位月內(nèi)日均電話量下降30%～35%。

從7 ～12 月數(shù)據(jù)看，由于11/12 月接近年底，商家營銷活動越來越多，發(fā)卡銀行的持卡人消費(fèi)行為升級，恰逢雙十一保障、年終大促、年終跨年結(jié)算等機(jī)構(gòu)側(cè)的重要工作安排，對于帶來的告警如果繼續(xù)沿用老算法對于一線運(yùn)維管理員將是“海陸空”全方位轟炸，引入新算法后在監(jiān)控系統(tǒng)服務(wù)側(cè)動態(tài)產(chǎn)生自定義抑制規(guī)則，實現(xiàn)告警收斂，運(yùn)維管理員收到的實時電話告警量下降明顯。

由于agent-Plugins 有著強(qiáng)大的可編輯能力，自定義插件可以橫向擴(kuò)展，彈性較強(qiáng)，且對于插件的開發(fā)語言選擇上并沒有過多硬性要求，推薦使用Python/Shell/C/Go/Java，且引入了成熟的規(guī)則引擎框架Drools，保障了處理性能，因此上述應(yīng)用算法有著廣闊的應(yīng)用前景，給一線運(yùn)維管理員帶來福音。

4 結(jié)語

隨著信息化高速發(fā)展，國內(nèi)外各大互聯(lián)網(wǎng)機(jī)構(gòu)均自主研發(fā)部署高度集成化、先進(jìn)性、安全性、開放性、可擴(kuò)展性、高效性和高可靠的運(yùn)維監(jiān)控系統(tǒng)，近年來國內(nèi)傳統(tǒng)金融企業(yè)啟動數(shù)字化轉(zhuǎn)型，并開始大規(guī)模的“新基建”建設(shè)，當(dāng)網(wǎng)絡(luò)、設(shè)備、服務(wù)發(fā)生異常時，運(yùn)維監(jiān)控系統(tǒng)勢必會產(chǎn)生大量的告警信息，增加了網(wǎng)絡(luò)運(yùn)維的壓力，降低了運(yùn)維工作者的幸福感，因此告警收斂包括后續(xù)對告警信息的分析、合并和丟棄在實際運(yùn)維工作中顯得尤為關(guān)鍵。

目前告警收斂的方法具有多維度、多方案的特點，任何一種單一的告警收斂方法都具有自身的局限性，實際運(yùn)維場景需要兼顧算法效率、系統(tǒng)維護(hù)復(fù)雜度和實際情形，告警收斂領(lǐng)域具有很大的研究潛力。

告警收斂是不斷豐富發(fā)展的，本文提出的基于agent-Plugins 可編輯能力，并引入了規(guī)則引擎實現(xiàn)告警收斂就是一種有益的探索，目前應(yīng)用于企業(yè)內(nèi)的年終結(jié)算場景，日常數(shù)據(jù)庫HA 切換，雙11 紅包活動峰值場景，已經(jīng)顯示出一定的效果。后續(xù)研發(fā)團(tuán)隊將探索引入大數(shù)據(jù)等優(yōu)秀的智能算法，進(jìn)一步實現(xiàn)場景告警收斂，提高一線運(yùn)維工作者的獲得感，實現(xiàn)運(yùn)維工作的人性化目標(biāo)，為金融企業(yè)的數(shù)字化轉(zhuǎn)型做貢獻(xiàn)。

引用

[1] 邢村.論監(jiān)控中心典型的異常告警及事故處理方法[J].中國科技縱橫,2016(19):169-170.

[2] 馬小波,柴宗弘.一種告警監(jiān)控系統(tǒng)及方法:中國,CN20151076 1866.9[P].2016-03-23.

[3] 國悅婷.運(yùn)維監(jiān)控系統(tǒng)告警收斂的算法研究與應(yīng)用[D].武漢:華中科技大學(xué),2017.

[4] 錢雁.IDC網(wǎng)絡(luò)監(jiān)控系統(tǒng)告警有效性提升研究[J].電信技術(shù), 2016(1):51-54.

[5] 張驍睿,劉曉茹.一種應(yīng)用于通信行業(yè)實現(xiàn)告警同步和清除機(jī)制的方法:中國,CN201911050574.9[P].2020-05-12..