导读：

交付的项目运行丝滑且无阻客户体验良好，没有 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 开发工程师，负责研发与维护云商互客系统与七鱼工单系统核心模块。

基于 Prometheus 精准监控 & 报警实践

导读：