对alertmanager 告警有延迟的理解

目录

1. prometheus

2. 告警状态

3. 告警规则for 即持续时间

4. 例子

5. alertmanager 

---

https://pracucci.com/prometheus-understanding-the-delays-on-alerting.html

1. prometheus

告警评估时间周期: evaluation_interval  默认1m

metrics收集周期: scrape_interval 默认1m

2. 告警状态

inactive   既不触发告警也不是挂起状态

pending  已经处于激活状态，但是激活时间小于配置的阈值持续时间

firing      已经处于激活状态并且激活时间超过阈值持续时间

3. 告警规则for 即持续时间

没有设置for，达到满足告警阈值的时候则是立即触发firing；

有设置for，经历evaluation_interval间隔后由inactive转换成pending，再经历evaluation_interval间隔后由pending转换成firing， 因此至少需要2倍的evaluation_interval ，告警才会触发

4. 例子

以节点的负载大于20为例，相关配置如下

prometheus
scrape_interval : 20s

evaluation_interval: 1m

告警规则

ALERT NODE_LOAD_1m
  IF load > 100
  FOR 1m

Q: 触发负载 > 20 需要花费多长时间？

A: 花费时间在1m ~ 20s+1m+1m之间。

1. prometheus每20s收集一次
2. 设置的告警规则，prometheus每1m评估一次

3. 当告警表达式满足告警触发条件时(load > 20)，由于设置了for:1m, 告警状态由inactive转pending

4. 在下一轮的evaluation_interval, 如果表达式依旧满足(load > 20)，由于设置了for:1m， 此时告警状态由pending转firing，此时告警由推送到alertmanager

5. alertmanager 

group_by: [ 'a-label', 'another-label' ]
group_wait: 30s  当一个新的告警触发时，这个告警要等待group_wait的时间直到调度通知。alertmanager会缓存改通知达30s。

group_interval: 5m 当下一轮的evaluation_interval触发了相同组内的其他告警，此时就不会再等待group_wait时间，而是等待group_interval， group_interval从上次发送通知的时间开始计算。