基於 Prometheus 精準監控 & 報警實踐

語言: CN / TW / HK
時間 2022-04-16 03:15:50

導讀：

交付的專案執行絲滑且無阻客戶體驗良好，沒有 bug 大概是所有鍵盤打工人的夢想。那麼我們能否在客戶感知到 bug 之前就修復掉它，當 bug 產生時如快速的感知並定位到問題，及時進行修復？針對報警的快速感知以及問題定位的命題，我們實施了基於 Prometheus 的精準報警系統，系統包括三部分：日誌平臺、指標系統、報警系統，該解決方案支援指定處理人快速訊息提醒，且報警訊息帶有充分的指標資訊可以快速定位問題範圍。

文｜兀華 網易雲商高階 Java 開發工程師

一、現狀 & 問題定位

大家一定有過報警風暴的困擾，沒有型別區分大量的報警資訊瘋狂湧入，導致處理人員一時之間不能快速確定問題位置，可能會繞幾圈之後才發現原來是某個問題造成的。目前大部分執行的專案中都有監控系統，異常發生時，監控系統會發出統一的報警訊息。如果訊息帶有 traceId，可以 traceId 到日誌平臺或者在 ELK 上檢視具體日誌，上下文資訊等。通常報警資訊會發送給專案組所有人或者專案大群，專案 leader 看到後會 @相關人員進行排查定位分析，定位分析過程所用時間隨問題複雜度成正比，如果遇上報警風暴問題這類定位複雜度高，則耗時更久，這個過程可能已經錯失了有利的補救時間，隨著時間推移，感知到問題的客戶越來越多，影響範圍逐漸擴大。我們的初衷是快速修復問題，這個快速是希望能夠儘可能縮短異常感知時間和定位分析時間，在客戶感知到之前完成修復，儘量不影響客戶體驗。

二、分析 & 方案

定位問題，一般情況下需要以下指標資訊，缺一不可：

​

通常日誌資訊會冗餘一些其他額外的資訊幫助定位排查問題，日誌包含以上資料但不限於此。無論介面是否正常響應，都記載日誌資訊，服務系統每日生成的日誌資料量級可達 T 級別，對如此龐大的資料直接進行處理是不現實的。指標系統存在的意義就是提取一些我們感興趣的關鍵資訊，例如服務記憶體、CPU、GC 狀態等。介面響應碼不是 200 的，或者自定義的系統異常狀態碼，或者其他業務指標等。指標系統是輕量資料的儲存、計算與展示， 展示我們需要的聚合後的資訊，依賴於指標系統我們可以靈活的配置熱點資料展示、趨勢圖、報警等。

​

目前社群較火熱指標系統對比：

​

​

由於報警聚集在 error 或 exception 資訊，或方法上缺少上下文關聯，導致資訊不足以支撐相關處理人儘快做出判斷，其次沒有歸類整理過的報警資訊一股腦的傳送出來只會擾亂當前處理人的資訊整理，尤其當遇上報警風暴的時候，瘋狂的報警容易導致誤判，從而延遲了處理時間。因此，我們需要對錯誤資訊進行收集整理、分類整理，當達到一定閾值時傳送訊息提醒對應業務處理人， 可以是業務組也可以是單人，訊息包含時間、機器、服務、方法、trace、模組、異常型別、異常資訊。報警資訊也可以選擇落庫儲存、統計響應時長、處理時長等。

經過調研我們決定選用開源 Prometheus，Prometheus 包含兩部分：指標系統與報警系統。 同時也提供一些 API 介面。指標儲存支援本地和遠端兩種方式。由於 Prometheus 載入所有資料到記憶體支援資料查詢，一般建議本地儲存資料不超過 15 天，以避免資料過大導致伺服器磁碟不夠用或者記憶體爆掉，資料也可儲存到遠端資料庫，指標資料庫進行支援。

社群遠端儲存支援有：

  • AppOptics: write
  • Chronix: write
  • Cortex: read and write
  • CrateDB: read and write
  • Elasticsearch: write
  • Gnocchi: write
  • Graphite: write
  • InfluxDB: read and write
  • OpenTSDB: write
  • PostgreSQL/TimescaleDB: read and write
  • SignalFx: write
  • Clickhouse: read and write

指標系統支援 PULL&PUSH 的方式。 對於 PULL 方式支援靈活的 job 配置，可以單獨配置目標指標拉取的 REST 介面以及頻率等。Prometheus 支援熱載入，這意味著可以做到遠端修改，且配置實時生效。指標系統與報警系統天然整合， 報警系統支援不同粒度的指標配置、報警頻率配置、標籤等，報警訊息推送支援 slack、釘釘、郵件、Webhook 介面等。由於需要保證線上服務的可用性，一般不會直接開放除業務功能支援外的其他介面，一是容易汙染業務功能，二是為了避免其他功能影響業務功能正常支援以及服務效能。系統日誌一般由其他服務收集儲存，例如 ELK 或其他自研日誌平臺。目前我們採用的是 PULL 模式對接日誌平臺，在日誌平臺開發提供指標拉取介面，架構設計如圖。

​

一般大部分報警資訊傳送是以 service 維度配置負責組，以郵件方式傳送負責人或群訊息形式傳送。國人目前的工作習慣並不是完全依賴郵件，對於郵件資訊提醒感知度還較低，群訊息無指定人時又容易被忽略掉，導致大家對於報警資訊的響應速度大打折扣。另外報警資訊不夠充分時會增加處理人的排查難度進一步降低處理速度。

因此，我們採用 Prometheus alert 方案將報警資訊傳送日誌平臺 Webhook 介面，由日誌平臺根據模組配置資訊選擇最終訊息路由目的地。

完整的執行鏈路如下：

  • 日誌平臺收集日誌，提供指標拉取介面
  • Prometheus 完成指標收集
  • Prometheus 配置報警規則，若規則匹配發送報警資訊
  • Prometheus alert 將報警資訊傳送至日誌平臺提供的報警介面
  • 日誌平臺根據報警資訊帶有的模組、指標名稱等呼叫 Prometheus API 獲取具體指標資訊
  • 日誌平臺根據已有配置，報警資訊的模組、指標標籤選擇負責人或者負責組傳送訊息

至此，完成一次報警的全鏈路流程。

三、實踐

實施步驟如下：

  • 日誌平臺搭建，需要收集介面或者系統日誌。
  • 日誌平臺開放指標拉取介面。

​

​

  • 配置 Prometheus【prometheus.xml】，啟動 Prometheus 程序

採集任務配置如下：

- job_name: 'name'# 自定義採集路徑 metrics_path: '/path' scrape_interval:1800s static_configs: - targets:['localhost:9527']

報警配置如下：​​​​​​​

```

Alertmanager configurationalerting: alertmanagers: - static_configs: -targets: ['localhost:9093']# Load rules once and periodically evaluatethemrule_files: -"rules.yml" -"kafka_rules.yml"

```

報警服務埠 9093 對應 Prometheus alert 服務。

rules 檔案配置如下：​​​​​​​

groups:- name: kafkaAlert rules: -alert: hukeKfkaDelay expr: count_over_time(kafka_log{appname='appname'}[1m]) > 0 labels: metric_name: kafka module: modulename metric_expr: kafka_log{appname='appname'}[1m] annotations: summary: "kafka訊息堆積" description: "{{$value}}次"

  • 由於日誌儲存採用的 Clickhouse 資料庫，啟動 Prometheus2click 程序將指標資料長期儲存在 Clickhouse，遠端配置介面對應 Prometheus2click。​​​​​​​

remote_write: -url: "http://localhost:9201/write"remote_read: -url: "http://localhost:9201/read"

  • 配置 PrometheusAlert，啟動 alter 程序。​​​​​​​

route: group_by: ['alertname'] group_wait: 10s group_interval: 10s repeat_interval: 1m receiver: 'web.hook'receivers:- name: 'web.hook' webhook_configs: - url: '外部報警訊息對接介面'

報警服務接收到的報警資訊來自 Prometheus，包括配置的標籤資訊。Alert 根據頻次、靜默配置等選擇是否將訊息傳送給三方介面。

  • 報警展示&對比
  • 業務報警

​

​

  • Kafka 報警例項

​

​

四、結論

基於 Prometheus 的精準監控與報警，可以有效避免報警風暴，提升線上問題的響應、處理速度，有效降低研發同學排查問題難度。針對不同負責人的靈活訊息推送，有效加快對應負責人的問題感知，及時響應處理問題。Prometheus 自帶的指標收集任務，避免了許多重複的指標收集工作，完美整合報警系統，目前缺點是配置稍顯複雜不夠靈活。

對 Prometheus 其他特性感興趣的也可直接到其官網檢視相關資訊。

參考資料

  • https://prometheus.fuckcloudnative.io/di-yi-zhang-jie-shao/overview
  • https://yunlzheng.gitbook.io/prometheus-book/introduction
  • http://dockone.io/article/10034
  • https://prometheus.io/docs/introduction/comparison/
  • https://segmentfault.com/a/1190000015710814
  • https://github.com/iyacontrol/prom2click

作者介紹

兀華，網易雲商高階 Java 開發工程師，負責研發與維護雲商互客系統與七魚工單系統核心模組。

相關閱讀推薦

​

「」
「」