group

目录

• 官方解释
• • group_wait（default: 30s）
  • group_interval（default: 5m）
  • repeat_interval（default: 4h）
• 实验
• • 参数
  • 告警过程
• 结论
• 补充
• 参考

官方解释

group_wait（default: 30s）

How long to initially wait to send a notification for a group of alerts. Allows to wait for an inhibiting alert to arrive or collect more initial alerts for the same group. (Usually ~0s to few minutes.)
一组告警第一次发送之前等待的时间。用于等待抑制告警，或等待同一组告警采集更多初始告警后一起发送。（一般设置为0秒 ~ 几分钟）

group_interval（default: 5m）

How long to wait before sending a notification about new alerts that are added to a group of alerts for which an initial notification has already been sent. (Usually ~5m or more.)
一组已发送初始通知的告警接收到新告警后，再次发送通知前等待的时间（一般设置为5分钟或更多）

repeat_interval（default: 4h）

How long to wait before sending a notification again if it has already been sent successfully for an alert. (Usually ~3h or more).
一条成功发送的告警，在再次发送通知之前等待的时间。 （通常设置为3小时或更长时间）。

---

实验

参数

group_wait: 10s
group_interval: 30m
repeat_interval: 50m

告警过程

1. alertmanager收到告警后，等待group_wait（10s），发送第一次通知
2. 未达到group_interval（30m 10s），休眠
3. 达到group_interval（30m 10s）时，小于repeat_interval（50m 10s），休眠
4. 到下一个group_interval（60m 10s），大于repeat_interval（50m 10s），发送第二次通知

Firing（0s） - 第一次通知（10s） - 第二次通知（60m 10s）

---

结论

1. 当repeat_interval小于group_interval时，repeat_interval不影响告警
2. 当repeat_interval大于group_interval，且不为group_interval倍数，影响告警
3. 当repeat_interval大于group_interval，且为group_interval倍数，可能影响告警（*注）

注：
当repeat_interval大于group_interval，且为group_interval倍数时，可能发生两种情况：

1. 在repeat_interval时发出告警
2. 在repeat_interval + group_interval时发出告警（原因是如果repeat_interval是group_interval的倍数，则在需要发出通知时会同时判断两个值，程序耗时 + 网络耗时会导致对比结果不准确）

---

补充

根据这篇文章对alertmanager高可用实现的描述：

当AlertManager启动时，它会首先从cluster.peer参数指定的地址和端口进行Push/Pull：即首先将本节点的状态信息（全部的Silence以及Notification Log）发送到对端，再从对端拉取状态信息并与本节点的状态信息合并：例如，对于从对端拉取到的静默规则，如果有本节点不存在的规则则直接添加，若是规则在本节点已存在但是更新时间更晚，则用对端规则覆盖已有的规则。对于Notification Log的做法类似。最终，集群中的所有AlertManager都会有同样的静默规则以及Notification Log。

如果此时用户在某个AlertManager请求增加新的静默规则呢？根据Gossip协议，该实例应该从集群中选取几个实例，将新增的静默规则发送给它们。而当这些实例收到广播信息时，一方面它会合并这一新的静默规则同时再对其进行广播。最后，整个集群都会接收到这一新添加的静默规则，实现了最终一致性。

不过，Notification Log的同步并没有静默规则这么容易。我们可以假设如下场景：由于高可用的要求，Prometheus会向每个AlertManager发送告警实例。如果该告警实例不属于任何之前已有的Alert Group，则会新建一个Group并最终创建一个相应的Notification Log。而Notification Log是在通知完成之后创建的，所以在这种情况下，针对同一个告警发送了多次通知。

为了避免这种情况的发生，社区给出的解决方案是错开各个AlertManager发送通知的时间。如上文的整体架构图所示，Notification Pipeline在进行去重之前其实还有一个Wait阶段。该阶段会将对于告警的通知处理暂停一段时间，不同的AlertManager实例等待的时间会因为该实例在整个集群中的位置有所不同。根据实例名进行排序，排名每靠后一位，默认多等待15秒。

假设集群中有两个AlertManager实例，排名靠前的实例为A0，排名靠后的实例为A1，此时对于上述问题的处理如下：

1. 假设两个AlertManager同时收到告警实例并同时到达Notification Pipeline的Wait阶段。在该阶段A0无需等待而A1需要等待15秒。
2. A0直接发送通知，生成相应的Notification Log并广播
3. A1等待15秒之后进入去重阶段，但是由于已经同步到A0广播的Notification Log，通知不再发送

当集群中排名靠前的alertmanager由于某种原因导致通知发送失败时，后续实例会等待一段时间再尝试发送，此时也会影响最终收到告警的时间。

---

参考

1. 关于 Alertmanager 中 group_interval 与 repeat_interval 上的一些坑
2. issue：Some troubles about group_interval, group_wait and repeat_interval
3. Prometheus告警模型分析
4. alertmanager集群实例Wait阶段时长（很多博客写的是5s，实际为15s，见209行peerTimeout参数）