一文看懂Prometheus告警原理及过程
本文详细介绍了如何在Prometheus中自定义告警规则，包括规则构成、Prometheus配置、告警流程以及告警解除的处理方法，特别关注了告警解除后的通知策略。
摘要由CSDN通过智能技术生成
目录
1. 自定义告警规则
2. 告警规则编写
3. prometheus配置
4. 告警过程
5. 告警解除
5.1 对startsAt和endsAt的处理
5.2 Prometheus告警解除后持续多久重复推送告警解除通知？？
1. 自定义告警规则
基于规则告警是指利用已经采集的监控数据，匹配用户自定义的多维度告警规则，如果满足，则触发相应规则的告警。例如，性能告警规则一般是设定某个阈值、触发次数和告警行为，对于 CPU利用率、内存使用量、QPS等性能指标，如果在某个时间段内多次触发该阈值，则将其视为满足告警条件。
2. 告警规则编写
一条报警规则主要由以下几部分组成：
alert：告警规则的名称
expr：是用于进行报警规则 PromQL 查询语句
for：评估等待时间（Pending Duration），用于表示只有当触发条件持续一段时间后才发送告警，在等待期间新产生的告警状态为pending
labels：自定义标签，允许用户指定额外的标签列表，把它们附加在告警上
annotations：指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的。
告警规则示例：
3. prometheus配置
global:
# How frequently to scrape targets by default.
scrape_interval: 30s
# How long until a scrape request times out.
scrape_timeout: 10s
# How frequently to evaluate rules.
evaluation_interval: 1m
alerting:
alertmanagers:
- static_configs:
- targets:
- 172.0.20.1:8088
rule_files:
- ./rules/*.yml
Prometheus以scrape_interval（默认为1m）规则周期，从监控目标上收集信息。其中scrape_interval可以基于全局或基于单个metric定义；然后将监控信息持久存储在其本地存储上。
Prometheus以evaluation_interval（默认为1m）另一个独立的规则周期，对告警规则做定期计算。其中evaluation_interval只有全局值；然后更新告警状态。
4. 告警过程
1、告警流程图
流程描述：
1.Prometheus以5s（scrape_interval）一个采集周期采集状态；
2.根据采集到状态按照10s（evaluation_interval）一个计算周期，计算表达式；
3.表达式为真，告警状态切换到pending；
4.下个计算周期，表达式仍为真，且符合for持续10s，告警状态变更为active， 并将告警从Prometheus发送给alert-manager；
5.下个计算周期，表达式仍为真，且符合for持续10s，持续发送告警给alert-manager。
5. 告警解除
5.1 对startsAt和endsAt的处理
1、两者都存在：不做处理
2、两者都未指定：startsAt指定为当前时间，endsAt为当前时间加上告警持续时间，默认为5分钟
3、只指定startsAt：endsAt指定为当前时间加上默认的告警持续时间
4、只指定endsAt：将startsAt设置为endsAt
即：如果 endsAt 没有提供，则自动等于 startsAt + resolve_timeout(默认 5m)
AlertManager一般以当前时间和告警实例的endsAt字段进行比较用以判断告警的状态：
* 若当前时间位于endsAt之前，则表示告警仍然处于触发状态（firing）
* 若当前时间位于endsAt之后，则表示告警已经消除（resolved）
Prometheus 需要 持续 地将 Firing 告警发送给 Alertmanager，遇到以下一种情况，Alertmanager 会认为告警已经解决，发送一个 resolved：
* Prometheus 发送了 Inactive 的消息给 Alertmanager，即 endsAt=当前时间
* Prometheus 在上一次消息的 endsAt 之前，一直没有发送任何消息给 Alertmanager
当告警没有再此触发时，多久后发送恢复的时间由什么因素决定：告警的endAt来决定。
告警的endAt默认情况下prometheus会设置为以下值来决定：
ts + max([check_interval], [resend_delay]) * 4
resendDelay，是程序启动参数 --rules.alert.resend-delay 规定的，默认 1m
interval，是我们配置的采集间隔
如果收到的告警里没有设置endAt，那么alertmanager设置endAt为以下值来决定：
now + resolve_timeout
即：对活跃告警的默认恢复时间决定为：如果发送方（prometheus等）指定了endAt，则以发送方为准，否则alertmanger统一设置为now + resolve_timeout，即一条告警等待了resolve_timeout还没收到新的告警内容，则视为恢复
5.2 Prometheus告警解除后持续多久重复推送告警解除通知？？
模拟告警解除过程，配置10分钟评估等待时长，
prometheus实际告警解除时间：2023-12-26 16:44:23.995
告警记录的告警解除时间：2023-12-26 16:54:49
prometheus停止推送告警解除通知：2023-12-26 16:58:23.995
结论：Prometheus告警解除后持续12分钟重复推送告警解除通知（间隔2分钟推送一次）
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/m0_58476313/article/details/135336755
