导读：

交给的项目运转丝滑且无阻客户体验杰出，没有 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 其他特性感兴趣的也可直接到其官网检查相关信息。

参考资料

• prometheus.fuckcloudnative.io/di-yi-zhang…
• yunlzheng.gitbook.io/prometheus-…
• dockone.io/article/100…
• prometheus.io/docs/introd…
• segmentfault.com/a/119000001…
• github.com/iyacontrol/…

作者介绍

兀华，网易云商高档 Java 开发工程师，担任研制与维护云商互客体系与七鱼工单体系中心模块。

相关阅览推荐

• 浅谈运营商通信中台的规划与实现
• 技能干货 | 实时通信服务中的语音解混响算法实践
• 深度分析「圈组」音讯体系规划 | 「圈组」技能系列文章

​