要让prometheus实现基于阈值的自动通知，必须打通“指标采集→告警规则定义→告警触发→通知路由”全链路；核心难点在于promql规则语义正确、alertmanager分组与抑制按业务对齐、通知渠道分级验证及告警生命周期闭环管理。
要让 Prometheus 实现基于阈值的自动通知，核心不是只改 Alertmanager 配置，而是打通「指标采集 → 告警规则定义 → 告警触发 → 通知路由」这整条链路。其中最容易出错的是规则表达式语义、分组逻辑和接收器配置不匹配。
写对 PromQL 告警规则是前提
告警规则必须用 PromQL 表达明确的异常条件，且结果需为标量或向量（不能是空集）。常见误区是直接套用 Grafana 图表里的查询，但图表可容忍部分缺失，告警规则不行。
- 用 rate() 或 irate() 计算速率时，区间必须覆盖至少两个采样点（如
rate(http_requests_total[2m])），否则返回空 - 判断 CPU 使用率超 80%：推荐用
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80，而非简单除法，避免聚合丢失维度 - 避免在规则中硬编码 label 值（如
job="api"），优先用 label_replace 或 relabel_configs 预处理，方便后期维护
Alertmanager 的分组与抑制必须按业务对齐
默认分组策略容易把不同服务的同类告警混在一起，导致误判或漏通知。分组 key 应体现业务上下文，比如按 service、severity 和 cluster 组合，而不是只按 alertname。
- 在
route中设置 group_by: ["alertname", "service", "severity"]，避免“所有 HTTP 错误”被合并成一条告警 - 用 inhibit_rules 抑制衍生告警：例如当
node_down触发时，自动抑制该节点上所有container_cpu_usage告警，防止告警风暴 - 设置 group_wait: 30s（首次等待）和 group_interval: 5m（后续合并间隔），平衡及时性与聚合效果
通知渠道需支持分级与回执验证
邮件、企业微信、钉钉等渠道本身不保证送达，必须结合 Alertmanager 的 repeat_interval 和外部重试机制来兜底。
- 为 P0 级告警配置独立 receiver，使用电话机器人或短信通道；P1/P2 可走企微/钉钉，并开启「已读回执」功能（需对接其 API）
- Webhook 接收器建议加一层轻量网关（如用 Python Flask 封装），用于记录推送日志、失败重试、添加 trace_id 方便追踪
- 测试通知是否生效：用
curl -X POST http://alertmanager:9093/api/v1/alerts手动注入模拟告警，观察接收端是否收到
告警生命周期管理不能只靠配置文件
上线后必须建立闭环机制，否则规则会快速过期或误报。Prometheus 自身不提供告警归档或静默历史，需借助外部工具或自建简易看板。
- 定期清理失效规则：检查
alerts指标中alertstate为inactive且持续超 7 天的规则，评估是否下线 - 对频繁触发的告警，先查
ALERTS_FOR_STATE和ALERTS，确认是真异常还是阈值不合理（如磁盘满告警每小时触发，大概率是清理策略缺失） - 所有规则变更必须走 Git 版本控制 + CI 自动校验（如用
promtool check rules），禁止手工修改生产 Alertmanager 的 rules.yml
不复杂但容易忽略。关键在每一步都验证输出，而不是只看配置是否加载成功。
