导读：

交付的我的项目运行丝滑且无阻客户体验良好，没有 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.fuckcloudn…
• https://yunlzheng.gitbook.io/…
• http://dockone.io/article/10034
• https://prometheus.io/docs/in…
• https://segmentfault.com/a/11…
• https://github.com/iyacontrol…

作者介绍

兀华，网易云商高级 Java 开发工程师，负责研发与保护云商互客零碎与七鱼工单系统核心模块。

相干浏览举荐

• 浅谈运营商通信中台的设计与实现
• 技术干货 | 实时通信服务中的语音解混响算法实际
• 深度分析「圈组」音讯零碎设计 |「圈组」技术系列文章

​