AIOps對監控報警架構的挑戰

做者簡介：周偉 百度高級研發工程師

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

乾貨概覽

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

如何支撐 AIOps 算法在監控報警系統的快速落地併產生業務價值，這對監控報警架構提出了很大的挑戰！本文首先介紹百度Noah監控報警的功能和業務模型，而後重點分析百度監控報警系統在落地 AIOps 過程當中遇到的挑戰。

百度Noah監控報警系統

首先咱們介紹下百度的標準故障處理流程，如上圖所示，主要分爲如下7個過程：

1. 故障發生：好比當內網機房核心交換機發生故障時，會形成內網的網絡故障，從而致使產品線的流量損失。
2. 故障發現：監控系統實時檢測到產品線的流量異常。
3. 故障通告：監控系統會經過短信或電話等渠道通知業務運維人員，產品線流量有異常。
4. 故障止損：業務運維人員會執行故障預案，或者藉助故障自愈平臺智能地執行故障止損操做，以達到快速止損的目的，常見的操做是將流量從故障機房切到非故障機房。
5. 故障定位：運維人員和研發人員一塊兒定位故障根因。
6. 故障恢復：當定位到問題後，運維人員開始執行修復操做，直到線上的全部服務（包括未接流量的模塊）都完全恢復正常。
7. 故障總結：運維人員會對故障處理流程進行復盤總結，好的方面繼續保持，很差的方面排期改正。

在整個故障處理流程中，監控系統主要負責故障發現到故障定位的環節；報警系統做爲監控系統的子系統，主要負責故障發現和故障通告。

百度Noah報警系統最先服務於百度內部的監控平臺，提供從機器、實例到上層業務等全方位、立體化的監控報警能力，已經覆蓋百度的全部產品線。同時，系統面臨很大的挑戰，每秒須要處理千萬級個數據點，線上的監控配置已經達到百萬級別，天天會產生千萬個報警事件，在這麼大的量級下，還需保證秒級的報警時效性。

百度Noah報警系統不只爲百度內部用戶服務，咱們還同時爲公有云和私有云服務提供監控報警能力。咱們將內部強大的監控產品和運維理念輸出到業界，打造了NoahEE產品（詳見《百度雲企業級運維平臺——NoahEE》介紹 ），幫助客戶一塊兒提高運維效率和線上穩定性。另外，咱們還依託報警系統孵化出了百度AIOps智能運維產品，包括智能異常檢測、故障定位、報警合併等高級功能，已經落地金融、交通、互聯網等行業，受到客戶一致好評。

業務模型

監控報警系統的核心使命是精準報警，那報警系統是如何進行故障發現和故障通告呢？咱們經過一個場景來了解下。

假設上圖中的曲線是某產品線的流量指標（簡稱PV），其中每一個點表明一個PV數據點，假設但願當PV值小於100時，異常判斷結果爲異常，並通告給業務運維人員。

監控報警系統會週期性地對最近一個數據點（Data）進行判斷，若是PV小於100則判斷結果爲異常，不然判斷結果爲正常。當首次異常的時候（即判斷結果從正常轉爲異常），會產生一個報警事件（Event）；當異常恢復時，則將報警事件結束掉。在報警事件持續期間，會根據報警規則產生一個或多個報警消息（Message），並將報警消息渲染成容易理解的文本，經過下游發送渠道（短信、電話等）送達給運維工程師。經過這麼一個流程，監控報警系統就達到了故障發現和故障通告的目的。

相應地，咱們將監控報警系統拆分紅如下三個子系統：

• 異常判斷系統：主要功能是根據異常判斷配置週期性地對數據進行判斷，並將產生的判斷結果（正常或異常）發送給下游。異常判斷系統不只須要提供基於傳統四則運算的異常判斷，還須要提供基於AIOps算法的異常判斷。
• 事件管理系統：主要負責報警事件的管理工做，並基於報警事件提供防抖動過濾、報警認領、逐級通告、報警靜默等功能。
• 通告發送系統：主要負責報警合併、渲染和發送等功能。另外爲了防止下游發送網關的帶寬被某些業務的突發報警流量淹沒而致使其它業務的報警消息得不到及時發送，還須要提供配額和流控功能，從而保證每一個業務公平地使用發送網關資源。

將監控報警系統拆分紅三個子系統後，有如下兩個好處：

• 系統功能邊界清晰，具有可擴展的報警架構能力

每一個子系統能夠根據自身的功能特色採用不一樣的技術棧和部署架構，由不一樣的研發工程師負責研發和維護。好比異常判斷系統更偏向計算邏輯，能夠採用Golang或C++這類更加註重執行效率的技術棧；而事件管理和報警發送系統更偏向於業務邏輯，能夠採用Java或PHP等更注重研發效率的技術棧。

每一個子系統也能夠獨立進行功能和架構升級。好比異常判斷系統須要大量的CPU資源，比較適合採用集羣架構，這樣方便橫向擴展，增長系統吞吐能力；而通告發送系統的流量相對小些，初期能夠採用主備架構，不只架構簡單可靠，並且研發和維護成本小。假設隨着業務的發展，業務須要更大的報警發送能力，通告發送系統只需保證對外接口不變，獨立將自身架構升級爲集羣架構，就可獲取更大的報警發送能力。

• 報警功能組件化，具有靈活的商業化交付能力

每一個子系統都是一個獨立的功能組件，能夠獨立部署、升級，這樣就具有靈活支持商業化交付能力。好比咱們能夠只將通告發送系統單獨交付給商業化客戶，客戶經過直接調用通告發送的接口就能夠獲取報警合併、渲染、發送等能力。

咱們遇到了哪些挑戰？

經過上面的業務模型介紹，你們已經對監控報警系統有了全局的認識，那下面來詳細分析落地AIOps遇到的問題。

1. 落地AIOps算法週期長，迭代成本高

咱們繼續來看PV指標，經過對歷史PV數據的觀察，咱們發現不一樣時間段的PV大小是上下波動的，好比在早上八九點是流量高峯期，在凌晨兩三點是流量低峯期，另外工做日和週末的流量大小也是不一樣的。這意味着，咱們不可能設置統一的閾值來檢測PV流量的變化狀況，那麼怎麼辦呢？

百度策略人員研發了基於魯棒迴歸的無監督突升突降檢測算法，這個算法不須要設置PV閾值，便可檢測流量的變化。下面展現的這個公式是其中的一步，其中變量y就是真實的PV值，f(x)表明利用某種算法預測到的PV值。若是對算法細節感興趣，可參考文章：《咱們不同！告訴你百度是如何作智能流量異常檢測的》。

這類異常檢測算法相對於傳統的四則運算，有如下不一樣：

• 對不一樣類型指標在不一樣的場景下，算法f(x)是不相同的，特別是在初期探索階段，咱們須要快速迭代算法，以驗證哪一種算法效果最優。
• 算法f(x)會依賴根據歷史數據訓練到的模型，然而業務數據的特徵複雜，不斷變化，這意味着咱們須要按期更新策略模型，以保證算法的效果。
• 算法f(x)對CPU資源的需求差別很大，有的算法計算量很是小，可能單個CPU核就能夠運行數千個此類任務，而有的算法會引入RNN等深度學習算法，計算複雜度特別高，每每就須要獨佔某個CPU核。

最初咱們落地這類AIOps算法時，總體的流程如上圖所示：

1. 策略工程師用Python或Matlab編寫算法腳本，並在線下進行Case回溯，保證算法的普適性。
2. 研發工程師將算法腳本改寫成線上代碼（C++或Java），以便在線上運行。
3. 測試工程師對改寫後的算法代碼進行測試迴歸。
4. 運維工程師對模塊（包括算法代碼和策略模型）進行發佈上線。

上面的研發流程暴露出不少的問題。一方面，對咱們的研發工程師要求比較苛刻，既須要看得懂策略算法，又要熟知工程研發；另外一方面，算法的迭代週期比較長，常常以月爲單位，可能算法剛上線，數據特徵就發生了變化，致使算法失效；最後，即便算法程序迭代穩定了，可是參數模型還須要按期更新，因爲參數模型和算法程序沒有分離，致使後期參數模型的更新須要不斷上線，提升了維護成本。

2. 報警管理需求繁雜多樣，疲於應付

咱們再來看下報警管理的挑戰。報警管理須要處理的需求比較多，咱們以一個典型的運維場景來串一下這些需求：

• 凌晨一點，網絡運維工程師對網絡進行調整，致使網絡產生了短期的抖動，這類抖動的持續時間一般都在1到2分鐘左右。網絡抖動致使大量的業務監控指標發生相應的抖動，從而觸發報警。此時業務運維工程師就但願系統可以提供防抖動過濾功能，避免指標在短期抖動時觸發報警。
• 凌晨三點，因爲系統日誌清理機制有問題，致使集羣內60%機器的磁盤佔用率超過安全線，觸發報警。可是報警電話未能喚醒值班工程師，最終致使大規模系統故障。所以值班工程師但願系統提供報警重複提醒功能，當值班工程師沒有及時響應報警時，經過屢次重複呼叫來避免報警遺漏。
• 可是，當值班工程師被及時喚醒並開始處理故障後，系統持續的重複提醒會對值班工程師造成很大的干擾。所以工程師們就但願引入報警認領功能，告知報警系統故障已經有人在處理，重複提醒能夠中止了。
• 凌晨4點半，因爲值班工程師是新入職的，對系統不夠熟悉，日誌清理的操做還未完成，致使故障持續。此時，就但願系統可以提供報警升級功能，在故障長時間未解除的時候能夠通知資深的二線值班工程師介入處理。
• 凌晨4點50，二線值班工程師完成日誌清理，故障恢復。這時，二線工程師發現日誌清理操做實際上是一套標準的止損操做，徹底能夠在發生報警時自動執行。所以但願系統可以提供報警回調功能，未來相似的問題就無需人工介入處理了。
• 除此以外，值班工程師可能還有斷流檢測、報警靜默等等各類需求。

可見報警管理的需求複雜多樣，若是咱們不能抽象出一個可擴展的報警管理模型，咱們將變得愈來愈被動。

3. 報警風暴淹沒核心報警，一籌莫展

看完報警管理，咱們再來看下報警風暴的挑戰。

爲了不遺漏故障，運維工程師經常會在監控系統中定製大量的監控指標和報警規則，從而創建起從網絡到機器、從實例到模塊、再到上層業務的立體化監控。立體化的監控雖然極大提升了故障發現的能力，可是很容易致使一個故障觸發大量報警，形成報警風暴。

爲了讓你們認識報警風暴的真面目，咱們來看三個典型的場景：

1. 機器故障：機器發生故障時，監控機器健康度的報警規則將會產生報警；而後監控機器上實例運行狀態的報警規則也會產生報警；最後這些實例的上游應用模塊也會受到影響，相關的報警規則也會開始報警。這樣一來，一個機器的故障就可能會產生幾十條的報警消息。
2. 應用模塊故障：首先這個應用模塊中的全部實例都會發出報警，緊接着上游應用模塊也會產生報警。當應用模塊中包含的實例比較多時，這類故障經常會產生數百條的報警消息。
3. 機房故障：會同時形成網絡、機器、域名、應用模塊、業務等多層次、多方面的異常報警，產生的報警消息能夠多達數萬條。

咱們能夠看到，這三種典型故障對值班工程師都很是的不友好。他們的手機會被短信和電話轟炸，與此同時大量的報警消息卻並不能幫助他們迅速尋找根因和制訂止損方案。對大量報警消息先進行有效地組織，而後再發送，就成爲值班工程師的一大需求。

總  結

本文首先介紹了百度Noah監控報警系統功能和業務模型，而後結合案例場景分析了咱們在落地AIOps時遇到的問題，讓你們對監控報警系統的現狀有一個直觀的認識。咱們將在下篇文章中講解如何來解決這些挑戰，敬請期待。

舒適提示

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