alertmanager静默需精准匹配标签、严格设utc时间、规范填元信息并验证清理。只屏蔽通知，指标照常采集；用业务标签如job="mysql"，避免全局匹配；时间格式为iso8601 utc（如2026-07-09t12:00:00z）；描述原因、负责人；维护后及时删除或确认过期。
维护期配置告警静默，核心是用 Alertmanager 的 Silence 功能精准屏蔽通知，而不是停监控、删规则或关服务。它只影响告警通知路径，所有指标照常采集、存储、触发，确保事后可追溯。
明确静默范围：靠标签精确匹配
静默生效的前提是标签（labels）能准确命中目标告警。范围越窄越安全，避免误伤其他告警。
- 优先使用业务语义强的标签，如 job="mysql"、cluster="prod-db"、service="payment-api"
- 支持正则匹配，比如 instance=~"10\.0\.1\.(5|6):9100" 或 alertname=~"HighCpuUsage|DiskFull"
- 多个 matcher 是“且”关系，例如同时指定 job="node_exporter" 和 severity="warning"，两者都满足才静音
- 避免宽泛匹配，像 job=~".*" 或不填 matcher，等于全局静默，极易掩盖真实问题
严格设置时间：UTC 时间不可省略
Alertmanager 所有时间字段必须用 ISO8601 格式 UTC 时间（带 Z 后缀），本地时间需手动换算。当前北京时间是 2026-07-09 08:10，对应 UTC 是 2026-07-09T00:10:00Z。
- 维护从今晚 20:00 开始、持续 2 小时 → 起始时间填 2026-07-09T12:00:00Z，结束填 2026-07-09T14:00:00Z
- 时间一旦过期或未生效，Silence 状态会自动变为 expired 或 pending，不会误触发
- 建议提前 10 分钟创建，避免维护刚开始就被告警淹没
规范填写元信息：原因、负责人、可审计
每条静默都应具备上下文和责任归属，这是避免“静默变黑洞”的关键。
- 描述字段写清具体动作和预期，例如：“2026-07-09 DB 主从切换，预计中断 90 分钟，静默 MySQL 连接类告警”
- createdBy 填真实运维账号或轮值组（如 sre-oncall），便于溯源
- 长期静默（>24h）建议同步录入变更系统，实现自动创建+自动过期
- 静默到期前可配置提醒（如邮件/企微），确认是否需延长；未延长则自动恢复通知
验证与清理：别让静默失效或残留
配置完不能只看界面显示 Active，要动手验证效果，并在维护结束后及时清理。
- 手动触发一条匹配条件的告警（如临时调低某条规则的 for=1s，或用 curl 向 Alertmanager API 推送测试告警）
- 检查 Alertmanager UI 的 Silences 列表，确认状态为 Active 且时间窗口正确
- 维护结束后，主动删除该静默规则；若忘记，至少确保其已 expired，不再生效
- 高危告警（如 backup_failed、cert_expires_soon、data_corruption）原则上不应纳入静默范围
