从prometheus刮取数据到alertmanager报警发出之间，会经历很多的时间设置，弄清楚这些设置是非常有必要的，可以根据一条报警的紧急程度来设置报警延迟。

---

1. prometheus

1.1. 数据刮取、评估和告警

global:
scrape_interval: 30s
scrape_timeout: 5s
evaluation_interval: 30s

• scrape_interval: 数据刮取间隔时长，默认1m
• evaluation_interval: 该时钟独立于刮取循环，定期评估告警规则，默认1m，在每个评估周期内，prometheus运行每条报警规则表达是并更新报警状态。

prometheus有三种告警状态：

• inactive：既没有触发也没有挂起的警报状态
• pending：低于配置的阈值持续时间的活动警报的状态
• firing：已激活超过配置的阈值持续时间的警报的状态
  警报仅在评估周期内，从一个状态转到另一个状态，如何转换，取决于规则中是否设置for子句

The optional FOR clause causes Prometheus to wait for a certain duration between first encountering a new expression output vector element (like an instance with a high HTTP error rate) and counting an alert as firing for this element.

• 警报没有设置for条款（或设置0）会立即转换到firing
• 带有for子句的警报将首先转换为pending，超过for配置的时间周期后转换到firing，因此在for时间触发警报之前至少需要两个评估周期

1.2. 警报的生命周期

举例说明：
监视一个节点负载1m，在高于20值1分钟的时候触发

ALERT NODE_LOAD_1M
IF node_load1 > 20
FOR 1m

Prometheus配置为每20秒刮取一次度量标准，评估间隔为1分钟

global:
scrape_interval: 20s
evaluation_interval: 1m

那么当负载高于20后，需要花费多长时间状态才会变为firing呢？
答案是大于1m小于20s+1m+1m

看图 1

1. 节点的负载不断变化，但每次都被Prometheus刮掉scrape_interval（即。20s）
2. 然后根据刮取的指标评估警报规则evaluation_interval（即。1m）
3. 当警报规则表达式为真（即。node_load1 > 20）时，警报将切换为pending，以遵守该FOR子句
4. 在下一个评估周期中，如果警报表达式仍为真，则一旦该FOR子句被遵守，警报最终将切换到firing并且通知将被推送到警报管理器

2. alertmanager

2.1. 告警分组

在分配报警通知之前，alertmanager是最后一个环节，当切换到firing或者是inactive的时候，alertmanager会发送告警通知（pending状态不会通知alertmanager）
alertmanager可以将类似的警一起分组到单个通知中，当发生相同类型的多个警报（即，当多个节点上发生相同的警报条件时，我们可能希望仅接收一个将所有节点组合在一起而不是单个通知的通知）。
分组通知的一个缺点就是会进一步引入延迟，配置举例：

group_by: [ 'a-label', 'another-label' ]
group_wait: 30s
group_interval: 5m

当一个警告fired，会等待group_wait时间后派送，这个等待时间用于于最终将匹配相同group_by条件的报警分组。如果两条告警具有相同的group_by标签值则将它们组合在一起。
也就是说，在经过group_wait时间后才将警报正式的发出去。

2.2. 组内新增告警

但是在下一个评估周期中，同一组的进一步报警被触发，它们将不会等待group_wait时间发送，而是等待group_interval时间

# How long to wait before sending notification about new alerts that are
# in are added to a group of alerts for which an initial notification
# has already been sent. (Usually ~5min or more.)
group_interval: 5m

group_interval设置控制在分派同一组的进一步通知之前等待的时间，并且从上次发送的通知开始计算时间间隔。
进一步通知表示有新的报警加入已报警组

2.3. 重复报警

repeat_interval: 1h
当报警发送成功，并且组内没有新增条目，则以repeat_interval时间间隔发送报警直到恢复。

参考：Prometheus: understanding the delays on alerting