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

做者簡介：周偉 百度高級研發工程師
負責百度智能運維（Noah）監控報警系統、通告平臺；在精準報警、精準通告、報警收斂、公/私有云監控等方向具備普遍的實踐經驗。

乾貨概覽

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

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

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

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

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

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

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

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

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

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

架構介紹

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

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

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

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

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

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

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

什麼是報警事件？

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

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

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

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

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

爲何須要狀態機？

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

1. 報警認領場景

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

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

咱們能夠看到，報警事件的狀態變遷過程其實就是一個狀態機的運行過程，每一個狀態都有對應的進入條件和動做，因此咱們將報警事件抽象成狀態機來描述它。

2. 報警升級場景

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

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

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

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

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

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

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

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

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

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

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

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

關於報警合併的更多細節，能夠參考咱們以前的文章《我在百度對抗報警風暴（一）》、《我在百度對抗報警風暴（二）》。

總  結

本文咱們首先回顧了AIOps對監控報警架構的挑戰，而後從工程角度聊了聊AIOps落地難的應對之策。經過這兩篇文章給你們系統性地介紹了百度Noah監控報警系統的前世此生，但願能給你們帶來一些收穫。若是你們對智能運維感興趣，歡迎留言繼續交流。

舒適提示

若是你喜歡本文，請分享到朋友圈，想要得到更多信息，請關注咱們！
若是你有任何問題歡迎留言諮詢~
若是想試用咱們的企業級運維平臺NoahEE，請聯繫郵箱：noah_bd@baidu.com