网关严重告警进了普通队列，怎样离线检查Alertmanager路由顺序

Alertmanager子路由通常按顺序匹配，命中后默认停止继续检查同级。宽泛的gateway分支放在前面，可能先接走critical告警；将更具体路由提前，并用amtool离线验证接收器。

画出父子与兄弟路由

路由树不是把所有满足条件的接收器自动相加。排查时从根节点继承设置开始，逐层看匹配条件、顺序和continue。只有标签本身正确，调整树才有意义；例如severity写成Critical与critical是不同值，不能靠移动分支弥补标签不一致。

用合成标签定位首匹配

样本包含fallback、normal与critical三个空接收器，不填写Webhook或邮箱。错误顺序把service=gateway、severity=critical送往normal；修正后送往critical，同时验证warning仍进normal、其他服务落到fallback。amtool的verify.receivers让命令在接收器不符时直接失败。

路由改动的回归输入应覆盖更具体条件、仅命中宽泛条件和完全不匹配三层。这样可以发现把critical提前后误伤warning，或根接收器被意外修改。amtool离线结果只包含接收器选择，生产静默、抑制与分组等待会进一步影响最终通知，不能从路由通过推断消息已经发出。

核对未匹配与缺标签兜底

若业务要求同时通知多个队列，可认真设计continue，但要重新核对最终集合，避免重复通知。本文只执行配置与路由测试，没有启动通知投递；它证明标签到接收器名字的选择，不证明外部接收器凭据、消息格式或真实送达。

适用范围：接收器只用无外部凭据的空演示定义；只运行配置和路由测试，不启动通知投递。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

下载后将amtool加入PATH再执行，程序分别验证错误顺序、修正顺序、普通级别与其他服务四类标签。所有接收器为空定义，所以不会触发外部通知。实际树复杂时可保留这四组，再补充continue需要同时命中的组合；检查命令应验证完整接收器集合，而不仅仅在输出里搜到某个预期名字。

Python3.8以上与官方Alertmanager0.28.1中的amtool。将工具加入PATH，或把AMTOOL设为绝对路径。接收器只有名字，没有通知地址或凭据；程序仅运行配置与路由检查，不发送消息。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对Alertmanager网关告警路由顺序，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（路由默认命中首个子节点后停止；抑制equal中双方缺失标签按空值等同处理。）；一手依据2（Routes小节实际给出amtool config routes test —config.file与—verify.receivers；本地路由测试可不向真实接收器发消息。）。

继续阅读：错误率一直超标告警却迟迟不响，怎样查动态标签重置for计时；一个租户的网关故障为何压住其他租户告警，怎样核对抑制规则equal；聚合层日志与可观测性实践：监控多模型 API 调用。