vivo 統一告警平臺建設與實踐
作者：vivo 互聯網服務器團隊 - Chen Ningning
一、背景
一套監控系統檢測和告警是密不可分的，檢測用來發現異常，告警用來將問題信息發送給相應的人。vivo 監控系統 1.0 時代各個監控系統分別維護一套計算、存儲、檢測、告警收斂邏輯，這種架構下對底層數據融合非常不利，也就無法實現監控系統更廣泛場景的應用，所以需要進行整體規劃，重新對整個監控系統架構進行調整，在這樣的背景下統一監控的目標被確立。
以前監控被劃分爲基礎監控、通用監控、調用鏈、日誌監控、撥測監控等幾大系統，統一監控的目標是將各個監控指標數據進行統一計算、統一存儲、統一檢測、統一告警、統一展示。這裏不作贅述，後面會出一期 vivo 監控系統演進的文章進一步說明。
上面我們說了監控統一的大背景。以前各個監控系統會各自進行告警收斂、消息組裝等工作，爲了減少冗餘，需要將收斂等工作由一個服務統一做處理，與此同時告警中心平臺也到了更新迭代的階段，這樣就需要建設一個對內部各業務統一提供告警收斂、消息組裝、告警發送的告警平臺，有了這個構想，我們準備將各系統告警收斂能力與告警發送能力下沉，將統一告警服務做成一個與各監控服務解偶的通用服務。
二、現狀分析
對於 1.0 時代的監控系統來說，如圖 1 所示各個監控系統要先進行告警收斂，然後分別和老的告警中心進行對接，才能將告警消息發送出來。每一套系統都要單獨進行維護一套規則，有很多重複功能建設，而實際這些功能具有高度通用性，完全可以建立合理模型對異常檢測服務生成的異常進行統一處理，從而生成問題，然後進行統一的消息組裝，最後發送告警消息。
(圖 1 老監控系統告警流程圖）
在監控系統中一個異常從被檢測出來到最終發出告警有幾個重要概念：
異常
在一個檢測窗口 (窗口大小可以自定義)，一個或幾個指標值達到檢測規則定義的異常閾值，就產生一個異常。如圖 2 所示，檢測規則定義當指標值在一個檢測窗口爲 6 的檢測週期內，有 3 個數據點超過閾值就認爲有異常，我們簡稱這個檢測規則爲 6-3，如圖所示第一個檢測窗口內(藍色虛線筐內) 只有 6 和 7 兩個點的指標值超過閾值 (95)，不滿足 6-3 的條件，所以第一個檢測窗口沒有異常。在第二個檢測窗口內(綠色虛線框內) 有 6、7、8 三個點的指標值超過閾值(95)，所以第二個窗口就是一個異常。
問題
一個連續的週期內產生的所有同類異常的集合，我們稱之爲問題。如圖 2 所示，第二個檢測窗口就是一個異常，同時這個異常也會對應有一個問題 A，如果第三個檢測窗口也是一個異常，那麼這個異常對應的問題也是 A，所以問題和異常是一對多的關係。
告警
當一個問題通過告警系統將消息以短信、電話、郵件等方式告知給用戶時，我們稱之爲一條告警。
恢復
當問題對應的異常不滿足檢測規則定義的異常條件時，就認爲所有異常都恢復了，同時問題也認爲恢復了，恢復也會發送相應的恢復通知。
(圖 2 時序數據異常檢測原理圖）
三、衡量指標
一個系統我們如何衡量它的好壞，如何提升它，如何管理它？管理學大師彼得 · 德魯克曾說 “你如果無法度量它，就無法管理它 (If you can’t measure it, you can’t manage it)”。從這裏可以看出，如果想全面管理提升一個系統，就需要先對它的各項性能指標有一個衡量，知道它的薄弱點在哪裏，找到病症所在才能對症下藥。
（圖 3 運維指標時間節點關係圖）
圖 3 是監控系統運營指標和對應時間節點關係圖，主要體現了 MTTD、MTTA、MTTF、MTTR、MTBF 等指標與時間節點的對應關係，這些指標對於提升系統性能，幫助運維團隊及早發現問題有很高的參考價值。業界有很多雲告警平臺也很注重這些指標，下面我們着重介紹一下 MTTA、MTTR 這兩個和告警平臺關係緊密的指標：
MTTA(Mean time to acknowledge, 平均應答時間)：
（圖 4 MTTA 計算公式）
-
t[i] -- 監控系統運行期間第 i 個服務出現問題後運維團隊或者研發人員響應問題的時間；
-
r[i] -- 監控系統運行期間第 i 個服務出現問題的總次數。
平均應答時間是運維團隊或者研發團隊響應所有問題所花費的平均時間。MTTA 度量標準用於衡量運維團隊或研發團隊的響應能力和警報系統的效率。通過跟蹤和最小化 MTTA，項目管理團隊可以優化流程，提高問題解決效率，保障服務可用性，提升用戶滿意度 [1]。
MTTR(Mean Time To Repair, 平均維修時間)：
（圖 5 MTTR 計算公式 [2]）
-
t[ri] -- 監控系統運行期間第 i 個服務出現 r 次告警後服務恢復正常狀態的總時間
-
r[i] -- 監控系統運行期間第 i 個服務出現告警的總次數
平均修復時間（MTTR）是修復系統並將其恢復到正常功能所需的平均時間。運維或研發人員開始處理異常，MTTR 便開始計算，並且一直進行到被中斷的服務完全恢復（包括所需的任何測試時間）爲止。在 IT 服務管理行業中，MTTR 中的 R 並不總是表示維修。它也可以表示恢復，響應或解決。儘管這些指標都對應 MTTR，但是它們都有各自的含義，因此，要弄清楚要使用哪個 MTTR，有助於我們更好的分析理解問題。讓我們簡要地看一下它們各自的含義：
1）平均恢復時間 (Mean time to recovery) 是從系統告警中恢復所需的平均時間。這涵蓋了從服務異常導致告警到恢復正常的整個過程。MTTR 是衡量整個恢復過程速度的指標。
2）平均響應時間 (Mean time to respond) 表示從出現第一個告警開始到系統從故障中恢復到正常狀態所需的平均時間，不包括告警系統中的任何延遲。該 MTTR 通常用於網絡安全中，以衡量團隊緩解系統攻擊的效率。
3）平均解決時間 (Mean time to resolve) 表示完全解決系統故障所花費的平均時間，包括檢測故障、診斷問題以及確保故障不再發生來解決問題所需的時間。此 MTTR 指標主要用於衡量不可預見事件的解決過程，而不是服務請求。
提升 MTTA 的核心是找對人、找到人 [3]，只有在最短的時間內找對能處理問題的人才能有效提升 MTTR。通常在生產實踐過程中我們會遇到“告警氾濫” 的問題，大量的告警出現時需要運維人員或者開發同學去解決，對於應激敏感的同學來說很容易出現 “狼來了” 的現象，只要收到告警就會很緊張，同時當大量的告警信息頻發騷擾我們運維人員，會引發告警疲勞，體現爲不重要的事件太多，最根本的問題較少，頻繁處理普通事件，重要的信息淹沒在汪洋大海中。[4]
（圖 6 告警氾濫問題圖 [5]）
四、功能設計
通過上面兩個重要指標的分析，我們總結出要從告警數量、告警收斂、告警升級等方面着手，減少告警發送的數量，提升告警準確性，最終提升解決問題的效率，降低問題恢復時長。下面我們從系統和功能層面說明如何降低告警量，把真正有價值的告警信息發送到用戶手中。本文也將重點圍繞告警消息收斂進行講解。
從圖 1 中可以看出各個監控系統中都有很多重複的功能模塊，所以針對這些功能模塊我們可以將其抽離出來，如圖 7 所示將告警收斂、告警屏蔽、告警升級等能力統一建設在統一告警服務中。這種架構下統一告警服務與檢測相關服務完全解耦，在能力上具有一定的通用性。例如其它有告警或消息收斂需求的業務團隊想接入統一告警，統一告警要能滿足消息收斂發送的需求，同時也要滿足消息直接發送的需求。統一告警會提供靈活可配置的消息發送方式，提供簡單、多樣的功能滿足各類需求。
（圖 7 統一告警系統結構圖）
4.1 告警收斂
對於告警平臺每天會產生數以萬計的告警，這些告警對於運維或開發人員都需要去分析、甄別優先級、並處理故障。數以萬計的告警如果不加收斂每條異常都發送告警，勢必會增大運維人員的工作壓力，當然也不是所有的告警都需要並且有必要發送給運維人員進行處理。所以我們需要對告警通過多種手段進行收斂，下面我們從四個方面介紹一下如何進行告警收斂。
首次告警等待
當一個異常產生之後我們不會立即去做告警，而是通過等待一段時間纔會去做告警發送，一般這個時間可以通過系統自定義，這個值如果太大就會影響告警延遲，太小不能提升告警合併效果。例如首次告警等待時間爲 5s，當一個服務下節點 1 出現 A 指標異常，5s 內節點 2 也出現了 A 指標異常，那麼發送告警時節點 1 和節點 2 會被合併到一起發送告警通知。
告警間隔
問題在沒有恢復前，系統會根據告警間隔的配置每隔一段時間發送一條告警信息，告警間隔用來控制告警發送的頻率。
異常收斂維度
異常收斂維度用來將同個維度下的異常合併在一起。例如同個節點路徑 A 下，通過同一個檢測規則產生的異常，會在告警發送的時候根據配置的異常收斂維度合併在一起。
消息合併維度
當多個異常收斂成一個問題，在發送告警的時候會涉及到消息合併，消息合併維度就是用來指定哪些維度可以合併。可能這樣理解有些晦澀，我們可以通過圖 8 看一下從異常到消息的轉換過程。
假如一個異常有兩個維度名字和性別，當這兩個異常經過統一告警，我們會根據配置的收斂策略進行合併，從圖中我們可以看到性別被定義爲異常收斂維度，通常異常收斂維度的選擇一定是兩個或兩個以上具有相同的屬性的異常，這樣在消息合併後只取相同屬性的同一個值，對應到示例圖，我們會將 ${sex} 佔位符替換成男。而名字是被定義爲告警合併維度，就表示所有異常中名字是都要展示在消息文本中，所以在消息合併的時候我們會將 ${name} 佔位符對應的信息一一拼接在消息文本中。
（圖 8 消息文本替換示意圖 ）
4.2 告警認領
當出現告警後如果有人認領了該告警，那麼後續相同告警只會發送給告警認領人。告警認領主要是爲了解決告警有人跟進後，減少將告警發給其他人員，也能從一定程度上解決告警被重複處理的問題。被認領的告警可以取消認領。
4.3 告警屏蔽
對於同一個問題，可以設置告警屏蔽，後續如果有該問題對應的告警產生，那麼將不會被髮送出去。告警屏蔽能減少故障在定位解決過程中，或者服務在發版變更過程中造成的告警，能有效減少無效告警對運維人員造成的困擾，屏蔽可以設置爲週期性的，也可以設置爲屏蔽某一時段，當然也可以取消屏蔽。
4.4 告警回調
當告警規則配置了回調，那麼當產生告警，就會調用回調接口，使服務或業務恢復正常。告警回調的目的是當某個服務有告警產生，希望系統能夠通過一些自動化的配置，使服務恢復到正常狀態，縮短故障恢復的時間，也能夠緊急情況下第一時間快速恢復服務。
4.5 誤告標註
對於一個問題，用戶可以通過誤告標註備註該異常是否爲誤告警。誤告標註的主要目的是通過標註讓系統開發人員知道異常檢測過程中，哪寫點還需要提升優化，提高告警的準確性，爲用戶提供真實有效的告警提供保障。
4.6 告警升級
當告警發生一定時間仍沒有恢復，那麼系統就會根據配置自動進行告警升級處理，然後將告警升級信息通過配置發送給對應的人員。告警升級一定程度上是爲了縮短 MTTA，當告警長時間未恢復，可以認爲故障沒有及時得到響應，這時就需要更高級別的人員介入處理。
如圖 9 所示，每天告警系統會發送大量的告警，當然這些告警會分別發送給不同服務的告警接收人。告警並不是越多越好，而是應該第一時間準確反映出服務的異常情況，所以如何提升有效告警，提高告警準確性，減少告警量至關重要。通過以上系統設計和功能設計能夠有效減少重複告警發送。
（圖 9 主機監控告警次數圖）
五、架構設計
上面我們從系統和功能層名講解了如何針對老架構下存在的各種問題進行解決，那麼對於這個構想我們應該用一套什麼架構來實現。
下面我們看下如何設計這套架構。統一告警作爲整個監控最後一環，既要滿足告警發送能力也要滿足業務服務發送通知的需求，所以統一告警的各種能力要具有通用性。統一告警服務要做到與其它服務低耦合，尤其是與已有監控系統做到解偶，這樣才能真正把通用能力釋放出來。服務要能做到根據業務場景的不同適配不同的業務邏輯，比如有的業務需要做告警收斂，有的業務不需要，那麼服務要提供靈活的接入方式以適用業務需要。
如圖 10 所示，統一告警核心邏輯由收斂服務實現，收斂服務可以消費 kafka 中的異常，也可以通過 RestFul 接口接收推送過來的異常，異常會先經過異常處理生成一個問題，然後將問題和異常存入 MySql 庫，經過告警收斂模塊問題會被推送到 Redis 延時隊列中，延時隊列會用來控制消息出隊時間，消息從隊列取出之後會進行文本組裝等操作，最後會通過配置發送出去。
（圖 10 統一告警架構圖）
配置管理服務用來管理應用、事件、告警等配置信息，元數據同步服務用來從其它服務同步告警收斂所需的元數據。
六、核心實現
統一告警的核心是告警收斂，收斂的目的就是減少發送重複的告警消息，避免因爲大量的告警對於告警接收人造成告警麻痹。
前文已經說到使用延時隊列做告警收斂，延時隊列在電商和支付項目中使用較多，比如商品下單後 10 分鐘未支付就要自動取消訂單。在告警系統中使用延時隊列主要目的是，在一定的時間內儘可能多的將同一個問題對應的異常合併在一起，減少告警發送的數量。舉個例，如果一個服務 A 有三個節點，當發生異常時，一般情況下每個節點的異常都會生成一條告警發送出去，但是經過告警收斂時候我們可以將三個節點的告警合併，由一條告警做通知。
延時隊列有很多種方式實現，這裏我們選擇了 Redis 實現延時隊列，選用 Redis 延時隊列主要的原因就是其支持高性能的 score 排序，同時 Redis 的持久化特性，保證了消息的消費和存貯問題。
如圖 11 所示，一個問題通過一系列校驗去重之後放入 redis 延時隊列，隊列中到期時間最小的問題會被排到最前面，同時有一個監聽任務不斷查看隊列中是否有過期的任務，如果有過期的任務會被取出，取出的消息會經過消息組裝等操作最終形成一條消息文本，然後根據配置通過不同的通道發送出去。
（圖 11 延時任務執行原理圖 [6]）
七、未來展望
基於統一告警服務定位來看，告警服務要能簡單、高效、準確的告訴運維或者開發人員，哪裏有故障需要去處理。所以對於後續服務的建設，應該考慮如何進一步減少人爲的配置，增強告警智能化收斂的能力，同時還要增強根因定位的能力，以上通過 AI 的加持能夠很好的解決此類問題。目前各大廠商都在向着 AIOps 探索前進，並且已經有一些產品投入使用，但是 AIOps 何時大規模落地，就目前來看還需要一段時間。相較於 AI 的使用，當前最緊迫的就是讓統一告警串聯起上下游服務，從而打通數據，爲數據流轉鋪平道路，增強服務的自動化程度，並且支持從更高維度實現告警發送，爲故障的發現和解決提供更準確的信息。
八、參考資料
[1]What are MTTR, MTBF, MTTF, and MTTA? A guide to Incident Management metrics
[2] 平均修復時間 [Z].
[3] 運維不容錯過的 4 個關鍵指標！
[5] 大規模智能告警收斂與告警根因技術實踐 [EB/OL].
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/PBClxfy6VE06LubszdOHYA