클릭으로 붙인 데이터소스는 어디에도 남지 않는다

한 줄 요약

Grafana 의 데이터소스·대시보드·알림은 전부 파일로 선언할 수 있다. 클릭으로 만든 것은 Grafana 의 데이터베이스 안에만 남는다.

왜 이게 필요했나

Grafana 를 새로 세워 보면 안다. UI 에서 붙인 데이터소스는 grafana.db(기본값은 SQLite) 안에만 있다. 그 파일이 사라지면 — 파드가 다시 만들어지거나, 볼륨이 지워지거나, 다른 클러스터로 옮기면 — 데이터소스도 대시보드도 함께 사라진다.

더 조용한 문제는 따로 있다. 누가 언제 이 URL 을 바꿨는지 아무도 모른다. 어느 날 대시보드가 빈 화면이 되고, 데이터소스 설정을 열어 보니 주소가 옛 클러스터를 가리키고 있다. 코드 리뷰도, 이력도, 되돌릴 방법도 없다. 운영 중인 설정이 유일하게 그 상태로 남아 있는 곳이 관리 UI 라면, 그건 설정이 아니라 그냥 기억이다.

어떻게 동작하나

프로비저닝 디렉터리는 세 갈래다. 위치는 GF_PATHS_PROVISIONING 으로 정한다.

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

데이터소스 파일은 이렇게 생겼다.

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

이렇게 붙인 데이터소스는 API 로 보면 "readOnly": true 로 나온다. UI 에서 고칠 수 없다는 뜻이고, 동시에 파일이 진실이라는 뜻이다. 클릭으로 붙인 것은 false 다 — 그 한 글자가 "이 설정이 어디에 있는가" 를 가른다.

기동할 때 한 번 읽는다

프로비저닝 파일을 고치고 화면이 안 바뀌어서 한참 헤매는 일이 흔하다. 이 파일들은 Grafana 가 뜰 때 읽힌다. 고쳤으면 다시 띄우거나, 관리자 계정으로 다시 읽히면 된다.

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

익명 접근으로는 403 이 돌아온다 — 이 엔드포인트는 조직 관리자가 아니라 서버 관리자 권한을 요구한다. 대시보드 제공자(provider)에는 updateIntervalSeconds 가 따로 있어 그 디렉터리를 주기적으로 다시 훑는다. 그래서 JSON 파일을 새로 떨어뜨리는 것은 재기동 없이 반영되지만, 제공자 파일 자체를 새로 놓았을 때는 기동이나 reload 가 필요하다.

흔한 착각

"UI 로 만들고 나중에 export 하면 된다." 그 '나중' 은 오지 않는다. 온다 해도 export 한 JSON 을 커밋할 사람이 그때 그 자리에 있어야 한다.

"프로비저닝하면 UI 에서 못 고치니 불편하다." 그게 목적이다. 고칠 수 없다는 것은 파일을 고치는 것 말고는 바뀔 길이 없다는 뜻이고, 그래야 파일과 화면이 어긋나지 않는다.

실무에서 진짜 중요한 것

데이터소스의 uid 를 직접 정하라. 안 적으면 Grafana 가 무작위로 만들어 주는데, 대시보드 JSON 은 데이터소스를 이름이 아니라 uid 로 가리킨다. 개발 환경과 운영 환경의 uid 가 다르면 같은 대시보드 JSON 이 한쪽에서만 그려진다. "내 화면에서는 되는데" 로 끝나는 대시보드 사고의 절반이 이것이다.

uid 를 prometheus 처럼 환경마다 같은 값으로 고정해 두면, 대시보드 JSON 이 환경을 그대로 넘나든다.