解决什么问题
界面上点出来的配置是「黑洞」：没人知道线上实例里有哪些数据源、这些配置怎么来的、换一套环境怎么复现。Provisioning（预置配置）的思路是让文件成为唯一事实：数据源、仪表盘、告警规则都写成 YAML 或 JSON，进版本库、可评审、可回滚。
目录结构
包安装的默认位置在 /etc/grafana/provisioning/，容器内路径相同：
/etc/grafana/provisioning/
├── datasources/ # 数据源定义(YAML)
├── dashboards/ # 仪表盘 provider 定义(YAML)+ 仪表盘 JSON 文件
├── alerting/ # 告警规则与通知策略
└── plugins/ # 插件配置目录下可以放多个 YAML 文件，Grafana 会全部加载——按团队或环境拆分文件，比全部挤进一个文件更易维护。
数据源 YAML 示例
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus:9090
isDefault: true
editable: falseeditable: false 会让界面上的删除按钮失效，防止有人手滑把基础设施删掉。字段含义与界面选项的对应关系，见数据源概念与管理。
仪表盘：provider 加 JSON 文件
provider 告诉 Grafana「去哪里、多久扫一次仪表盘文件」：
apiVersion: 1
providers:
- name: platform
orgId: 1
folder: Platform
type: file
updateIntervalSeconds: 30
allowUiUpdates: false
options:
path: /etc/grafana/provisioning/dashboards/json
foldersFromFilesStructure: true把导出的仪表盘 JSON 放进 json/ 目录即可；foldersFromFilesStructure: true 会让目录结构直接映射成界面里的文件夹。仪表盘本身怎么写，见创建与管理仪表盘。
与手工修改的共存取舍
| 场景 | 行为 | 建议 |
|---|---|---|
| 文件改了 | 数据源需重启加载；仪表盘按 updateIntervalSeconds 自动刷新 |
用 Git 提交驱动变更 |
| 界面上手改 provisioned 仪表盘 | allowUiUpdates: false 时无法保存原处，只能「另存为」副本 |
保持 false，改完导出回仓库 |
| 界面上删 provisioned 数据源 | editable: false 时禁止 |
通过删文件加重启来下线 |
| 删了文件 | 对应对象随文件消失，引用它的仪表盘报错 | 下线走评审，别直接 rm |
提示： 排障时临时在界面上手搓一个仪表盘很常见，正确姿势是立刻 Export JSON 存进 provisioning 目录，让临时变长期。
容器与 Kubernetes 里的用法
Docker 下把整个目录挂载进去：
docker run -d --name grafana -p 3000:3000 \
-v "$PWD/provisioning:/etc/grafana/provisioning" \
grafana/grafana-oss:12.1.0Kubernetes 下更常见的做法是把每个 YAML 做成 ConfigMap，由官方 Helm Chart 的 sidecar 自动发现，见Kubernetes 与 Helm 部署。
常见坑
- YAML 缩进错：列表项差一个空格就静默不加载，日志里会留下线索，见日志、诊断与服务器管理。
- 改数据源忘重启：数据源文件只在启动时加载，不像仪表盘有轮询。
- 同名冲突：provisioned 数据源与界面手动创建的同名数据源会互相打架，统一由文件管理。
下一步
- 数据源管理概念：数据源概念与管理。
- 仪表盘 JSON 从哪来：创建与管理仪表盘。
- 配置项与变量基础：配置文件 grafana.ini。