group_by应设为['alertname', 'job']为起点，避免漏告或爆炸；for按场景设5m/2m/30s；静默需完全匹配标签且覆盖group_by字段；reload失败多因文件权限或路径问题。
Alertmanager 的 group_by 怎么配才不漏告、不爆炸
配错 group_by 是告警风暴和关键告警被吞掉的头号原因。它不是“把相似告警合一起”那么简单，而是决定了 Alertmanager 什么时候发一条通知、什么时候拆成多条——底层逻辑是：只有标签集完全一致的告警，才会被归入同一组并共享一个抑制、静默和通知生命周期。
常见错误现象：group_by: ['job'] 导致 50 个 instance 全部崩了，却只收到一条“job=api-server down”，根本看不出是哪台机器挂了；或者反过来，group_by: ['job', 'instance', 'alertname'] 让每条告警都单发，钉钉/邮件刷屏。
- 默认值是
group_by: ['alertname']，实际几乎从不用这个——太粗或太细都危险 - 推荐起点：
group_by: ['alertname', 'job']，再按需加severity或namespace（K8s 场景） - 绝对不要把
instance放进group_by，除非你真要为每台机器单独发通知 - 如果用 Prometheus 的
label_replace做了自定义标签（比如env），记得把它加进group_by，否则同环境不同集群的告警会被强行合并
告警规则里 for 字段设几秒才算合理
for 不是“等多久发告警”，而是“确认这问题真持续存在”。设太短（比如 for: 10s），网络抖动、瞬时采集失败就触发，全是误报；设太长（比如 for: 1h），服务已宕机半小时，你还在等它“稳定故障”。
使用场景差异极大：
- 基础设施类（CPU、内存、磁盘）：
for: 5m是安全起点，能过滤掉大部分毛刺 - 业务 SLI 类（HTTP 5xx 率、延迟 P99）：
for: 2m更合适，业务故障需要更快响应 - 依赖外部系统（DB 连接池耗尽、第三方 API 超时）：
for: 30s可接受，但必须配合annotations里写清“连续 X 次采样失败” - 永远别用
for: 0s—— Alertmanager 会拒绝加载规则，且语义上就是“不确认直接炸”，违背告警设计原则
为什么 silence 静默不了某些告警
静默失效，90% 是匹配逻辑没对上。Alertmanager 的静默是“标签完全匹配”，不是模糊搜索，也不是正则自动补全。
常见错误现象：在 Web UI 里填了 job = "node-exporter" 静默，结果 node_exporter（下划线 vs 中划线）的告警照样来；或者静默了 instance="10.0.1.5"，但告警实际带的是 instance="10.0.1.5:9100"。
- 静默前先查真实告警标签：点开 Alertmanager UI 的 Alerts 页面，点具体告警，看
Labels区域——复制粘贴，别手敲 - 静默必须覆盖所有
group_by标签，否则该告警不会被归入静默组。比如group_by: ['alertname', 'job']，静默就得同时指定这两个 - 时间范围别设错：UTC 时间，不是本地时区；开始时间不能早于当前时间 30 秒（Alertmanager 会拒绝）
- 静默不继承，父级静默（如
job="*"）不会自动覆盖子标签，得显式写job=~".*"
Alertmanager 配置 reload 失败但没报错日志
配置语法没错，curl -X POST http://localhost:9093/-/reload 返回 200，但新规则不生效——大概率是文件权限或路径引用问题，而不是配置本身。
典型表现：改了 route 的 receiver 名，重启后还是旧 receiver；或者新增了 inhibit_rules，但抑制始终不触发。
- 检查
configuration.yml文件是否被 Alertmanager 进程可读：ls -l /etc/alertmanager/config.yml，用户得是运行 Alertmanager 的用户（比如alertmanager） - 确认
global.slack_api_url这类敏感字段没被注释掉但留了空值，会导致 reload 静默失败（日志里只有一行 “loading configuration file” 就停了） - 如果用了
file_sd_configs动态加载路由，注意文件路径是 Alertmanager 进程的相对路径，不是配置文件所在路径 - 最稳的 reload 方式其实是
kill -SIGHUP $(pidof alertmanager)，比 HTTP 接口更可靠，尤其在容器里
复杂点在于：告警规则的生效依赖 Prometheus 和 Alertmanager 两端同步。Prometheus 加了新 rule，但 Alertmanager 没 reload，或者 reload 了但 group_by 不匹配，都会让规则“看起来存在，实际不工作”。盯住两边日志里的 Loaded configuration 和 Received alert 行，比猜强得多。
