Grafana 13.1.1 已正式发布。这个版本延续了 Grafana 作为统一可观测性入口的定位：把 Prometheus 指标、Loki 日志，以及 Elasticsearch、InfluxDB、Postgres 等数据源接入同一套查询和可视化界面。此次更新规模不算大，但 Go 版本升级和 Provisioning 的交互改进，仍值得运维团队与平台工程团队关注。
两项明确变化意味着什么
Go 更新至 1.26.5
Grafana 13.1.1 将 Go 版本更新至 1.26.5。对于直接使用官方容器镜像或发行包的团队，这通常不需要修改仪表盘和数据源配置；升级工作主要集中在镜像验证、插件兼容性测试以及运行环境回归。
如果团队自行编译 Grafana、维护二次开发版本，或在内部流水线中构建相关组件，则应同步检查 Go 工具链。可以这样确认本地及容器中的版本信息：
go version
docker run --rm grafana/grafana:13.1.1 --version
不要仅凭服务能够启动就认定升级完成。告警规则计算、数据源查询、插件加载和登录流程，才是更需要回归的路径。
GitHub Provisioning 表单错误提示得到改进
该版本还改进了 Provisioning 场景下 GitHub 连接表单的错误提示。其直接价值不是增加新的连接能力，而是让配置失败更容易定位。对于通过 GitHub 管理仪表盘或配置的团队，更清楚的错误信息可以减少反复检查令牌、仓库参数和连接设置所花费的时间。
这里需要注意边界：错误提示变得更明确，并不代表权限、网络或令牌问题会自动修复。升级后仍应验证 GitHub 凭据的最小权限、有效期，以及 Grafana 到 GitHub 服务端的网络连通性。
用 Docker Compose 搭建最小验证环境
在升级生产实例之前，可以这样实践：启动 Grafana 13.1.1 和 Prometheus，验证容器状态、数据源连接及基本查询。下面的命令会在当前目录创建一个独立测试项目；运行前需要安装 Docker，并确保 3000 和 9090 端口未被占用。
mkdir -p grafana-13-test/prometheus
cd grafana-13-test
cat > prometheus/prometheus.yml <<'EOF'
global:
scrape_interval: 15s
scrape_configs:
- job_name: prometheus
static_configs:
- targets: ["prometheus:9090"]
EOF
cat > compose.yaml <<'EOF'
services:
prometheus:
image: prom/prometheus:latest
command:
- --config.file=/etc/prometheus/prometheus.yml
volumes:
- ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
ports:
- "9090:9090"
grafana:
image: grafana/grafana:13.1.1
environment:
GF_SECURITY_ADMIN_USER: admin
GF_SECURITY_ADMIN_PASSWORD: change-me-now
ports:
- "3000:3000"
depends_on:
- prometheus
volumes:
- grafana-data:/var/lib/grafana
volumes:
grafana-data:
EOF
docker compose up -d
docker compose ps
curl --fail http://localhost:3000/api/health
启动后访问 http://localhost:3000，使用示例中的管理员账号登录。添加 Prometheus 数据源时，容器内部地址应填写：
http://prometheus:9090
保存并测试连接后，可以在 Explore 中运行以下 PromQL，确认查询链路工作正常：
up
测试完成后停止环境：
docker compose down
如果需要同时删除测试数据卷，可执行 docker compose down -v。该命令会永久删除此 Compose 项目中的 Grafana 数据，不应在生产环境中直接使用。
生产升级不要忽略状态数据
Grafana 本身可以通过替换镜像完成升级，但仪表盘、用户、告警、数据源和插件构成了真正的运行状态。采用 SQLite 的单节点安装，应在停写或停机窗口内备份数据库和配置目录；采用外部 Postgres 或 MySQL 的部署，则应按照数据库自身的一致性机制完成备份。
以容器部署为例，可以先记录当前镜像与日志，再执行升级：
docker compose images
docker compose logs --tail=200 grafana
docker compose pull grafana
docker compose up -d grafana
docker compose ps
curl --fail http://localhost:3000/api/health
生产环境不应把管理员密码直接写进 Compose 文件。更合适的做法是使用 Docker Secret、Kubernetes Secret 或现有的密钥管理系统，并限制配置文件的读取权限。
升级检查清单
Grafana 13.1.1 适合按照补丁版本的节奏推进，但仍建议完成以下检查：
- 备份 Grafana 数据库、配置文件和 Provisioning 目录。
- 在预发布环境复现关键仪表盘、告警规则和登录流程。
- 检查已安装插件是否支持目标版本，尤其是第三方数据源和面板插件。
- 验证 Prometheus、Loki、Elasticsearch、InfluxDB 或 Postgres 等实际使用的数据源。
- 使用 GitHub Provisioning 时，主动制造一次无效配置，确认错误提示和排障流程符合预期。
- 升级后观察启动日志、查询错误率、告警执行情况和资源使用量。
- 保留旧镜像与数据库备份，明确回滚步骤和负责人。
这次发布的价值更多体现在基础运行环境和配置体验的打磨。对于已经运行 Grafana 的团队，最稳妥的采用方式不是立即替换生产镜像，而是把真实插件、数据源和 Provisioning 配置带入预发布环境，完成一次贴近生产的回归后再逐步放量。