alertmanager 一触发就发 5 条微信，根本原因是 group_by 未按业务维度（如 alertname、job、severity）配置，导致同一故障被拆分为多个分组重复通知；需调整 group_wait 和 group_interval，验证路由避免多匹配，并确保微信等渠道去重由 alertmanager 层控制。
告警重复发送：为什么 Alertmanager 一触发就发 5 条微信？
根本原因是分组（group_by）配置没对齐业务语义，导致同一故障被拆成多个分组反复通知。比如按 instance 分组，但一个服务跑在多个容器里，每个容器都单独触发告警，又没做聚合，自然刷屏。
实操建议：
- 优先用业务维度分组，比如
group_by: ['alertname', 'job', 'severity']，而不是默认的[... 'instance'] - 检查
group_wait（首次发前等待）和group_interval（后续合并窗口），建议设为30s和5m，避免过早或过久积压 - 确认接收器（
receiver）是否在route多层嵌套中被意外匹配多次——用amtool config routes test验证路由路径 - 微信/钉钉等渠道本身不支持去重，必须靠 Alertmanager 层控制，别指望下游过滤
silence 失效：明明加了静默，告警还在推
静默规则没生效，90% 是因为匹配标签不全或时间范围错位。Alertmanager 要求所有标签完全匹配才静默，少一个 job="api" 或多一个 env="staging" 都会跳过。
实操建议：
- 从告警详情页点「Silence this alert」生成模板，再手动补全缺失标签，别凭记忆手写
- 注意时区：静默时间填的是 UTC，不是本地时间；
amtool默认也用 UTC，用--utc=false可切本地，但 Web ui 始终 UTC - 检查静默状态是否为
active（不是pending或expired），过期时间显示在列表第二列，容易被忽略 - 静默不继承子路由——如果告警进了子
route，而你在父级建的静默，大概率不生效
自定义告警内容：微信消息里怎么带 runbook_url 和实例负载？
Alertmanager 本身不执行查询，所有动态字段都得靠 prometheus 的 annotations 提前注入，或者用 {{ template }} 在通知模板里拼接。直接在模板里调用函数查数据是不可能的。
实操建议：
- 在
alert_rules.yml里把需要的上下文塞进annotations，比如：annotations:<br> summary: "High CPU on {{ $labels.instance }}"<br> runbook_url: "https://wiki.example.com/runbooks/{{ $labels.job }}-cpu-high"<br> value: "{{ $value }}" - 微信模板用 Go text/template 语法，引用注解用
{{ .Annotations.runbook_url }}，别漏掉.Annotations.前缀 - 想带实时指标值（如当前 CPU 百分比），必须在 alert rule 的
expr里用label_replace或vector注入，不能靠模板运行时计算 - 避免在模板里写复杂逻辑——微信消息长度限制严，超长会被截断，且无错误提示
高可用部署下，告警丢了：两个 alertmanager 实例为啥不共享静默和抑制？
Alertmanager 集群模式（--cluster.peer）只同步告警状态和静默，不自动同步配置变更。如果你改了配置但只 reload 了一个实例，或者两个实例启动参数不一致（比如 cluster listen 地址没对齐），就会出现“这个实例收得到、那个收不到”或“静默只在一个上生效”的现象。
实操建议：
- 集群节点必须用相同配置启动，尤其
--cluster.advertise-address和--cluster.listen-address要能互相访问，用netstat -tuln | grep :9094确认端口监听正常 - reload 配置必须对所有实例同时操作，推荐用 systemd 服务文件 +
systemctl reload alertmanager@{1..2}，别手工 curl 单个 - 抑制规则（
inhibit_rules）依赖精确的标签匹配，集群间同步没问题，但若两个实例加载了不同版本配置，抑制可能一边生效一边不生效 - 用
curl http://am1:9093/metrics | grep alertmanager_cluster_查alertmanager_cluster_peers_connected是否为预期数量，这是最直接的连通性证据
配置热加载、静默生命周期、集群脑裂——这些地方没有报错日志，但问题爆发时往往已经丢了几轮告警。盯住 amtool 输出和 /metrics 里的指标，比看 UI 更靠谱。