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

本文轉載自查看原文 2022-04-15 10:05 833 Java

導讀：

交付的項目運行絲滑且無阻客戶體驗良好，沒有 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 其他特性感興趣的也可直接到其官網查看相關信息。

參考資料

作者介紹

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