Prometheus Alertmanager group_interval与repeat_interval配置失效排查

你的核心需求是按memory标签分组告警，新组等待1分钟收集告警后发送，同组通知间隔1天（包含当前及新增告警），但实际通知间隔混乱，主要问题出在路由配置继承、告警标签完整性、子路由continue逻辑这几个方面，具体分析和修复如下：

1. 子路由未显式指定分组规则，可能导致继承异常 #

Alertmanager子路由会继承父路由的group_by配置，但显式配置能避免潜在的继承逻辑问题，确保所有路由都按memory分组。修改所有子路由，添加group_by: ["memory"]：

route:
  receiver: telegram_tech
  group_by:
  - memory
  continue: false
  routes:
  - receiver: telegram_configs
    match:
      route: configs
    continue: false
    group_by: ["memory"]  # 显式指定分组
  - match:
      route: networks
    continue: false
    group_by: ["memory"]  # 显式指定分组
    routes:
    - receiver: telegram_tech
      continue: true
      group_by: ["memory"]  # 显式指定分组
    - receiver: sms
      continue: false
      group_by: ["memory"]  # 显式指定分组
  group_wait: 1m
  group_interval: 1d
  repeat_interval: 1d

2. route: networks子路由的continue: true导致重复通知 #

匹配route: networks的告警会被同时发送到telegram_tech和sms两个接收方，这会让你误以为是两次间隔的通知，但实际上是同一个告警的多渠道推送。如果不需要重复发送，将第一个子路由的continue改为false：

- receiver: telegram_tech
  continue: false  # 改为false，避免同一个告警发送到两个接收方
  group_by: ["memory"]

3. 部分告警缺少memory标签，导致分组混乱 #

如果告警没有memory标签，group_by: memory会被忽略，这类告警会被归为同一个默认组（无分组标签）。当新的无标签告警产生时，若该组之前未发送过通知，会触发group_wait: 1m后发送；若已发送过，则需等待group_interval: 1d。这会导致你看到“几分钟到一天”的间隔差异。

修复方式：

• 检查所有告警规则，确保输出的告警都带有memory标签；
• 若无法添加memory标签，修改group_by为包含其他唯一标识标签（如instance），避免无标签告警归为同一组。

4. 验证group_interval与repeat_interval的逻辑一致性 #

group_interval: 1d控制同组通知的间隔（上次发送后，至少1天才能再次发送该组的汇总通知）；repeat_interval: 1d控制单个持续触发告警的重复通知间隔。两者设置为1天是符合你的需求的，无需修改，但需注意：

• 同组内若有新告警加入，会在group_interval到期后一起发送（包含持续触发的老告警和新告警）；
• 若告警状态变为resolved后再次触发，会重新走group_wait流程。

验证步骤 #

1. 重启Alertmanager加载新配置；
2. 触发一组带有相同memory标签的告警，确认1分钟后收到第一次通知；
3. 1天内触发同memory标签的新告警，确认1天后收到包含新旧告警的汇总通知；
4. 检查无memory标签的告警，确认是否按预期分组或已添加标签。

内容的提问来源于stack exchange，提问作者Arthy Zimmer