作者簡介
周偉 百度高級研發工程師
負責百度智能運維（Noah）監控報警系統、通告平臺；在精準報警、精準通告、報警收斂、公/私有云監控等方向具有廣泛的實踐經驗。
乾貨概覽
監控報警是故障發現的重要一環，也是百度在AIOps的最早切入方向之一，目前百度 AIOps 在監控報警方面已經有兩個場景取得突出效果：智能異常檢測和智能報警合併。
如何支撐 AIOps 算法在監控報警系統的快速落地併產生業務價值，這對監控報警架構提出了很大的挑戰！本文首先介紹百度Noah監控報警的功能和業務模型，然後重點分析百度監控報警系統在落地 AIOps 過程中遇到的挑戰。
百度Noah監控報警系統
首先我們介紹下百度的標準故障處理流程，如上圖所示，主要分爲以下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算法時，整體的流程如上圖所示：
策略工程師用Python或Matlab編寫算法腳本，並在線下進行Case回溯，保證算法的普適性。
研發工程師將算法腳本改寫成線上代碼（C++或Java），以便在線上運行。
測試工程師對改寫後的算法代碼進行測試迴歸。
運維工程師對模塊（包括算法代碼和策略模型）進行發佈上線。
上面的研發流程暴露出很多的問題。一方面，對我們的研發工程師要求比較苛刻，既需要看得懂策略算法，又要熟知工程研發；另一方面，算法的迭代週期比較長，經常以月爲單位，可能算法剛上線，數據特徵就發生了變化，導致算法失效；最後，即使算法程序迭代穩定了，但是參數模型還需要定期更新，由於參數模型和算法程序沒有分離，導致後期參數模型的更新需要不斷上線，提高了維護成本。
2
報警管理需求繁雜多樣，疲於應付
我們再來看下報警管理的挑戰。報警管理需要處理的需求比較多，我們以一個典型的運維場景來串一下這些需求：
凌晨一點，網絡運維工程師對網絡進行調整，導致網絡產生了短時間的抖動，這類抖動的持續時間通常都在1到2分鐘左右。網絡抖動導致大量的業務監控指標發生相應的抖動，從而觸發報警。此時業務運維工程師就希望系統能夠提供防抖動過濾功能，避免指標在短時間抖動時觸發報警。
凌晨三點，由於系統日誌清理機制有問題，導致集羣內60%機器的磁盤佔用率超過安全線，觸發報警。但是報警電話未能喚醒值班工程師，最終導致大規模系統故障。因此值班工程師希望系統提供報警重複提醒功能，當值班工程師沒有及時響應報警時，通過多次重複呼叫來避免報警遺漏。
但是，當值班工程師被及時喚醒並開始處理故障後，系統持續的重複提醒會對值班工程師形成很大的干擾。因此工程師們就希望引入報警認領功能，告知報警系統故障已經有人在處理，重複提醒可以停止了。
凌晨4點半，由於值班工程師是新入職的，對系統不夠熟悉，日誌清理的操作還未完成，導致故障持續。此時，就希望系統能夠提供報警升級功能，在故障長時間未解除的時候可以通知資深的二線值班工程師介入處理。
凌晨4點50，二線值班工程師完成日誌清理，故障恢復。這時，二線工程師發現日誌清理操作其實是一套標準的止損操作，完全可以在發生報警時自動執行。因此希望系統能夠提供報警回調功能，將來類似的問題就無需人工介入處理了。
除此之外，值班工程師可能還有斷流檢測、報警靜默等等各種需求。
可見報警管理的需求複雜多樣，如果我們不能抽象出一個可擴展的報警管理模型，我們將變得越來越被動。
3
報警風暴淹沒核心報警，束手無策
看完報警管理，我們再來看下報警風暴的挑戰。
爲了避免遺漏故障，運維工程師常常會在監控系統中定製大量的監控指標和報警規則，從而建立起從網絡到機器、從實例到模塊、再到上層業務的立體化監控。立體化的監控雖然極大提高了故障發現的能力，但是很容易導致一個故障觸發大量報警，造成報警風暴。
爲了讓大家認識報警風暴的真面目，我們來看三個典型的場景：
機器故障：機器發生故障時，監控機器健康度的報警規則將會產生報警；然後監控機器上實例運行狀態的報警規則也會產生報警；最後這些實例的上游應用模塊也會受到影響，相關的報警規則也會開始報警。這樣一來，一個機器的故障就可能會產生幾十條的報警消息。
應用模塊故障：首先這個應用模塊中的所有實例都會發出報警，緊接着上游應用模塊也會產生報警。當應用模塊中包含的實例比較多時，這類故障常常會產生數百條的報警消息。
機房故障：會同時造成網絡、機器、域名、應用模塊、業務等多層次、多方面的異常報警，產生的報警消息可以多達數萬條。
我們可以看到，這三種典型故障對值班工程師都非常的不友好。他們的手機會被短信和電話轟炸，與此同時大量的報警消息卻並不能幫助他們迅速尋找根因和制訂止損方案。對大量報警消息先進行有效地組織，然後再發送，就成爲值班工程師的一大需求。
總 結
本文首先介紹了百度Noah監控報警系統功能和業務模型，然後結合案例場景分析了我們在落地AIOps時遇到的問題，讓大家對監控報警系統的現狀有一個直觀的認識。我們將在下篇文章中講解如何來解決這些挑戰，敬請期待。
溫馨提示
如果你喜歡本文，請分享到朋友圈，想要獲得更多信息，請關注我們！
如果你有任何問題歡迎留言諮詢~
如果想試用我們的企業級運維平臺NoahEE，請聯繫郵箱：[email protected]
RECOMMEND
推薦閱讀
↓↓↓ 點擊"閱讀原文" 【瞭解更多精彩內容】
