A Data Source Added by Clicking Is Recorded Nowhere

In one line

Grafana's data sources, dashboards, and alerts can all be declared in files. What you create by clicking remains only inside Grafana's database.

Why this was needed

You find out when you set up Grafana fresh. A data source attached in the UI exists only inside grafana.db (SQLite by default). If that file disappears — the Pod is recreated, the volume is wiped, or you move to another cluster — the data sources and dashboards disappear with it.

There is a quieter problem. Nobody knows who changed this URL and when. One day a dashboard becomes a blank screen, and when you open the data source settings, the address points to the old cluster. There is no code review, no history, and no way to roll back. If the only place where the live configuration remains in that state is the admin UI, it is not configuration but just memory.

How it works

The provisioning directory has three branches. You set its location with GF_PATHS_PROVISIONING.

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

A data source file looks like this.

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

A data source attached this way shows up as "readOnly": true when you look at it through the API. That means it cannot be edited in the UI, and at the same time that the file is the truth. One attached by clicking is false — that single word separates "where does this configuration live."

It is read once at startup

It is common to edit a provisioning file and wander for a long time because the screen did not change. These files are read when Grafana starts. After editing, you start it again, or have it re-read with an admin account.

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

An anonymous request gets a 403 — this endpoint requires server administrator rights, not organization administrator. A dashboard provider has its own updateIntervalSeconds that rescans that directory periodically. So dropping in a new JSON file takes effect without a restart, but when you place a new provider file itself, a startup or reload is needed.

Common misconceptions

"I can create it in the UI and export it later." That "later" does not come. Even if it does, the person who commits the exported JSON has to be there at that time.

"Provisioning means I can't edit it in the UI, which is inconvenient." That is the point. Not being able to edit means there is no way it changes other than editing the file, and only then do the file and the screen not drift apart.

What really matters in practice

Set the data source uid yourself. If you do not write it, Grafana makes one at random, and dashboard JSON refers to a data source by uid, not by name. If the uids differ between the development and production environments, the same dashboard JSON renders on only one side. Half of the dashboard accidents that end in "it works on my screen" are this.

If you pin the uid to the same value in every environment, like prometheus, dashboard JSON moves across environments as is.