Grafana 13.2.0 升级前要处理的三处破坏性变更：Prometheus 鉴权、grafana-prometheus 包与 Zipkin 插件
Grafana 13.2.0 的 CHANGELOG（2026-08-18）里标了三处破坏性变更，方向一致：把原先塞在核心里的能力往外挪。对已经在跑的生产环境，这三条都可能在升级后的第一次查询或第一次构建时直接暴露出来。
Prometheus 数据源移除 azure 与 sigv4 认证（#123089）
原先在 Prometheus 数据源配置里可以直接选 Azure 认证，或者用 SigV4（AWS IAM）对请求签名，签名与令牌获取由核心数据源内部完成。13.2.0 把这两条鉴权路径从核心 Prometheus 数据源中删除。
影响面集中在托管 Prometheus 场景：
- Azure Monitor 托管 Prometheus，数据源用 Azure 认证接入的。
- Amazon Managed Service for Prometheus 或其他 AWS 侧 Prometheus，走 SigV4 签名的。
升级后这类数据源的查询和告警规则评估会鉴权失败，典型表现是 401/403，或签名校验不通过。需要注意配置里残留的鉴权字段不一定被清理，界面看起来还是配好的，但请求已经不再走原来的签名逻辑，所以只看数据源页面判断升级是否安全并不可靠。
迁移方向大致两类：一是在数据源前面放一层网关或代理，由代理侧补鉴权再转发给 Prometheus；二是改用云厂商对应的独立数据源/插件。无论走哪条，先确认告警规则里引用这些数据源的表达式能正常评估，再动生产。
移除 grafana-prometheus 包（#122953、#123035）
这条只影响自己编译 Grafana、编译插件，或者维护内部 fork 的场景。grafana-prometheus 这个包被移除后，任何 import 了这个包路径的代码会在编译阶段直接失败，而不是运行时才报错。
排查方式很直接：在源码和构建依赖里搜包名，把引用点列出来，对照对应的 PR 与目标仓库结构改成新的包路径。如果内部有多个仓库共用这段依赖，改动要一次性推齐，否则会出现部分模块编译通过、部分失败的分裂状态。
Zipkin 从核心插件中移除（#124148）
Zipkin 之前是随核心一起分发的插件，13.2.0 起不再随 Grafana 一起提供。不带额外安装的环境，升级后 Zipkin 数据源会直接消失。
受影响的是把链路追踪接在 Zipkin 上的看板和链路面板：
- 数据源列表里 type 为 zipkin 的条目失去后端。
- 依赖该数据源的 trace 面板、trace ID 跳转链接、Explore 里的 trace 查询会报数据源不存在或查不到数据。
迁移前先把所有 Zipkin 数据源和引用它们的看板列清楚，再决定是装独立的数据源插件，还是把链路数据切到 Tempo/Jaeger 之类的替代方案。如果看板里有从日志跳到 trace 的链接，这部分地址和查询参数要一起改，漏改的话数据源换了、跳转仍然是死链。
同一版本里的两处非破坏性改动
Prometheus 代码编辑器改为在挂载时获取 metric metadata（#121339）。指标名和标签的提示会更及时，代价是打开编辑器时会立即产生一批 metadata 请求，对 Prometheus 侧限流较严的环境需要留意。
Alerting 中 prometheus 与 loki 的 instant 查询改为 range（#118538）。涉及这两类数据源的告警规则语义有变化，升级后建议把相关规则的评估结果回归一遍，确认没有因为查询范围改变而出现漏报或重复触发。
升级前自查
- 列出所有 Prometheus 数据源，逐条确认鉴权方式是否涉及 Azure 或 SigV4，涉及的在非生产环境先跑通替代方案。
- 检查告警规则中引用这些数据源的表达式，确认升级后仍能正常评估。
- 搜索构建代码与依赖中的 grafana-prometheus 引用，确认包路径替换完毕再打包。
- 列出 Zipkin 数据源及其关联看板，确认替代数据源、插件与 trace 跳转链接都已更新。
- 记录 Prometheus 与 Loki 的告警规则，升级后做一次评估结果对比。