咱們不生產報警，咱們只是報警的搬運工

本文做者：AIOps智能運維

做者簡介

      芃熙    百度雲高級研發工程師

 

負責百度雲Noah監控產品報警系統的設計和研發，在大規模分佈式系統、監控、運維on-call方面具備普遍的實踐經驗。

 

乾貨概覽

百度雲的Noah監控系統（Argus）是保障百度內外服務高可用的基石。它具備諸如機器監控、實例監控、HTTP監控、域名監控、日誌監控、自定義監控等多種監控手段，具有「海陸空」全方位的監控能力，讓服務異常無處遁形。若是你看過本公衆號以前的系列文章，相信你會以爲我所言非虛。然而如此強大的監控系統所產生的「辣麼多」報警若是不能及時精準地送達給運維人員，那麼一切都還只是個傳說。今天咱們就聊聊報警如何送達的問題，注意，咱們今天不談報警，咱們只談報警的搬運工——百度雲Noah通告平臺！

一個都不能少

報警不一樣於普通的通知，它反映的是線上服務即將或正在遭受損失，若是咱們把核心報警搞丟了，形成線上故障得不到及時解決，這個責任是巨大的。因爲報警系統自然就這樣要求高可靠性，所以咱們奉行「at-least-once」的投遞原則，確保報警至少有一次能成功抵達用戶，作到「該報的報警一個都不能少」。而爲了實現這個目標咱們經歷過很多坑：

• 機房網絡連通性問題

咱們發送報警要依賴四個底層發送網關（電話網關、短信網關、IM網關、郵件網關）來向用戶發送消息，以下圖所示。因爲公司網絡環境的緣由，這些網關部署在某些特定機房，和上游的監控系統部署在不一樣機房中，這樣機房間的網絡擁塞或抖動將直接影響報警發送。解決這種問題，能夠將底層發送網關主備部署到不一樣的機房，由上游系統重試解決。也能夠考慮建設額外的網絡路由通路，例如機房A到B不通時，繞經機房C 「曲線救國」。具體選擇何種策略，要依據不一樣的網絡現狀而定。

• 限流

資源永遠是有限的。對咱們來講底層網關的發送能力是瓶頸所在，尤爲是電話網關，線路資源很是寶貴，有明確的路數限制（例如100路）。這樣當某業務的報警量很大時，它的報警將用光有限的發送資源，將致使其餘業務的重要報警發送延遲甚至失敗。所以，須要對不一樣業務的報警量進行限流，避免單業務報警量過大影響其餘業務。

• 報警追查

監控系統中關於如何報警有多種配置，例如報警最大次數、報警容許等待時長、報警屏蔽等，這些配置都會影響報警發送行爲。常常有用戶反饋報警不符合預期，例如「該收的報警沒有收到，不應收的報警卻收到了」等這種諮詢問題，其實每每都是因爲報警配置致使的，並不是系統功能不正常，所以咱們面臨不少報警追查的需求。爲此，咱們將報警從產生到最終發送整個生命週期中的處理歷史都記錄下來，讓用戶像查詢快遞物流信息同樣去追查報警處理歷史。個人工做是否是真的很像快遞搬運工（偷笑.jpg）！

若報警只如初見

隨着業務的發展，咱們發現報警量愈來愈大。通告平臺天天都面臨百萬級的報警量，而這些報警中卻有大量類似、重複的冗餘報警。致使核心報警淹沒在大量冗餘報警中，極易形成報警遺漏。若是遇到骨幹網擁塞或數據中心故障，那報警量就須要再加幾個數量級，這就是傳說中的報警風暴，風暴期間運維人員的手機、郵箱迅速會「爆」掉，聽說之前有人根據報警短信的響鈴頻率來判斷故障是否恢復，無論這是真事仍是笑談，他的囧境可見一斑。

所以，報警收斂成爲了監控報警領域面臨的一個共同命題。目前，業界通常的策略是分析報警內容，按照相同關鍵字進行報警合併。這種策略每每效果不好，由於事實上不少關聯報警的內容自己並不包含相同關鍵字。針對這一問題咱們逐漸演化出兩類策略：

1. 分維度報警合併策略，即按照報警維度屬性（機房、機器、實例、服務等）合併。

2. 基於關聯挖掘的合併策略，即採用離線數據挖掘或機器學習的方式，從歷史報警中挖掘出具備關聯關係的監控策略，而後將相關聯監控策略下的報警進行合併。

通過以上的合併策略後，咱們的報警量減小了九成以上，有效地減小了冗餘報警對運維人員的干擾。對報警合併算法感興趣的朋友能夠參考咱們的以前的專題文章《我在百度對抗報警風暴》詳細瞭解呦！

優雅的外表

通過合併後的多個報警，如何友好展現是另外一個隨之而來的問題。若是把原始報警內容堆疊到一塊兒展現的話，用戶將很難理解。毫無疑問，須要對這些原始報警的內容進行抽象歸納以友好顯示。咱們將這一過程稱之爲「報警渲染」。舉個例子，在一個服務集羣下配置監控策略Rule_A，該策略下在一個短時間時間窗口內共有110條報警, 如圖所示:

通過報警合併，最終渲染爲一條報警，展現以下：

從最終的報警內容中，運維人員能夠快速瞭解報警的嚴重程度、觸發報警的監控策略、影響範圍、報警時間等信息。咱們針對不一樣的合併策略分別有不一樣的渲染模版，目的就是讓運維人員能快速準確地獲取到報警信息。另外，對於電話報警，渲染邏輯要更加複雜些，由於報警是以語音的形式觸達用戶的，受TTS技術所限，很難把形如「pr-nginx_xxx_pv_rule」的策略名，經過電話語音播報給用戶，即便播放出英文讀音，也會讓人莫名其妙，所以咱們定義了若干簡化的語音模板，只播報核心概要內容，同時提醒用戶關注短信、郵件等其餘渠道獲取報警詳情。

7*24值班也能睡個安穩覺

剛剛咱們聊了報警風暴問題，它每每是由機房級故障或者網絡故障觸發大量的冗餘報警致使的。而實際上咱們觀察到還有一個問題一樣能帶來報警冗餘——那就是報警接收人配置過多。不少業務線將多個運維成員都配置到報警接收人裏，而實際上運維人員是輪流值班的，非值班人員徹底沒有必要接收這些報警，這也形成了資源浪費。所以，咱們集成了值班功能，支持設置值班週期、交接班時間、值班提醒，多種值班角色，天天動態地將報警發送給值班人，這減小了一大批冗餘報警。

另外，爲了確保核心報警能獲得及時響應並有效解決，咱們引入了「報警升級」，即一個報警若是沒有在限定時間內獲得處理的話，那麼該報警將自動升級到更高一級的接收人那裏。看個示例，以下圖：

報警發送給值班人後，若是該值班人在2分鐘內沒有認領或者在10分鐘以內沒有處理完成，則自動把該報警發送下一級接收人，如圖中的yunxiaolin, yunxiaobo，並直接發送電話報警；若是他們在10分鐘以內沒有認領或者20分鐘以內沒有處理完成該報警，則繼續升級到下一級接收人，如圖中的yunxiaoyu。值班人收到報警後要回復正確的指令來「認領」或「完成」該報警，咱們藉此來判斷該報警是否繼續升級。假如你認爲報警足夠重要的話，你能夠設置多級升級，甚至到「廠長」！（偷笑.jpg）

總結

今天咱們一塊兒聊了百度雲Noah通告平臺遇到過的溝溝坎坎，有如何發報警的基礎問題，有報警風暴時報警壓縮、報警渲染的難點問題，也有咱們在on-call輪值和報警升級場景下的思考。做爲報警的「搬運工」，咱們始終相信「簡單」的事也能夠作得不一樣！但願咱們的努力能讓運維兄弟們過得更輕鬆一點，幸福一點。

目前平臺還在持續進化中，歡迎你們積極留言共同交流！

原文連接地址：https://developer.baidu.com/topic/show/290333