Prometheus 加 Alertmanager 的告警群里，一次磁盘维护前建了静默，界面上显示 Active，可十分钟后磁盘使用率的告警照样推送到群里，维护窗口被消息刷屏。
一开始怀疑是「告警是从另一套 Prometheus 发过来的，那套没配这条静默」，查了一圈，方向不对。
这类报错背后常见的原因有几处，逐个排除就行。静默的匹配器只写了 alertname，实际告警带了额外的 instance 标签。另一种情况是静默的开始时间用了本地时区，比 UTC 晚八小时，实际还没进入窗口。
另外，匹配器用了正则但没写锚点，写的是 = 而不是 =~ 导致永远匹配不上。
上来先看静默到底匹配到了哪些告警
amtool silence query --alertmanager.url=http://127.0.0.1:9093再往下按标签逐个核对告警的实际标签集
curl -s 'http://127.0.0.1:9090/api/v1/alerts' | head -40接着用正确的匹配器重建静默
amtool silence add alertname=DiskUsageHigh instance=~'.*node-03.*' --duration=2h末了确认静默状态和生效时间
amtool silence query --within=3h别只看报错消失，验证要多做一步。amtool 里新静默状态为 active，时间窗口覆盖维护时段，触发一次测试告警后群里不再收到 node-03 的磁盘告警。
容易忽略的是，静默时间统一按 UTC 填，界面上显示的本地时间容易看错；维护类静默要把 instance 和 alertname 一起写上，只写一个很容易漏。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。