AlertManager 配置独立于 Prometheus，需手动重载或重启；路由匹配为树状结构，首匹配即终止；邮件需注意 SMTP 端口、TLS、认证及 from 一致性；Webhook 要求支持 POST/JSON 数组解析；静默与抑制规则动态生效，非配置文件管理。
AlertManager 配置文件路径和加载方式
AlertManager 不读取 Prometheus 的配置，它自己有一套独立的 alertmanager.yml，默认不自动重载。改完配置后必须手动触发重载或重启服务。
- 典型配置路径是
/etc/alertmanager/alertmanager.yml，但实际取决于你启动时用的--config.file参数 - 修改后别直接 reload：用
curl -X POST http://localhost:9093/-/reload（需开启--web.enable-lifecycle）；否则只能systemctl restart alertmanager - 配置语法严格，YAML 缩进错误会导致启动失败，错误信息是
yaml: unmarshal errors，不是 JSON 那种明显报错，容易卡在空格上
路由（route）配置为什么收不到告警
90% 的“配置了但没通知”问题出在 route 层级匹配逻辑上——AlertManager 是树状路由，告警从 route 根节点开始逐级匹配，一旦匹配到叶子节点（有 receiver）就停止向下，不会继续找更细的规则。
-
group_by写了[alertname]但告警里没有这个 label？那这条 route 根本不生效，得先看curl http://localhost:9093/api/v2/alerts确认真实 label 键名 -
match和match_re区分字符串完全匹配和正则，比如severity: "warning"要求 label 值**字面等于** warning，大小写、引号都算数 - 全局
group_wait设成 30s，但单条告警发出来后 5 秒就恢复了？那根本等不到聚合，直接走receiver发送，但可能被静默或抑制规则拦住
邮件通知收不到：SMTP 配置关键点
用 email_configs 发邮件最常栽在 TLS、认证和中继限制上，不是配错密码就是被企业邮箱拒收。
-
smarthost别写smtp.qq.com:465就完事——465 要配require_tls: true，而 587 必须配require_tls: false+auth_username明文账号（QQ 邮箱要求 SMTP 开通并用独立密码） -
from地址必须和auth_username一致，Gmail 会校验，否则报错530 5.7.0 Must issue a STARTTLS command或直接静默丢弃 - 邮件内容模板里别直接写
{{ .Labels.alertname }}，如果 label 不存在，整个字段渲染为空，建议用{{ .Labels.alertname | default "unknown" }}
Webhook 接收端收不到 AlertManager 请求
Webhook 不是“配了 URL 就能通”，AlertManager 默认用 HTTP POST 发送 JSON，但很多自建服务默认只接受 GET，或没处理好 CORS / body 解析。
- 先用
curl -X POST http://your-webhook-url -H "Content-Type: application/json" -d '{"test":"ok"}'手动模拟，确认服务本身能收请求 - AlertManager 发的 body 是数组（
alerts: []），不是单个对象，解析时别用json.Unmarshal(&singleAlert)这种单结构体方式 - 如果 webhook 服务跑在内网，AlertManager 容器启动时没加
--network host或没配对的docker network，DNS 和端口都可能不通，错误日志里只会显示context deadline exceeded
AlertManager 的静默（silence）和抑制（inhibit）规则是运行时生效的，不写在配置文件里，得通过 Web UI 或 API 动态管理。很多人调了半天配置，最后发现是某条静默规则把所有 severity=critical 的告警全挡了。
