极客工场

Appearance

共 724 字预计阅读约 2 分钟

Prometheus 告警为什么不触发/不通知？ ​

更新时间：2026-09-19。短答页。告警链路是「规则算出 pending/firing → Alertmanager 分组/抑制/静默 → receiver 发出」，任一环节断掉都表现为「没收到告警」，要分段定位。

一句话回答 ​

先在 Prometheus 的 Alerts 页面看规则处于 inactive/pending/firing 哪一档：根本不进 pending 是表达式没数据或阈值不对，firing 了但没收到是 Alertmanager 路由、抑制、静默或通知渠道的问题，再用 promtool check rules 和 amtool 定位。

分段排查 ​

第一段：规则本身（Prometheus）

  1. 表达式直接跑有没有结果：在 Graph/Explore 执行告警 expr，没结果说明标签选择器不匹配、指标没数据或阈值写错。
  2. 状态停在 pending：规则带了 for: 5m，条件必须持续满足才转 firing；中途抖动会重置计时，这是正常抗噪，不是故障。
  3. 规则没加载/语法错：promtool check rules rules.yml 校验；看 Prometheus 的 /rules、配置 reload 是否成功（改了规则要 reload）。
  4. 评估间隔：规则组 interval 太长，最坏要等一个评估周期才看到变化。

第二段：到了 Alertmanager 却没通知

  1. 路由没匹配：告警 labels（如 severity）不符合任何 route，落到默认 receiver 或发去了别处，看 Alertmanager UI 的 grouping/route。
  2. 被抑制（inhibition）：存在更高级别告警、且 equal 标签匹配，目标告警被压制，见 抑制规则。
  3. 被静默（silence）：发布/演练建的 silence 没到期，在 UI 或 amtool silence query 能看到。
  4. group_wait 延迟：同组第一条要等 group_wait（如 30s）攒批，不是立刻发。
  5. receiver 失败：钉钉/企业微信 webhook、邮件 SMTP、token 配置错误，Alertmanager 的通知会报错；多 receiver 时注意各自是否启用。
bash
promtool check rules /etc/prometheus/rules/*.yml   # 规则语法
amtool silence query                               # 生效中的静默
amtool alert --alertmanager.url=http://localhost:9093   # 当前告警及接收状态

坑 ​

  • 用 irate/超短窗口配 for，数据抖动导致永远凑不满持续时间（告警表达式优先 rate，见 rate/irate）。
  • 规则文件改了没 reload，线上还是旧规则。
  • severity 标签值写成 critical 而路由匹配 page，发不到值班渠道。
  • 演练时的 silence 忘记删，告警长期「失明」。

怎么设计低噪告警见多窗口燃烧率与 on-call。

总结 ​

排查告警不触发要沿链路分段：Prometheus 侧用 Alerts 页区分无数据/阈值错（不进 pending）、for 持续时间未满（停 pending）、规则未 reload 或语法错（promtool 校验）；firing 后仍无通知则查 Alertmanager 的 route 标签匹配、inhibition 抑制、未到期 silence、group_wait 攒批延迟和 receiver webhook/SMTP 失败，配合 amtool silence/alert 命令即可快速定位到具体断点。