作者簡(jiǎn)介：周偉 百度高級(jí)研發(fā)工程師
負(fù)責(zé)百度智能運(yùn)維（Noah）監(jiān)控報(bào)警系統(tǒng)、通告平臺(tái)；在精準(zhǔn)報(bào)警、精準(zhǔn)通告、報(bào)警收斂、公/私有云監(jiān)控等方向具有廣泛的實(shí)踐經(jīng)驗(yàn)。

干貨概覽

監(jiān)控報(bào)警是故障發(fā)現(xiàn)的重要一環(huán)，也是百度在AIOps的最早切入方向之一，目前百度AIOps在監(jiān)控報(bào)警方面已經(jīng)有兩個(gè)場(chǎng)景取得突出效果：智能異常檢測(cè)和智能報(bào)警合并。

如何支撐AIOps算法在監(jiān)控報(bào)警系統(tǒng)的快速落地并產(chǎn)生業(yè)務(wù)價(jià)值，這對(duì)監(jiān)控報(bào)警架構(gòu)提出了很大的挑戰(zhàn)！在上篇《AIOps對(duì)監(jiān)控報(bào)警架構(gòu)的挑戰(zhàn)》文章中，我們介紹了監(jiān)控報(bào)警系統(tǒng)在故障處理流程中的位置（故障發(fā)現(xiàn)和故障通告），并且分析了AIOps對(duì)監(jiān)控報(bào)警架構(gòu)的三個(gè)挑戰(zhàn)。在本篇，我們將詳細(xì)介紹應(yīng)對(duì)這三個(gè)挑戰(zhàn)的方案：

• 為了應(yīng)對(duì)挑戰(zhàn)一，我們研發(fā)了策略運(yùn)行平臺(tái)，讓AIOps算法迭代找到飛一般的感覺。
• 為了應(yīng)對(duì)挑戰(zhàn)二，我們提出了基于狀態(tài)機(jī)的事件管理引擎，讓事件管理so easy。
• 為了應(yīng)對(duì)挑戰(zhàn)三，我們?cè)O(shè)計(jì)了靈活的報(bào)警合并方案，讓值班工程師徹底跟報(bào)警風(fēng)暴say bye bye。

下面我們來詳細(xì)看下這三個(gè)方案的實(shí)現(xiàn)細(xì)節(jié)。

策略運(yùn)行平臺(tái)，讓算法迭代飛起來

在上篇《AIOps對(duì)監(jiān)控報(bào)警架構(gòu)的挑戰(zhàn)》文章中，我們提到異常判斷在落地AIOps智能異常檢測(cè)算法時(shí)，遇到的最大挑戰(zhàn)是算法迭代周期長(zhǎng)達(dá)一個(gè)月，費(fèi)時(shí)費(fèi)力，算法的迭代成本非常高。

為了能快速落地AIOps算法，并能產(chǎn)生好的效果，提高報(bào)警準(zhǔn)確率，我們希望算法的迭代周期從月降低到天級(jí)別，為了達(dá)到這個(gè)目標(biāo)，需要異常判斷系統(tǒng)滿足這些需求：

• 減少算法工程實(shí)現(xiàn)成本，彌合線下算法腳本和線上運(yùn)行代碼的鴻溝，從而能快速驗(yàn)證算法腳本的真實(shí)效果。
• 快速評(píng)估算法的穩(wěn)定性、性能和資源消耗，盡早發(fā)現(xiàn)問題，不將問題帶到線上，保證線上算法運(yùn)行環(huán)境的穩(wěn)定性。
• 分離算法代碼和算法模型，支持算法模型的獨(dú)立更新，加快算法模型的迭代速度。

基于這些需求，我們研發(fā)了策略運(yùn)行平臺(tái)。策略運(yùn)行平臺(tái)共分為三個(gè)環(huán)境：

• 離線環(huán)境：離線環(huán)境提供了策略開發(fā)框架，策略人員基于策略框架的標(biāo)準(zhǔn)Lib接口開發(fā)算法。同時(shí)策略開發(fā)框架還支持算法的離線回溯、時(shí)序數(shù)據(jù)可視化等功能。
• 在線環(huán)境：在線環(huán)境提供了一個(gè)穩(wěn)定可靠的算法運(yùn)行環(huán)境。在線環(huán)境會(huì)為每個(gè)任務(wù)啟動(dòng)一個(gè)子進(jìn)程，在子進(jìn)程中啟動(dòng)策略運(yùn)行時(shí)環(huán)境，運(yùn)行環(huán)境會(huì)提供跟策略開發(fā)框架一致的Lib接口，這樣就可以將離線開發(fā)的算法腳本直接放到線上運(yùn)行。
• 近線環(huán)境：近線環(huán)境和在線環(huán)境其實(shí)是同一套架構(gòu)，只是目的不同。近線環(huán)境會(huì)引入線上的小流量數(shù)據(jù)提前進(jìn)行算法驗(yàn)證，保證線上和線下的運(yùn)行效果一致；另外，近線環(huán)境還會(huì)評(píng)估算法腳本的資源消耗和穩(wěn)定性，如果評(píng)估結(jié)果不符合預(yù)期，那么算法腳本就會(huì)在近線環(huán)境被攔截住，從而保證線上環(huán)境的高可靠。

架構(gòu)介紹

上圖是策略運(yùn)行平臺(tái)的架構(gòu)圖，我們以新建一個(gè)報(bào)警策略的場(chǎng)景來依次介紹下每個(gè)模塊的功能：

1. 上層業(yè)務(wù)系統(tǒng)調(diào)用API接口，向業(yè)務(wù)模塊發(fā)起新建策略的請(qǐng)求，業(yè)務(wù)模塊會(huì)將報(bào)警配置、算法腳本和算法參數(shù)模型存儲(chǔ)起來。
2. 任務(wù)分配模塊會(huì)實(shí)時(shí)感知到新創(chuàng)建的報(bào)警策略，并將報(bào)警策略轉(zhuǎn)化為任務(wù)，然后分配給任務(wù)運(yùn)行模塊。
3. 任務(wù)運(yùn)行模塊周期性匯報(bào)心跳給任務(wù)分配模塊，通過心跳拉取分配給自己的任務(wù)列表。任務(wù)運(yùn)行模塊根據(jù)任務(wù)列表為每個(gè)任務(wù)啟動(dòng)一個(gè)策略運(yùn)行時(shí)環(huán)境，運(yùn)行時(shí)環(huán)境負(fù)責(zé)啟動(dòng)算法腳本，并周期性地驅(qū)動(dòng)算法腳本執(zhí)行異常判斷邏輯。另一方面，任務(wù)運(yùn)行模塊根據(jù)報(bào)警策略配置向數(shù)據(jù)轉(zhuǎn)發(fā)模塊訂閱所需的數(shù)據(jù)，將接收到的數(shù)據(jù)轉(zhuǎn)發(fā)給運(yùn)行時(shí)環(huán)境，并將算法腳本返回的異常判斷結(jié)果發(fā)送給下游的事件管理系統(tǒng)。
4. 數(shù)據(jù)轉(zhuǎn)發(fā)模塊根據(jù)訂閱配置到數(shù)據(jù)源訂閱數(shù)據(jù)，將接收到的數(shù)據(jù)轉(zhuǎn)發(fā)給任務(wù)運(yùn)行模塊。同時(shí)，數(shù)據(jù)轉(zhuǎn)發(fā)模塊還會(huì)將所有接收到的數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)cache中，允許算法腳本在運(yùn)行過程中方便地拉取近期的數(shù)據(jù)。
5. 數(shù)據(jù)適配模塊可以適配不同的上游數(shù)據(jù)源，支持推和拉兩種獲取數(shù)據(jù)模式。策略運(yùn)行平臺(tái)允許多個(gè)針對(duì)不同上游數(shù)據(jù)源的數(shù)據(jù)適配模塊同時(shí)存在，從而支持平臺(tái)中的報(bào)警策略使用來自于不同數(shù)據(jù)源的數(shù)據(jù)。

為了負(fù)載平衡和Failover，任務(wù)分配模塊需要將報(bào)警任務(wù)在任務(wù)運(yùn)行模塊中的不同實(shí)例間移動(dòng)。當(dāng)一個(gè)報(bào)警任務(wù)從實(shí)例A移動(dòng)到實(shí)例B上后，實(shí)例B會(huì)向數(shù)據(jù)轉(zhuǎn)發(fā)模塊訂閱任務(wù)需要的數(shù)據(jù)，而實(shí)例A則相應(yīng)取消數(shù)據(jù)訂閱。這樣，數(shù)據(jù)訂閱模塊就能夠?qū)?shù)據(jù)轉(zhuǎn)發(fā)到正確的實(shí)例上，從而保證任務(wù)的正常運(yùn)行。

如果算法腳本在運(yùn)行過程中存在內(nèi)部狀態(tài)，任務(wù)在實(shí)例B上啟動(dòng)后，可以在初始化的時(shí)候向數(shù)據(jù)cache請(qǐng)求近期的數(shù)據(jù)以重建內(nèi)部狀態(tài)。根據(jù)我們的實(shí)踐經(jīng)驗(yàn)，大部分任務(wù)只需要最近1到2個(gè)小時(shí)的數(shù)據(jù)就能夠重建內(nèi)部狀態(tài)了。

通過策略運(yùn)行平臺(tái)，我們已經(jīng)將算法迭代周期從月減少到天級(jí)別。另外，我們還將框架開放給業(yè)務(wù)運(yùn)維工程師使用，業(yè)務(wù)運(yùn)維工程師具有豐富的業(yè)務(wù)運(yùn)維經(jīng)驗(yàn)，由他們自己來開發(fā)異常檢測(cè)算法，可以將他們的專家經(jīng)驗(yàn)固化到報(bào)警系統(tǒng)中，提高報(bào)警的準(zhǔn)確性。

狀態(tài)機(jī)引擎，讓事件管理更輕松

為什么報(bào)警事件需要用狀態(tài)機(jī)描述呢？為了回答這個(gè)問題，我們首先介紹下什么是報(bào)警事件。

什么是報(bào)警事件？

我們先來看一個(gè)簡(jiǎn)單的故障場(chǎng)景，上圖中的時(shí)序數(shù)據(jù)展示了某服務(wù)的平均響應(yīng)時(shí)間（latency），假設(shè)監(jiān)控策略是如果latency大于800則報(bào)警：

1. 很明顯，在T1-T2時(shí)間段latency指標(biāo)處于異常狀態(tài)，在這期間有7個(gè)異常點(diǎn)，從運(yùn)維工程師看來，這7個(gè)異常點(diǎn)應(yīng)該歸屬為一個(gè)報(bào)警事件，所以報(bào)警事件是具有持續(xù)性（特征一）。
2. 異常發(fā)生后，報(bào)警系統(tǒng)會(huì)在故障期間重復(fù)通告Oncall工程師，故障恢復(fù)后也需要發(fā)送恢復(fù)通知，所以一個(gè)報(bào)警事件會(huì)產(chǎn)生多個(gè)報(bào)警消息（特征二）。
3. 另外，為了保證Oncall工程師介入處理故障期間免受打擾，我們還需要提供報(bào)警認(rèn)領(lǐng)功能。如果報(bào)警認(rèn)領(lǐng)的對(duì)象是報(bào)警消息（比如短信）。一方面，一個(gè)報(bào)警事件會(huì)產(chǎn)生多條報(bào)警消息，這意味著同一個(gè)人對(duì)同一個(gè)故障需要認(rèn)領(lǐng)多次；另一方面，假設(shè)故障已經(jīng)恢復(fù)，但是報(bào)警消息還沒有被認(rèn)領(lǐng)，會(huì)繼續(xù)提醒Oncall工程師認(rèn)領(lǐng)，這也不符合Oncall工程師的預(yù)期。所以報(bào)警認(rèn)領(lǐng)的對(duì)象需要為報(bào)警事件（特征三）。

我們?cè)賮砜匆粋€(gè)更復(fù)雜的場(chǎng)景。在實(shí)際運(yùn)維過程中，我們會(huì)分省份和運(yùn)營(yíng)商維度采集服務(wù)的平均響應(yīng)時(shí)間（latency），即多維度數(shù)據(jù)。如果我們分別針對(duì)不同省份和運(yùn)營(yíng)商都單獨(dú)配置一個(gè)監(jiān)控策略，很明顯，這會(huì)導(dǎo)致報(bào)警配置的管理成本很高，實(shí)際上運(yùn)維工程師希望配置類似latency{isp=*,province=*} > 80的報(bào)警策略，就可以同時(shí)對(duì)所有省份和運(yùn)營(yíng)商的latency指標(biāo)進(jìn)行分別判斷，這就是所謂的多維度異常判斷配置。

上圖展示了一個(gè)多維度判斷配置的例子，很明顯，在T2-T3期間，廣東電信和北京移動(dòng)的latency指標(biāo)同時(shí)發(fā)生異常。如果策略在故障期間只產(chǎn)生一個(gè)報(bào)警事件，那么我們根據(jù)事件無法區(qū)分是哪個(gè)省份和運(yùn)營(yíng)商的數(shù)據(jù)異常了，所以一個(gè)策略需要針對(duì)每個(gè)數(shù)據(jù)維度分別產(chǎn)生一個(gè)報(bào)警事件（特征四）。

上面通過兩個(gè)業(yè)務(wù)場(chǎng)景介紹了報(bào)警事件的業(yè)務(wù)模型，以及報(bào)警事件的四個(gè)特征，讓大家對(duì)報(bào)警事件有一個(gè)直觀的認(rèn)識(shí)，下面我們來看下基于狀態(tài)機(jī)的事件管理引擎。

為什么需要狀態(tài)機(jī)？

我們分報(bào)警認(rèn)領(lǐng)和報(bào)警升級(jí)兩個(gè)場(chǎng)景來介紹基于狀態(tài)機(jī)的事件管理引擎。

1. 報(bào)警認(rèn)領(lǐng)場(chǎng)景

我們結(jié)合狀態(tài)機(jī)來看下報(bào)警認(rèn)領(lǐng)場(chǎng)景中，報(bào)警事件的生命周期是如何演化的：

• T1時(shí)刻：latency指標(biāo)異常，監(jiān)控系統(tǒng)會(huì)產(chǎn)生一個(gè)異常狀態(tài)的報(bào)警事件，并發(fā)送異常通知給Oncall工程師。
• T2時(shí)刻：Oncall工程師沒有響應(yīng)報(bào)警，監(jiān)控系統(tǒng)重復(fù)發(fā)送報(bào)警給Oncall工程師。
• T3時(shí)刻：Oncall工程師響應(yīng)報(bào)警，完成認(rèn)領(lǐng)報(bào)警，表示已經(jīng)在跟進(jìn)中。同時(shí)，監(jiān)控系統(tǒng)會(huì)將認(rèn)領(lǐng)操作廣播給所有的Oncall工程師，表示已經(jīng)有人在跟進(jìn)報(bào)警了。
• T4時(shí)刻：Oncall工程師修復(fù)故障后，該報(bào)警事件變?yōu)檎顟B(tài)，監(jiān)控系統(tǒng)會(huì)發(fā)送故障恢復(fù)通知。

我們可以看到，報(bào)警事件的狀態(tài)變遷過程其實(shí)就是一個(gè)狀態(tài)機(jī)的運(yùn)行過程，每個(gè)狀態(tài)都有對(duì)應(yīng)的進(jìn)入條件和動(dòng)作，所以我們將報(bào)警事件抽象成狀態(tài)機(jī)來描述它。

2. 報(bào)警升級(jí)場(chǎng)景

我們?cè)賮砜匆粋€(gè)報(bào)警升級(jí)的場(chǎng)景，假設(shè)對(duì)應(yīng)的報(bào)警升級(jí)配置如下所示：

其中第1級(jí)配置的含義是：報(bào)警接收人為運(yùn)小二，報(bào)警發(fā)送渠道為短信，如果超過1分鐘沒有進(jìn)行報(bào)警認(rèn)領(lǐng)，或者認(rèn)領(lǐng)了但是超過2分鐘故障沒有恢復(fù)，則報(bào)警事件會(huì)升級(jí)到第二級(jí)。其他層級(jí)的配置含義以此類推。

這個(gè)報(bào)警升級(jí)配置對(duì)應(yīng)的狀態(tài)機(jī)如下圖所示。

我們通過一個(gè)真實(shí)的報(bào)警認(rèn)領(lǐng)場(chǎng)景來了解狀態(tài)機(jī)的變遷過程：

• 03:14 – 線上服務(wù)發(fā)生故障，監(jiān)控系統(tǒng)發(fā)送短信報(bào)警給第一級(jí)接收人：運(yùn)小二。
• 03:15 – 由于運(yùn)小二超過1分鐘沒有認(rèn)領(lǐng)報(bào)警事件，則事件狀態(tài)升級(jí)到第二級(jí)，并發(fā)送短信和電話給第二級(jí)接收人：運(yùn)小偉。運(yùn)小偉收到報(bào)警后，立即認(rèn)領(lǐng)故障，監(jiān)控系統(tǒng)同時(shí)會(huì)給運(yùn)小二和運(yùn)小偉發(fā)送認(rèn)領(lǐng)信息。
• 03:17 – 由于運(yùn)小偉不太熟悉業(yè)務(wù)，過了2分鐘，故障還沒有恢復(fù)，則報(bào)警事件升級(jí)到第三級(jí)，并發(fā)送短信和電話給三線值班人：運(yùn)小博，運(yùn)小博認(rèn)領(lǐng)了故障后，和運(yùn)小偉一起定位故障。
• 03:20 – 經(jīng)過兩人的一番努力，線上故障恢復(fù)了，則報(bào)警事件狀態(tài)變成正常，并發(fā)送恢復(fù)正常通知。

經(jīng)過上面的案例分析，我們看到，在報(bào)警升級(jí)場(chǎng)景下，報(bào)警事件的狀態(tài)變遷過程將變得更加復(fù)雜，而且不同事件狀態(tài)之間變遷的觸發(fā)條件和執(zhí)行動(dòng)作也可能會(huì)各不相同?；跔顟B(tài)機(jī)的報(bào)警事件模型不僅足夠抽象，表達(dá)能力強(qiáng)，可以囊括繁雜多樣的事件管理需求；而且可擴(kuò)展性強(qiáng)，通過狀態(tài)機(jī)描述文件定義狀態(tài)機(jī)行為，可以快速添加“數(shù)據(jù)斷流”、“報(bào)警失效”等新狀態(tài)，來滿足無數(shù)據(jù)檢測(cè)和報(bào)警失效檢測(cè)等更多復(fù)雜的事件管理需求。

報(bào)警合并，讓報(bào)警風(fēng)暴成為過去

在上篇《AIOps對(duì)監(jiān)控報(bào)警架構(gòu)的挑戰(zhàn)》文章中，我們通過三個(gè)場(chǎng)景給大家呈現(xiàn)報(bào)警風(fēng)暴的真面目，其中提到了可以對(duì)大量報(bào)警消息進(jìn)行有效的組織，然后再發(fā)送，從而將運(yùn)維工程師從報(bào)警風(fēng)暴中解救出來，這就是所謂的報(bào)警合并。

報(bào)警合并的基本思路是將相關(guān)聯(lián)的報(bào)警消息組成到一起，作為一條信息發(fā)送給運(yùn)維工程師，這樣運(yùn)維工程師可以根據(jù)這種相關(guān)性來輔助故障定位。

那如何來描述這種相關(guān)性呢？基于百度的運(yùn)維場(chǎng)景，我們挖掘出以下三類相關(guān)性：

1. 報(bào)警消息具有相同的維度屬性，比如具有相同的策略名，或者相同的部署屬性（比如產(chǎn)品線、模塊、集群、實(shí)例、機(jī)器等屬性）。
2. 報(bào)警消息所屬的模塊具有關(guān)聯(lián)關(guān)系，比如A模塊調(diào)用B模塊，如果B出現(xiàn)異常，一般A也會(huì)有相關(guān)異常，而我們可以通過歷史的異常事件來挖掘這類關(guān)聯(lián)性。
3. 當(dāng)發(fā)生機(jī)房故障時(shí)，位于同一個(gè)機(jī)房?jī)?nèi)部所產(chǎn)生的報(bào)警消息沒必要一一發(fā)送了，可以有效組織成一條消息發(fā)送給運(yùn)維工程師。

下圖展示了服務(wù)A下多個(gè)實(shí)例同時(shí)故障，如果對(duì)每個(gè)實(shí)例的故障，都給運(yùn)維工程師發(fā)送一條消息，那么就很容易產(chǎn)生報(bào)警風(fēng)暴。我們通過將報(bào)警緩存一段時(shí)間（可以設(shè)置最大延遲時(shí)間，從而保證報(bào)警時(shí)效性），然后將緩存內(nèi)所有屬于服務(wù)A的報(bào)警合并到一起后發(fā)送，這樣運(yùn)維工程師只會(huì)收到一條報(bào)警，而且在報(bào)警信息中還會(huì)告知運(yùn)維人員，服務(wù)A下有大量實(shí)例異常，這樣運(yùn)維人員可以根據(jù)這個(gè)提示有針對(duì)性去排查故障。

關(guān)于報(bào)警合并的更多細(xì)節(jié)，可以參考我們之前的文章《我在百度對(duì)抗報(bào)警風(fēng)暴（一）》、《我在百度對(duì)抗報(bào)警風(fēng)暴（二）》。

總? 結(jié)

本文我們首先回顧了AIOps對(duì)監(jiān)控報(bào)警架構(gòu)的挑戰(zhàn)，然后從工程角度聊了聊AIOps落地難的應(yīng)對(duì)之策。通過這兩篇文章給大家系統(tǒng)性地介紹了百度Noah監(jiān)控報(bào)警系統(tǒng)的前世今生，希望能給大家?guī)硪恍┦斋@。如果大家對(duì)智能運(yùn)維感興趣，歡迎留言繼續(xù)交流。

溫馨提示

如果你喜歡本文，請(qǐng)分享到朋友圈，想要獲得更多信息，請(qǐng)關(guān)注我們！
如果你有任何問題歡迎留言咨詢~
如果想試用我們的企業(yè)級(jí)運(yùn)維平臺(tái)NoahEE，請(qǐng)聯(lián)系郵箱：noah_bd@baidu.com