一文看懂Prometheus告警原理及过程

2024-01-02 13:33:20

目录

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分钟推送一次)

文章来源:https://blog.csdn.net/m0_58476313/article/details/135336755
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。