本文做者:AIOps智能運維架構
做者簡介併發
運小偉 百度高級研發工程師運維
負責百度監控平臺報警子系統的設計和研發,在大規模分佈式系統、運維監控、精準報警等方面具備普遍的實踐經驗。分佈式
乾貨概覽函數
Argus(Noah 監控3.0)是百度內部最大的監控平臺,提供了機器監控、進程監控、日誌監控、遠程監控、自定義監控等多種監控方式。它還支持集羣級別的監控配置和管理,並支持複雜的異常判斷,提供多種途徑的報警手段。設計
圖1 Argus監控系統示意圖日誌
從系統架構層面,Argus主要包括採集、匯聚計算、數據存儲、報警通路和可視化五個主要部分。報警通路除負責異常判斷、報警發送外,還支持報警回調和聯動故障自愈機器人等功能。報警通路目前承載了千萬級實例異常判斷和報警,天天會自動執行數百次故障自愈任務。本篇文章會重點分異常判斷和報警發送兩部分來介紹報警通路的功能。blog
異常判斷進程
判斷規則 事件
異常判斷是報警通路的核心部分,其支持的判斷規則決定了監控報警能力的強大與否,Argus報警通路支持如下兩類判斷規則:
內置的判斷規則:該部分支持四則運算 、邏輯運算以及各類內置函數。例如:metric_a < 99.99% && metric_b < 99.99% 、 abs(metric_c) > 100 等 。
自定義的判斷規則:運維人員可先用腳本編寫異常判斷規則,而後將腳本提交到報警通路,報警通路負責執行腳本併產生報警。該部分適用於比較複雜的異常判斷場景,好比複雜的同環比報警、多維度數據分析等場景。
判斷流程
圖2 異常判斷流程
報警通路在接收到上游發送過來的數據後,首先找到跟數據相關聯的報警配置,而後根據配置的判斷規則進行異常判斷,如知足判斷規則,則產生報警;爲了防止頻繁的抖動報警,報警通路還支持防抖動過濾策略,例如,M個週期中有N個週期的數據被檢測爲異常纔會產生一個報警。另外,報警通路還會將產生的報警事件存儲到運維知識庫,供業務平臺或用戶來查詢和使用。
異常判斷例子
圖3 異常判斷例子
圖3是一個異常判斷的例子,爲判斷某業務在某機房的可用性指標是否達標,報警通路會對該指標的每一個數據點逐一進行異常判斷,若是連續3次都小於99.99%,則產生異常警報;反過來,只有連續3次都大於或等於99.99%,該次故障纔會被斷定爲結束。
異常的自動化處理方案
異常判斷產生的異常除了用於報警發送,還有下面三種自動化處理方案:
腳本回調功能:報警通路支持在異常實例或機器上執行某個腳本的能力。好比當檢測到某個實例異常時,能夠執行此實例上的腳本(如:重啓實例),就能夠在無需人工參與的狀況下自動修復異常的實例。
HTTP回調功能:爲了支持集羣級別的故障處理能力,報警通路還支持HTTP回調功能。報警通路會將報警POST給指定的URL,接收端便可處理集羣下的全部報警,以此來決定是否觸發某個複雜的故障處理動做。
聯動故障自愈機器人:產生的報警還能夠聯動故障自愈機器人,執行相關自愈動做。故障自愈機器人是一款面向感知、決策、執行的故障自愈機器人,相關介紹,詳見以前的公衆號文章《AIOps時代,你準備好了嗎?》。
報警發送
圖4 報警發送流程圖
異常判斷產生的警報,若是想到達運維工程師,還須要通過報警過濾、報警合併、報警渲染三個環節。報警過濾會將運維工程師不但願收到的冗餘警報過濾掉。報警合併會將相關聯的警報合併到一塊發送。報警渲染就是將結構化的警報數據渲染成文本信息,供運維工程師查看。
報警過濾
用戶但願在如下三個場景過濾掉報警,針對這三種需求,咱們提供了相應的功能:
報警屏蔽過濾:運維工程師不但願接收預期內(好比模塊上線期間)的報警,但願能夠臨時過濾掉相關報警。
報警依賴過濾:運維工程師但願只收到產生故障的根因報警(即精準報警),這樣利於快速定位線上問題。好比某臺機器出現故障(因)時,那麼這臺機器上全部實例的報警(果)應該過濾掉,只需給運維工程師發送機器故障的報警。
最大報警次數過濾:若是一個服務持續異常,運維工程師不但願持續收到同一故障的報警,能夠限制最大報警次數。
報警合併
即便有上述報警過濾措施,但在較大規模故障發生時,仍然還可能產生大量的報警,形成報警風暴。所以,咱們須要對同源的報警進行合併發送,一條信息中通常會包含多個相關聯的警報。報警合併的細節詳見本公衆號以前的文章《我在百度對抗報警風暴(一)》。
報警渲染
合併後的報警,會按照默認格式渲染成短信、郵件、語音等,發送給運維工程師。此外,運維工程師也能夠經過配置報警渲染模板,來自定義報警樣式。
總結
本篇文章主要介紹了百度監控平臺報警通路子系統的核心功能,在報警規則、異常判斷、警報自動化處理、報警過濾等方面作了詳細介紹。關於報警通路的實現細節和系統架構,會在後續的文章中介紹,敬請期待。