クリックで繋いだデータソースはどこにも残らない

一言でいうと

Grafanaのデータソース・ダッシュボード・アラートは、すべてファイルで宣言できます。クリックで作ったものは、Grafanaのデータベースの中にしか残りません。

なぜ必要なのか

Grafanaを新しく立ててみるとわかります。UIで追加したデータソースは、grafana.db(既定ではSQLite)の中にしかありません。そのファイルが消えると(Podが作り直されたり、ボリュームが削除されたり、別のクラスターへ移したりすると)、データソースもダッシュボードも一緒に消えます。

もっと静かな問題が別にあります。誰がいつこのURLを変えたのか、誰にもわかりません。ある日ダッシュボードが空の画面になり、データソースの設定を開いてみると、アドレスが古いクラスターを指しています。コードレビューも、履歴も、元に戻す方法もありません。運用中の設定が唯一その状態で残っている場所が管理UIなら、それは設定ではなく、ただの記憶です。

どう動くのか

プロビジョニングのディレクトリは3つに分かれています。場所は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です。その1語が、「この設定がどこにあるのか」を分けます。

起動時に1回読み込む

プロビジョニングのファイルを直したのに画面が変わらず、長く悩むことがよくあります。これらのファイルは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が環境をそのまま行き来します。