Linux alertmanager 告警规则设计

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 行，比猜强得多。