点出来的数据源，哪里都留不下

一句话总结

Grafana 的数据源、dashboard 和告警全部都可以通过文件声明。点击创建的内容只会留在 Grafana 的数据库中。

为什么需要它

重新搭建一次 Grafana 就会明白：在 UI 中连接的数据源只存在于 grafana.db（默认使用 SQLite）中。一旦该文件消失——例如 Pod 被重新创建、volume 被删除，或迁移到另一个集群——数据源与 dashboard 也会一同消失。

另一个问题更加隐蔽：**没有人知道是谁在何时修改了这个 URL。**某天 dashboard 变成空白，打开数据源设置后发现地址仍指向旧集群。没有 code review，没有历史记录，也没有回退方法。如果运行中的设置唯一存在的地方是管理 UI，那它不是配置，只是记忆。

它如何工作

provisioning 目录分为三类，其位置由 GF_PATHS_PROVISIONING 决定。

provisioning/
  datasources/*.yml   ← 데이터소스 정의 그 자체
  dashboards/*.yml    ← 대시보드 JSON 이 아니라 "어느 디렉터리를 볼지"
  alerting/*.yml      ← 알림 규칙·연락처·알림 정책

数据源文件如下所示。

apiVersion: 1
datasources:
  - name: Lab-Prometheus
    uid: labprom            # ← 직접 정한다. 아래 설명 참고
    type: prometheus
    access: proxy
    url: http://127.0.0.1:9090
    isDefault: true

通过这种方式连接的数据源，在 API 中会显示为 "readOnly": true。这表示它不能在 UI 中修改，同时也意味着文件才是事实来源。点击连接的数据源则为 false——这一个词就区分了“配置究竟存在于哪里”。

启动时读取一次

修改 provisioning 文件后，画面没有变化而排查许久，是常见的情况。**这些文件会在 Grafana 启动时读取。**修改后应重新启动，或使用管理员账户触发重新读取。

curl -XPOST -u admin:admin \
  http://127.0.0.1:3000/api/admin/provisioning/datasources/reload

匿名访问会返回 403——该 endpoint 要求的不是组织管理员，而是服务器管理员权限。dashboard provider 另有 updateIntervalSeconds，会定期重新扫描指定目录。因此，新放入 JSON 文件无需重启即可生效；但新放入 provider 文件本身时，仍然需要启动或 reload。

常见误解

**“先在 UI 中创建，以后再 export 就行。”**那个“以后”永远不会到来。即使真的到来，当时也必须有人愿意把 export 的 JSON 提交到仓库。

“provisioning 后不能在 UI 中修改，很不方便。”这正是它的目的。不能修改意味着除了修改文件之外，没有其他改变配置的途径；只有这样，文件与画面才不会发生偏差。

实际工作中真正重要的事

**亲自指定数据源的 uid。**如果省略，Grafana 会随机生成；而 dashboard JSON 引用数据源时使用的是 uid，不是名称。开发环境与生产环境的 uid 不同，同一份 dashboard JSON 就只会在其中一个环境正常显示。以“在我的画面上能用”收场的 dashboard 事故，有一半源于此。

把 uid 固定为 prometheus 等在各环境一致的值后，dashboard JSON 就可以原样跨环境使用。