告警運維中心｜構建高效精準的告警協同處理體系

• 2022 年 2 月 17 日
• 筆記
• Arms告警運維中心, 雲原生, 監控, 阿里雲

作者：延福

在開始正式內容前，我想跟大家聊一聊為什麼要做告警平台。

隨著越來越多企業上雲，會用到各種監控系統。這其中，用 Skywalking 做 tracing，Prometheus 做 matches，ES 或者雲上日誌服務，做日誌相關監控，隨便算算就至少有三套系統了，這其中還不包括雲監控等雲平台自身的監控平台。這麼多監控平台如果沒有統一配置告警的地方，就需要在每個系統中都維護一套聯繫人，這會是一個複雜的管理問題。與此同時，會非常難以形成上下文關聯。比如，某一個介面出現問題，那可能雲監控的撥測在報警，日誌服務的日誌也在報警，甚至 ARMS 應用監控也在報警。這些報警之間毫無關聯，這是在雲上做告警雲很大的痛點。

其次無效告警非常多。什麼叫無效告警？當業務系統出現嚴重故障時，關聯繫統也可能出現相關告警。而且關聯告警會非常多，進而將關鍵資訊淹沒在告警海洋中，導致運維人員沒辦法及時對告警進行處理。最後，現在很多報警經常發生，但是沒有人處理，就算有人處理了，但處理情況怎麼樣，關鍵性告警從發生到修復的時間到底有多長，每天有多少人在處理，企業的 MTTR 能不能算出來？這也是我們要做統一告警平台要解決的問題。

為了解決以上三個問題，ARMS 的智慧告警平台應用而生。

首先，集成了眾多監控系統包括 ARMS 本身的應用監控、雲監控、日誌服務等十幾家監控系統，並提供開箱即用的智慧降噪能力。同時，為了更高效的協作，整個協同的工作流都可以放在釘釘、企業微信等 IM 工具上，用戶可以更加便捷的去處理和運維相關的告警。最後，提供告警分析大盤幫助用戶來分析告警是不是每天都有人在處理，處理情況是什麼樣的。

告警要在腦海里形成抽象的概念，到底分成哪些步驟？

第一、從事件源產生告警事件，事件是告警發送之前的狀態。事件並不會直接發送進來，它需要和告警的聯繫人匹配完成以後，才能生成告警流程。這張圖簡單的介紹了告警的過程。這也是很多同學用系統時候會經常出現的問題：配置了事件，卻不知道怎麼樣產生告警。必須要事件加聯繫人才能產生告警。

第二、很多同學用的告警系統默認沒有接入。我們也提供了靈活告警事件源的接入方式。可以按照自定義的接入方式，將事件傳進來，我們來清洗欄位，最後接入形成告警平台可以理解的告警。

工單系統舉例，希望系統里產生很重要的事件也往告警平台去傳時，可以把工單系統的報警事件通過 webhook 的方式發送到告警平台。識別並設置相關內容，再通過電話或簡訊方式通知到相應聯繫人。告警平台本質上是接受事件，把告警團隊相關資訊配到告警平台，幫用戶把事件給這些團隊的聯繫人進行匹配發送。

接下來，展示一下這部分能力是怎麼實現的，在介面上是什麼樣的功能。

首先，打開 ARMS 控制台，拉到最下面告警管理模組。我們可以看到概覽，其中包括大部分接入過程、事件處理流程等等。

現在已經用 ARMS 應用監控的用戶,可以直接在其中先創建一個告警的規則。條件是應用響應時間，調用次數大於一次的時候，它就會產生一個事件。

如果是開源 Skywalking 或其他服務，需要到其中去把告警規則設好，把相應的事件傳遞過來。傳遞進來以後，在報警事件列表裡面就能看到對應報警的事件了。

報警事件發送進來以後。首先會對告警事件進行降噪處理，識別告警目前最多關鍵詞是什麼樣，哪些關鍵詞高度重複，或者哪些內容是高度匹配的。同時，根據我們給出的關鍵詞進行壓縮。比如，不希望能收到來自於測試環境的告警，可以把「測試」這兩個字作為屏蔽詞，這樣帶「測試」相關屏蔽詞的功能，告警事件就不會進行二次報警。

告警事件傳遞過來後，整個數據都會放在事件大池子裡面。需要對這些事件進行分配，這個事件到底誰去接收他，誰來對這些事件做通知和排班管理。按照告警名稱或者其他的欄位等在告警裡面預製的欄位去匹配，對 Pod 狀態的異常做匹配，那它會生成告警。

生成告警以後，可以在聯繫人裡面去配置相關聯繫人，其中包括導入通訊錄或配釘釘機器人等等。在通用策略裡面，進一步配置，讓用戶配一個機器人或者真實的人去接受告警。也可以是對工單系統，比如 Jira 等平台裡面去做對接，保證資訊可以傳遞到他們那邊。

配完通知策略以後，一旦產生告警，就可以收到相關的告警了。比較推薦您使用的是通過釘釘來接收相關的報警。

這裡展示一下怎麼樣通過釘釘來接收相關的告警。比如，這是我們接收到釘釘相關告警。在接收到這個告警以後，對這條告警消息，只需有一個釘釘帳號，不需要有理解這些相關資訊，或者登錄到系統，直接對這個告警進行認領。因為和釘釘系統深度集成，可以去認領告警，也可以在認領完以後點解決這條告警。

我們會把過程記錄在活動裡面。用戶就會知道認領和關閉告警的整個過程。同時，每天會針對情況做統計，比如今天發生告警的數量，是否有處理，哪些沒有處理，整體處理情況是怎麼樣的。如果團隊比較大，有非常多運維同學，而且會有 L1 和 L2 分層運維同學的時候，可以使用排班功能進行線上排班。比如，這一周是某個同學接受告警，下一周是另外的同學。同時，也可以做升級策略的排班管理。重要告警在十分鐘內沒有人去做認領時，對重要告警做相應升級。

作為運維主管或運維總監，需要了解每天發生的這麼多告警，經過一段時間後，它是不是有收斂或平均 MTTR 用了這些工具以後，有沒有提升。我們提供了告警大盤，通過這個告警大盤可以了解到每天告警平均響應時間以及大家處理情況。MTTx 相關時間等統計數據會在這個大盤裡面給用戶進行展示，同時這個大盤是集成在 Grafana 上面，可根據實際需求，把相關數據放 Grafana 上，或者您的 Prometheus 數據源裡面做二次的開發。

告警不僅是管理和收集的過程。很多時候雖然發現了告警。在告警處理過程中，阿里雲是否可以提供一些建議參考。對此，我們也提供了相應功能來增強這一塊的能力。

首先，基於類似應用監控的產品，提供一系列默認報警能力。一旦產生相關報警，我們會提供相關診斷能力。在如上圖 20 多種場景下，會提供自動診斷報告。

舉一個例子，應用的響應時間做突增，我們會生成一個直觀的報表。在這個報表中，會告訴你當前突增的原因是什麼。然後會整體的檢測這個應用突增以後到底是哪些因素導致的。一般來說，這個診斷邏輯和普通的診斷邏輯是一樣的。應用突增會去先檢測一下多個主機是不是有突增，然後是不是介面有突增。這些介面如果它響應時間的數據特徵是和整個應用一致，會在進一步分析這個介面裡面到底又是哪些方法有突增，他傳遞的入參是什麼，為什麼有這樣的突增？同時我們也會給出來一些特徵請求告訴用戶，慢的請求是怎樣運行的。

以這個 version.json 介面為例，它是在對應的這個時刻，與應用有類似的突增。主要的核心方法就是這樣一個方法，導致了介面緩慢。

同時我們結合當時打出來的堆棧可以再次確認，當時就是個 handler 方法導致了它的緩慢，那接下來我們就可以結合程式碼進一下進一步的優化了。

這就是 ARMS insight 針對常見問題深入分析的一個 case。基於報告，ARMS 能快速的整合上下文，包括 Prometheus 監控進行監控。還有前端監控的相關數據，都會整合到報告裡面，進行全方位檢測來收斂相關問題。

最後還有一個問題，用戶很關心到底怎麼收費。簡單介紹一下，服務本身雖然存了事件，但是告警事件現在是不收費的，僅收取簡訊、電話、郵件基礎費用。可以理解為是通道費用，不用擔心更多額外費用。

點擊此處，即可觀看直播課程回放！