alertmanager 是 prometheus 告警链路中不可替代的中枢，需在 prometheus 端配置 alertmanagers 地址并加载规则，在 alertmanager 端配置 route、receivers 和 templates，再通过 ui 和日志验证链路，最后通过高可用部署、抑制规则等提升可靠性。
要让 Prometheus 发出的告警真正“响起来”，必须对接 Alertmanager。它不是可选插件，而是告警链路中不可替代的中枢——Prometheus 只负责“发现异常”，Alertmanager 才负责“通知谁、怎么通知、何时通知、避免重复通知”。
一、Prometheus 端配置：告诉它把告警发给谁
在 prometheus.yml 中添加 alertmanagers 配置段，指向 Alertmanager 实例地址：
- 确保
alerting段已启用，且alertmanagers列表至少包含一个静态目标（如本机） - 示例配置：
alerting: alertmanagers: - static_configs: - targets: ['localhost:9093'] # Alertmanager 默认端口 - 同时需加载告警规则文件，例如：
rule_files: - "rules/host_alerts.yml" - "rules/mysql_alerts.yml"
- 修改后执行热重载：
curl -X POST http://localhost:9090/-/reload（需开启--web.enable-admin-api）
二、Alertmanager 端配置：定义如何处理和分发告警
核心是 alertmanager.yml 文件，重点关注三部分：
-
route：设置默认路由策略，比如按
alertname或severity分组，控制聚合等待时间（group_wait）、重复发送间隔（repeat_interval） -
receivers：声明通知渠道，如邮件、企业微信、钉钉 Webhook。每个 receiver 需有唯一
name，并在 route 中被引用 - templates（可选但推荐）：引入自定义通知模板（.tmpl 文件），统一消息格式，插入实例名、触发值、Grafana 链接等上下文
配置完成后，用 ./alertmanager --config.file=alertmanager.yml 启动，访问 :9093 可查看告警状态与静默界面。
三、验证与调试：确认链路跑通
不要跳过这步——很多问题出在中间环节无声失败：
- 在 Prometheus UI 的 Alerts 页面，确认规则状态为
FIRING（而非INACTIVE或PENDING） - 进入 Alertmanager UI（
:9093），检查 Alerts 标签页是否收到对应告警；若无，说明 Prometheus 未成功推送（查 network 或日志） - 若告警出现在 Alertmanager 但没收到通知，检查 receiver 日志（如邮件 SMTP 连接失败、企微 webhook 返回 404）、
match标签是否匹配路由规则 - 临时加一条测试规则（如
ALERT AlwaysFiring ... expr: vector(1)），快速验证整条链路
四、提升可靠性：几个关键实践
生产环境建议补充以下配置，避免告警“失联”：
- 部署 Alertmanager 至少两个实例，通过
--cluster.advertise-address和 Gossip 协议组成高可用集群 - 在 route 中为关键告警（如
severity=critical）设置独立子路由，指定专属 receiver 和更短的group_interval - 配置
inhibit_rules：例如主机宕机时，自动抑制其上所有服务的告警，避免信息过载 - 定期用
amtool命令行工具静默维护窗口或测试路由匹配逻辑，比手动点 UI 更可控
