版本历史怎么工作
Grafana 每次保存看板都会生成一条版本记录，包含修改人、时间与看板 JSON 快照。版本之间可以对比差异并一键回滚，保存时还能填写变更说明。它的价值不止救回误改的看板，更在于复盘时能还原当时的指标口径与展示方式。
基本信息
| 入口 | Dashboard settings → Versions |
|---|---|
| 记录粒度 | 每次保存生成一个版本，含修改人与时间 |
| 对比能力 | Compare 查看两个版本之间的差异 |
| 回滚 | Restore 回到所选版本，回滚本身也生成新版本 |
操作路径
操作路径
# Dashboard settings → Versions
# - 版本列表与保存时间、修改人
# - Compare：查看两个版本的差异
# - Restore：回滚到所选版本
# 保存时可填 change note，例如：p95 口径改为 5 分钟窗口
# 若看板由 provisioning 管理，UI 改动会随下次同步被覆盖典型使用场景
- 误删面板或改错查询后快速回滚到可用版本
- 复盘时确认当时的口径与阈值，对齐事件时间线
- 多人协作时查看谁改了哪一处，避免互相猜测
- 把关键变更与变更单关联，形成可追溯的看板演进记录
实践建议
| 做法 | 原因 |
|---|---|
| 保存时写变更说明 | 日后能看懂这次改动是为了什么 |
| 关键看板 JSON 入库 Git | 双保险，可做代码评审与批量恢复 |
| provisioned 看板走源文件 | UI 改动会被同步覆盖，避免白改 |
| 回滚前记下当前版本号 | 误操作时可再回到回滚前状态 |
回滚本身也会生成新版本，历史不会被抹掉，出问题时可以放心先恢复服务再慢慢查原因。
版本历史保存在 Grafana 数据库中，迁移实例或重建数据库前先把关键看板 JSON 导出留档。
排查要点
- 看板改动“自己变回去”时，先确认是否由 provisioning 源文件同步覆盖
- 版本列表不更新通常是保存失败或数据库写入异常，结合服务日志确认
- 跨实例迁移后版本记录缺失属正常，迁移前导出 JSON 才是稳妥做法