为什么按这个顺序改配置
Alertmanager 的配置改动直接影响告警能不能送达，所以流程是固定的：先本地校验语法，再对单台实例触发重载并观察日志，确认无误后在集群内逐台推进。集群内各节点配置必须一致，逐台重载期间新旧路由短暂共存属于预期现象，但重要变更应避开值班高峰。
基本信息
| 校验命令 | amtool check-config，改完先跑一遍 |
|---|---|
| 重载接口 | POST /-/reload，需要启动参数 --web.enable-lifecycle |
| 信号方式 | 发送 SIGHUP 也可触发重载 |
| 失败表现 | 重载失败时进程沿用旧配置继续运行 |
重载流程
重载流程
amtool check-config /etc/alertmanager/alertmanager.yml
# 触发热重载（需启动参数 --web.enable-lifecycle）
curl -sX POST http://127.0.0.1:9093/-/reload
# 查看重载日志确认无报错
journalctl -u alertmanager -n 20 --no-pager
# 无 lifecycle 时用信号方式
kill -HUP $(pidof alertmanager)重载方式对比
| 方式 | 条件 | 适用 |
|---|---|---|
| HTTP 接口 | 启动时开启 lifecycle | 脚本化与自动化流程 |
| SIGHUP 信号 | 有进程管理权限 | 未开启 lifecycle 的场景 |
| 重启进程 | 可接受短暂中断 | 配置结构大改后更稳妥 |
操作步骤
- 改配置前备份当前文件，确认版本库里有对应的历史记录
- 先跑 amtool check-config，语法错误在这一步就会被拦下
- 单台触发重载并核对日志，确认没有配置解析或模板错误
- 集群内逐台推进，每台重载后确认路由与抑制行为符合预期
- 变更后在告警面板上确认通知量正常，再结束本次操作
未启用 lifecycle 时 /-/reload 不可用，别误判成配置错误；reload 失败时进程沿用旧配置继续跑，只看 HTTP 返回不够，必须核日志。
排查要点
- 重载后行为没变化，先查日志里是否有解析错误，再确认文件路径与容器挂载一致
- 模板语法错误只在渲染时暴露，改动消息模板后务必发一条测试告警验证
- 集群中某台长期未重载，用各节点配置文件的校验和比对确认版本一致
- 配置放进版本库，回退时用上一个提交的文件，而不是凭记忆改回去