對於大部分公司，通常都不止一套監控、可觀測性相關的系統，雲上的、雲下的，開源的、商業的，指標的、日誌的、鏈路的，各個系統體驗不同，權限難管，如何統一化併為各個團隊賦能，是很多技術負責人極為頭疼的問題。
要完全推翻現有的體系也不現實，畢竟遷移成本很高，而且誰能保證那些所謂的 all-in-one 的系統一定能在各方面勝出現有的平台？利舊的同時，把體驗和價值提升，或許是個路子。
Grafana 其實是個很好的例子，Grafana 幾乎統一了數據可視化。如果我們再進一步，除了可視化還有什麼可以統一呢？我想應該是告警！一個典型的監控/可觀測性系統，其架構如下：
數據採集方面，確實五花八門，比如指標使用 Categraf、Exporter，Tracing 使用 Otel-Collector，日誌使用 Filebeat，統一的必要性也不大。
數據存儲方面，指標使用 VictoriaMetrics、Prometheus，日誌和 Tracing 使用 ElasticSearch、ClickHouse，解決方案也基本已經固化了。
告警方面，尚有統一優化的空間。首先，我們希望把各個平台的告警統一到一起，做統一的收斂降噪、排班認領升級、靈活的分發。我們做了一個產品來做告警統一，稱為 Flashduty，本文介紹一下 Flashduty 的一些設計理念，希望對你有所啓發。
Flashduty 統一告警的思路
統一告警如果細分，可以分兩個方面，一個是統一事件生成，一個是統一事件分發。
- 事件生成。通常是監控系統來做。監控系統支持用户配置告警規則，然後週期性查詢存儲，對數據做異常判定，進而生成告警事件。
- 事件分發。通常是 OnCall 平台來做，比如國外的 PagerDuty、Opsgenie。對接各個監控系統收集告警事件，然後做統一的收斂降噪、排班、分發等。
統一事件生成
Flashduty 的思路是對接各種存儲，比如 Prometheus、VictoriaMetrics、Thanos、MySQL、Postgres、Oracle、ElasticSearch、Loki、ClickHouse 等，支持用户配置查詢告警規則，然後週期性查詢生成告警事件。
其架構圖如下：
一個公司通常會有多個機房，每個機房有不同的存儲，要對各種存儲做告警，建議在每個機房部署一個告警引擎，避免網絡分區問題。告警引擎從中心同步告警規則，然後查詢存儲做異常數據判定，進而生成告警事件。
下面是一個告警規則列表頁面的樣例，即大家可以在 Flashduty 管理各類告警規則。
除了對接存儲生成告警事件，Flashduty 還提供了一個事件監控小工具，叫 catpaw，catpaw 可以執行一些自定義腳本，對問題現場做檢測，檢測到問題之後直接生成告警事件。catpaw 是開源的，地址是：https://github.com/cprobe/catpaw。
統一事件分發
告警事件散落在各個監控系統裏，不方便處理，不方便量化，而且動不動還有告警風暴，此時就需要一個 OnCall 平台了。
國外有 PagerDuty、Opsgenie 這樣的產品，PagerDuty 估值幾十億美金。很多 SRE 工程師應聘的時候，如果發現僱主公司沒有使用 PagerDuty，直接拒絕入職，因為沒有使用 PagerDuty 的 OnCall 工作，太痛苦，凌晨一個告警，把全組都呼起來，大家都受不了。
Flashduty 類似 PagerDuty，可以對接各類監控系統，收集告警事件，目前已經對接的監控系統如下圖：
整個數據流原理是：監控系統生成告警事件，通過 Webhook 或 Email 的方式發給 Flashduty，Flashduty 即可做後續統一處理。比如：
- 標籤增強。給告警事件附加更多有意義的元信息，方便後續篩選、查看、關聯
- 事件處理。按條件修改告警事件，也可以過濾、抑制告警事件等
- 路由。通過告警事件的屬性、標籤，路由告警事件到特定的協作空間，即路由給特定的團隊
-
分派。協作空間裏，關聯了不同的分派策略，不同級別的告警可以使用不同的通知媒介。
- 分發告警時也可以和值班表關聯，避免所有人受到打擾
- 支持認領、升級策略，確保告警一定被最終處理
- 支持收斂降噪，把多條告警合併為故障，解決告警風暴問題
- 可以和 IM 打通，方便移動端辦公。尤其是晚上睡得朦朦朧朧，移動辦公更是必備
總結
通過統一事件生成和分發，Flashduty 提升了告警的整體體驗，所以新的架構變成了 👇
如果您也想建設類似的平台，可以參考 Flashduty 的做法，或者直接使用 Flashduty，Flashduty 的地址如下：
- 產品介紹：flashcat.cloud/product/flashduty/
- 免費註冊：console.flashcat.cloud
