Grafana 13 告警：多通知策略 GA，以及 13.0 里会打断升级的破坏性变更
Grafana 13 在 GrafanaCON 2026 主题演讲公布，self-managed 版本 grafana-v13.3.0 于 2026-09-21 发布。对 SRE 来说，这次告警侧有两条线要分开看：一条是 13.2 起正式 GA 的「多个通知策略」，属于能力升级，可以增量采用；另一条是 13.0 的一批破坏性变更与弃用，升级前需要逐项确认。
多个通知策略：13.1 开关，13.2 GA
Grafana 13.2 起，多个通知策略（Multiple notification policies）在 Grafana 管理的告警中正式 GA。13.1 时它通过 alertingMultiplePolicies 特性开关引入，13.2 转正。
它解决的问题是：可以创建命名的通知策略树，把告警规则指派到某个特定策略，并各自独立管理。现有告警规则除非被显式指派到命名策略，否则继续使用默认通知策略，因此可以增量采用，不必一次性迁移所有规则。
具体好处：
- 把路由逻辑拆成更小的、按团队/服务/域/所有权边界组织的命名树。
- 直接把告警规则指派给应处理它们的策略。
- 通过 Grafana UI、API 或 Terraform 独立地 provision 和管理每个策略。
- 用策略级 RBAC 控制访问。
- 更新一个策略不会影响指派到其它策略的告警的路由配置或通知状态。
路由模型上和原来的区别
Grafana 告警的通知路由模型构建在 Prometheus Alertmanager 之上，路由表示为一个全局通知策略树（顶层 route 与嵌套子 route）。有了多通知策略，每个团队/服务可以有自己的命名策略，而不是只作为全局树里的一个分支。
每个命名策略有自己的 root policy 与子 route；在选定的树内，路由仍按标签匹配、按 route 控制分组/通知时序/contact point 选择。区别在于告警规则现在可以选择由哪个策略处理——策略选择器是告警规则配置的一部分。未显式选择命名策略的规则继续使用默认通知策略，保持现有告警配置的行为不变。
增量迁移步骤
- 为团队/服务/域创建命名策略。
- 在新策略里复现相关路由行为。
- 把该团队的告警规则指派到该策略。
- 验证产生的通知行为。
- 把策略的管理移交给所属团队或自动化流程。
其余规则可以继续留在默认策略上，直到有理由移动它们。这套流程不需要一次切换，可以按团队逐个推进。
13.0 的破坏性变更与弃用
Alertmanager status 端点需要新权限。 GET /api/alertmanager/grafana/api/v2/status 之前需要旧的 alert.notifications:read 权限，现在需要专门的 alert.notifications.system-status:read 权限。这个新权限包含在 fixed:alerting.notifications:writer 角色里，默认授予 Admin 用户。如果用的是自定义角色或自建 RBAC，升级后这个端点会直接返回鉴权失败。
旧的 Alertmanager 配置 API 端点变更。 Grafana v12.0 弃用了一批依赖旧单租户 Alertmanager 配置语义的端点，v13.0 移除或限制了访问。仍在调用这些端点的脚本、Terraform 配置或自研工具需要先迁到新接口。
Grafana 数据库指标弃用。 一批 Prometheus 指标在 v13 弃用，将在未来版本移除。跑 Dashboard 或告警规则依赖这些指标的话，需要在移除前换掉数据源。
告警通知资源的 provenance 支持。 Kubernetes 风格 API 写入时，alerting notification 资源上的 grafana.com/provenance 注解现在会被正确读取并强制执行；此前在所有 K8s API 写入里 provenance 被硬编码为 none，注解被静默忽略。也就是说，之前写了这个注解但没生效的配置，升级后会开始真的生效——如果注解值与实际期望不符，行为会发生变化。