聊聊AIOps落地監控報警的應對之策

作者簡介

周偉百度高級研發工程師

負責百度智能運維（Noah）監控報警系統、通告平臺；在精準報警、精準通告、報警收斂、公/私有云監控等方向具有廣泛的實踐經驗。

乾貨概覽

監控報警是故障發現的重要一環，也是百度在AIOps的最早切入方向之一，目前百度AIOps在監控報警方面已經有兩個場景取得突出效果：智能異常檢測和智能報警合併。

如何支撐AIOps算法在監控報警系統的快速落地併產生業務價值，這對監控報警架構提出了很大的挑戰！在上篇《AIOps對監控報警架構的挑戰》文章中，我們介紹了監控報警系統在故障處理流程中的位置（故障發現和故障通告），並且分析了AIOps對監控報警架構的三個挑戰。在本篇，我們將詳細介紹應對這三個挑戰的方案：

爲了應對挑戰一，我們研發了策略運行平臺，讓AIOps算法迭代找到飛一般的感覺。
爲了應對挑戰二，我們提出了基於狀態機的事件管理引擎，讓事件管理so easy。
爲了應對挑戰三，我們設計了靈活的報警合併方案，讓值班工程師徹底跟報警風暴say bye bye。

下面我們來詳細看下這三個方案的實現細節。

策略運行平臺，讓算法迭代飛起來

在上篇《AIOps對監控報警架構的挑戰》文章中，我們提到異常判斷在落地AIOps智能異常檢測算法時，遇到的最大挑戰是算法迭代週期長達一個月，費時費力，算法的迭代成本非常高。

爲了能快速落地AIOps算法，並能產生好的效果，提高報警準確率，我們希望算法的迭代週期從月降低到天級別，爲了達到這個目標，需要異常判斷系統滿足這些需求：

減少算法工程實現成本，彌合線下算法腳本和線上運行代碼的鴻溝，從而能快速驗證算法腳本的真實效果。
快速評估算法的穩定性、性能和資源消耗，儘早發現問題，不將問題帶到線上，保證線上算法運行環境的穩定性。
分離算法代碼和算法模型，支持算法模型的獨立更新，加快算法模型的迭代速度。

基於這些需求，我們研發了策略運行平臺。策略運行平臺共分爲三個環境：

離線環境：離線環境提供了策略開發框架，策略人員基於策略框架的標準Lib接口開發算法。同時策略開發框架還支持算法的離線回溯、時序數據可視化等功能。
在線環境：在線環境提供了一個穩定可靠的算法運行環境。在線環境會爲每個任務啓動一個子進程，在子進程中啓動策略運行時環境，運行環境會提供跟策略開發框架一致的Lib接口，這樣就可以將離線開發的算法腳本直接放到線上運行。
近線環境：近線環境和在線環境其實是同一套架構，只是目的不同。近線環境會引入線上的小流量數據提前進行算法驗證，保證線上和線下的運行效果一致；另外，近線環境還會評估算法腳本的資源消耗和穩定性，如果評估結果不符合預期，那麼算法腳本就會在近線環境被攔截住，從而保證線上環境的高可靠。

架構介紹

上圖是策略運行平臺的架構圖，我們以新建一個報警策略的場景來依次介紹下每個模塊的功能：

上層業務系統調用API接口，向業務模塊發起新建策略的請求，業務模塊會將報警配置、算法腳本和算法參數模型存儲起來。
任務分配模塊會實時感知到新創建的報警策略，並將報警策略轉化爲任務，然後分配給任務運行模塊。
任務運行模塊週期性彙報心跳給任務分配模塊，通過心跳拉取分配給自己的任務列表。任務運行模塊根據任務列表爲每個任務啓動一個策略運行時環境，運行時環境負責啓動算法腳本，並週期性地驅動算法腳本執行異常判斷邏輯。另一方面，任務運行模塊根據報警策略配置向數據轉發模塊訂閱所需的數據，將接收到的數據轉發給運行時環境，並將算法腳本返回的異常判斷結果發送給下游的事件管理系統。
數據轉發模塊根據訂閱配置到數據源訂閱數據，將接收到的數據轉發給任務運行模塊。同時，數據轉發模塊還會將所有接收到的數據存儲到數據cache中，允許算法腳本在運行過程中方便地拉取近期的數據。
數據適配模塊可以適配不同的上游數據源，支持推和拉兩種獲取數據模式。策略運行平臺允許多個針對不同上游數據源的數據適配模塊同時存在，從而支持平臺中的報警策略使用來自於不同數據源的數據。

爲了負載平衡和Failover，任務分配模塊需要將報警任務在任務運行模塊中的不同實例間移動。當一個報警任務從實例A移動到實例B上後，實例B會向數據轉發模塊訂閱任務需要的數據，而實例A則相應取消數據訂閱。這樣，數據訂閱模塊就能夠將數據轉發到正確的實例上，從而保證任務的正常運行。

如果算法腳本在運行過程中存在內部狀態，任務在實例B上啓動後，可以在初始化的時候向數據cache請求近期的數據以重建內部狀態。根據我們的實踐經驗，大部分任務只需要最近1到2個小時的數據就能夠重建內部狀態了。

通過策略運行平臺，我們已經將算法迭代週期從月減少到天級別。另外，我們還將框架開放給業務運維工程師使用，業務運維工程師具有豐富的業務運維經驗，由他們自己來開發異常檢測算法，可以將他們的專家經驗固化到報警系統中，提高報警的準確性。

狀態機引擎，讓事件管理更輕鬆

爲什麼報警事件需要用狀態機描述呢？爲了回答這個問題，我們首先介紹下什麼是報警事件。

什麼是報警事件？

我們先來看一個簡單的故障場景，上圖中的時序數據展示了某服務的平均響應時間（latency），假設監控策略是如果latency大於800則報警：

很明顯，在T1-T2時間段latency指標處於異常狀態，在這期間有7個異常點，從運維工程師看來，這7個異常點應該歸屬爲一個報警事件，所以報警事件是具有持續性（特徵一）。
異常發生後，報警系統會在故障期間重複通告Oncall工程師，故障恢復後也需要發送恢復通知，所以一個報警事件會產生多個報警消息（特徵二）。
另外，爲了保證Oncall工程師介入處理故障期間免受打擾，我們還需要提供報警認領功能。如果報警認領的對象是報警消息（比如短信）。一方面，一個報警事件會產生多條報警消息，這意味着同一個人對同一個故障需要認領多次；另一方面，假設故障已經恢復，但是報警消息還沒有被認領，會繼續提醒Oncall工程師認領，這也不符合Oncall工程師的預期。所以報警認領的對象需要爲報警事件（特徵三）。

我們再來看一個更復雜的場景。在實際運維過程中，我們會分省份和運營商維度採集服務的平均響應時間（latency），即多維度數據。如果我們分別針對不同省份和運營商都單獨配置一個監控策略，很明顯，這會導致報警配置的管理成本很高，實際上運維工程師希望配置類似latency{isp=*,province=*} > 80的報警策略，就可以同時對所有省份和運營商的latency指標進行分別判斷，這就是所謂的多維度異常判斷配置。

上圖展示了一個多維度判斷配置的例子，很明顯，在T2-T3期間，廣東電信和北京移動的latency指標同時發生異常。如果策略在故障期間只產生一個報警事件，那麼我們根據事件無法區分是哪個省份和運營商的數據異常了，所以一個策略需要針對每個數據維度分別產生一個報警事件（特徵四）。

上面通過兩個業務場景介紹了報警事件的業務模型，以及報警事件的四個特徵，讓大家對報警事件有一個直觀的認識，下面我們來看下基於狀態機的事件管理引擎。

爲什麼需要狀態機？

我們分報警認領和報警升級兩個場景來介紹基於狀態機的事件管理引擎。

報警認領場景

我們結合狀態機來看下報警認領場景中，報警事件的生命週期是如何演化的：

T1時刻：latency指標異常，監控系統會產生一個異常狀態的報警事件，併發送異常通知給Oncall工程師。
T2時刻：Oncall工程師沒有響應報警，監控系統重複發送報警給Oncall工程師。
T3時刻：Oncall工程師響應報警，完成認領報警，表示已經在跟進中。同時，監控系統會將認領操作廣播給所有的Oncall工程師，表示已經有人在跟進報警了。
T4時刻：Oncall工程師修復故障後，該報警事件變爲正常狀態，監控系統會發送故障恢復通知。

我們可以看到，報警事件的狀態變遷過程其實就是一個狀態機的運行過程，每個狀態都有對應的進入條件和動作，所以我們將報警事件抽象成狀態機來描述它。

報警升級場景

我們再來看一個報警升級的場景，假設對應的報警升級配置如下所示：

其中第1級配置的含義是：報警接收人爲運小二，報警發送渠道爲短信，如果超過1分鐘沒有進行報警認領，或者認領了但是超過2分鐘故障沒有恢復，則報警事件會升級到第二級。其他層級的配置含義以此類推。

這個報警升級配置對應的狀態機如下圖所示。

我們通過一個真實的報警認領場景來了解狀態機的變遷過程：

03:14 – 線上服務發生故障，監控系統發送短信報警給第一級接收人：運小二。
03:15 – 由於運小二超過1分鐘沒有認領報警事件，則事件狀態升級到第二級，併發送短信和電話給第二級接收人：運小偉。運小偉收到報警後，立即認領故障，監控系統同時會給運小二和運小偉發送認領信息。
03:17 – 由於運小偉不太熟悉業務，過了2分鐘，故障還沒有恢復，則報警事件升級到第三級，併發送短信和電話給三線值班人：運小博，運小博認領了故障後，和運小偉一起定位故障。
03:20 – 經過兩人的一番努力，線上故障恢復了，則報警事件狀態變成正常，併發送恢復正常通知。

經過上面的案例分析，我們看到，在報警升級場景下，報警事件的狀態變遷過程將變得更加複雜，而且不同事件狀態之間變遷的觸發條件和執行動作也可能會各不相同。基於狀態機的報警事件模型不僅足夠抽象，表達能力強，可以囊括繁雜多樣的事件管理需求；而且可擴展性強，通過狀態機描述文件定義狀態機行爲，可以快速添加“數據斷流”、“報警失效”等新狀態，來滿足無數據檢測和報警失效檢測等更多複雜的事件管理需求。

報警合併，讓報警風暴成爲過去

在上篇《AIOps對監控報警架構的挑戰》文章中，我們通過三個場景給大家呈現報警風暴的真面目，其中提到了可以對大量報警消息進行有效的組織，然後再發送，從而將運維工程師從報警風暴中解救出來，這就是所謂的報警合併。

報警合併的基本思路是將相關聯的報警消息組成到一起，作爲一條信息發送給運維工程師，這樣運維工程師可以根據這種相關性來輔助故障定位。

那如何來描述這種相關性呢？基於百度的運維場景，我們挖掘出以下三類相關性：

報警消息具有相同的維度屬性，比如具有相同的策略名，或者相同的部署屬性（比如產品線、模塊、集羣、實例、機器等屬性）。
報警消息所屬的模塊具有關聯關係，比如A模塊調用B模塊，如果B出現異常，一般A也會有相關異常，而我們可以通過歷史的異常事件來挖掘這類關聯性。
當發生機房故障時，位於同一個機房內部所產生的報警消息沒必要一一發送了，可以有效組織成一條消息發送給運維工程師。

下圖展示了服務A下多個實例同時故障，如果對每個實例的故障，都給運維工程師發送一條消息，那麼就很容易產生報警風暴。我們通過將報警緩存一段時間（可以設置最大延遲時間，從而保證報警時效性），然後將緩存內所有屬於服務A的報警合併到一起後發送，這樣運維工程師只會收到一條報警，而且在報警信息中還會告知運維人員，服務A下有大量實例異常，這樣運維人員可以根據這個提示有針對性去排查故障。