我在百度對抗報警風暴（一）

本文做者：AIOps智能運維

做者簡介

運小博    百度高級研發工程師

從事有關運維數據分析相關的工做，負責異常檢測系統和報警收斂等工做，重點關注時序數據分析、故障診斷等相關領域技術。

乾貨概覽

百度監控系統Argus保障了百度內外產品服務的高可用，《我在百度對抗報警風暴》系列文章將會介紹百度高級研發工程師運小博在實踐中如何運用報警合併、機房故障分析、報警關注度分析、值班與逐級通告平臺和報警回調技術等對抗報警風暴。本文將主要介紹報警風暴造成的緣由和報警合併策略中簡單的報警合併策略。

 

Argus名字含義：希臘語「Argus」的意思是「明亮的」、「明察秋毫的」，在古代希臘神話裏面的巨人Argus長有一百隻眼睛，所以能夠觀察到全部方向的事物與動靜；後世以此來比喻機警、機靈的護衛，咱們但願百度監控系統可以如巨人Argus全面洞察異常並報警，故命名爲Argus。

報警風暴

百度監控系統（Argus）是保障百度內外產品服務高可用的利器。小到機器的磁盤是否打滿、虛擬機實例上的進程或端口是否存活，大到產品的流量是否穩定、機房網絡是否聯通，盡在Argus的掌握之中。

兩年前，百度每個運維工程師都被報警風暴所困擾。白天，百度的運維工程師們平均11分鐘就會接收一次短信報警，在夜間則是平均14分鐘一次，而實際數據統計發現，有效短信報警佔比不到15%。所以短信報警的冗餘度是很是高的，已經形成了報警風暴。

通過分析，報警風暴的造成主要有這麼幾個緣由：

報警重複度>58%

分析其緣由，首先報警策略執行週期計算，所以會持續產生重複報警，部分策略甚至會致使持續報警達1小時以上。更嚴重的情形是，一次故障可能引起多個相關策略報警。好比一臺機器死機，首先機器層面報警，而後實例層面報警，接着服務上游也可能會報警。

報警關注度不足

咱們把報警發送後有實際處理的比例做爲報警關注度的度量指標，發現實際關注度並不高，而在夜間短信報警關注率則低至25%。但事實上夜間短信報警的級別通常都是比較高的。這就意味着不少報警策略的發送方式和實際的報警等級已經相違背了。這是由於報警的關注度隨着業務發展發生變化，可是這些關注度的變化沒有及時的在報警系統中修改，致使已經變得不那麼重要緊急的報警，卻還在以短信的形式給值班工程師發送報警。

報警接收人冗餘

每一個報警策略平均有3個接收人，部分報警甚至超過了7個。報警策略的接收人每每會填寫了運維團隊中的全部人，但實際值班人只有一我的，你們按週期輪轉。所以，對於一個特定的報警，大部分同窗是不須要即時關注的。

報警有效性不足

超過88%以上的報警都是單實例報警，40%以上只須要簡單的處理便可恢復，好比磁盤打滿或者內存泄露等。所以咱們在Argus中增長了自愈機制，自愈成功後，報警也就無需繼續發送了。

針對上面的這些問題，咱們在設計Argus時使用了智能報警合併策略、基於報警數據挖掘的機房故障分析、報警關注度分析、值班與逐級通告平臺和報警回調技術等。Argus的功能逐漸完善，並把周級報警短信總量削減了85%。

 

報警合併策略

報警合併對不少作監控的同窗來講並不陌生，大部分介紹報警收斂的文章都提到了這個過程，但大多數說起的報警合併都是將某個時間窗口內的報警簡單的合併成爲一條，此舉對削減報警數量當然有效，但不利於值班工程師進行故障診斷。咱們但願把若干描述同一故障的報警合併在一塊兒，讓值班工程師能夠快速捕捉到故障本質，甚至故障根因，而並不是一味的削減報警量。

在本文中，咱們先介紹一個合併來源於相同報警策略或者相同模塊的重複報警的策略，下一篇文章中將討論如何合併跨模塊、跨策略的報警和一個消除機房網絡故障期間報警風暴的方法，這一方法也能夠用來檢測機房的網絡故障。

 

簡單的報警合併策略

最簡單的報警合併方法能夠基於報警策略的天然屬性，包含策略名或者部署維度等。百度的生產系統使用了虛擬化技術混布各項服務，所以部署的邏輯維度包含了實例、模塊、集羣等層次，物理維度包含機器和機房層次。一個層次同時刻的報警，大多數都存在着必定聯繫，於是能夠將這些報警合併。舉一個實際的例子，A模塊在bj機房部署有100個實例，統一爲每一個實例配置了端口存活報警策略rule1，某個時刻這個策略在0.A.bj（A模塊在bj機房的0號實例）和1.A.bj（A模塊在bj機房的1號實例）上都報警了。這兩個報警屬於同一個模塊的同一個策略，於是能夠合併在一塊兒，便於值班工程師瞭解總體狀況。最終發送的報警樣式以下：

 

{A:instance:rule1}{整體異常實例比例:2%}{異常(2):0.A.bj,1.A.bj}{05-02 16:49:36 - 16:54:09} {http://dwz.cn/… }

簡單介紹一下這條報警的意思：

◤A:instance:rule1表明的是報警策略rule1屬於A模塊，而且是實例級別的報警；

◤整體異常實例比例是使用異常實例數量除以實例總數量計算出來的；

◤0.A.bj和1.A.bj屬於A服務下的兩個異常實例，異常時間段是05-02 16:49:36 到16:54:09；

◤後面有個短鏈，用戶能夠打開短鏈查看更詳細的報警內容。

當合並的內容過多時，咱們將最主要的報警或者報警的總結匯總到短信內容裏面，具體的每一條細節報警、報警起始結束時間、報警持續時間、報警配置內容等細節信息都會在短鏈的頁面中展現。

瞭解了報警合併的策略，接下來介紹一下實際合併的機制。一個報警產生之後，咱們先把這個報警插入一個發送等待隊列而非當即發送。每個報警策略都有一個在等待隊列裏的最長存留時間，換言之，是這條報警能夠容忍的最長延遲發送時間。報警產生後先插入等待隊列裏面去，在隊列裏等進行延遲計時，當達到了可以容忍的延遲時間之後，咱們在等待隊列中找到能夠和該報警一塊兒合併發送的報警，根據實際的合併維度渲染成不一樣的報警短信內容，而後合併成一條報警短信發送。在下面的例子裏，A，B，C表明了3個不一樣的模塊，A模塊上配置了兩條報警策略分別爲rule1，rule2，B模塊上配置了rule3，C模塊上配置了rule4，紅色的報警A:rule1即將到達最長存留時間，按照合併策略，黃色的報警能夠一塊兒合併爲一條發送，這樣實際的報警信息中包含了三條報警。

總結

在今天的故事裏，咱們從多個角度分析了報警風暴的問題，並重點介紹了報警合併技術中簡單的報警合併策略。以後的故事裏咱們會繼續介紹關聯規則的報警合併策略、基於報警數據挖掘的機房故障分析、報警關注度分析、值班與逐級通告平臺和報警回調技術等，請持續關注AIOps智能運維！

若您有其餘疑問或者想進一步瞭解百度監控系統Argus，歡迎留言或評論！

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