脱・野良ダッシュボード：Terraform × Grafana で実現する「オブザーバビリティ・コード化」の神髄
「あ、そのダッシュボード、誰が作ったやつだっけ？」「クエリをいじったらグラフが壊れた…」
Grafanaを運用する現場で、誰もが一度は経験する「Dashboard Sprawl（ダッシュボードの乱立・腐敗）」。GUIでポチポチと作り上げたダッシュボードは、組織の成長と共に「属人化の墓場」と化します。
真のオブザーバビリティとは、観測対象（システム）だけでなく、観測する仕組みそのもの（ダッシュボード・アラート）がバージョン管理され、再現可能であることです。本稿では、Grafanaを単なる「可視化ツール」から「コード化された信頼の基盤」へ変貌させる実践テクニックを伝授します。
—
1. なぜ「ダッシュボードのIaC」が必要なのか
GUIで作成したダッシュボードは、JSON定義の塊に過ぎません。これをGitで管理しないということは、「システムの重要な計器類がバックアップなしの砂上の楼閣の上に置かれている」のと同じです。
- レビューの強制: 変更はすべてプルリクエスト（PR）を通す。これにより、不適切な閾値設定や不要なクエリをリリース前に防げます。
- 環境の一貫性: ステージングと本番でダッシュボードの乖離をゼロにする。
- DR（災害復旧）: クラスタが消滅しても、Terraform `apply` 一発で監視基盤が復活する。
—
2. Terraform × Grafana：理想的なディレクトリ構成
「とりあえず一つのtfファイルに全部書く」のは卒業しましょう。規模が大きくなれば、モジュール分割が必須です。
.
├── modules/
│ └── grafana-dashboard/ # 再利用可能なモジュール
│ ├── main.tf # grafana_dashboardリソース定義
│ └── variables.tf
├── environments/
│ └── prod/
│ ├── backend.tf # S3/GCS等のバックエンド設定
│ ├── provider.tf # Grafanaプロバイダー定義
│ └── dashboards.tf # モジュールの呼び出し
└── .github/workflows/ # CI/CDパイプライン
└── deploy.yaml
実践：ダッシュボードのコード化テンプレート
`grafana_dashboard` リソースを使う際、JSONを直接書くと地獄を見ます。必ず「GUIで作成→JSONエクスポート→整理」のステップを踏んでください。
modules/grafana-dashboard/main.tf
resource “grafana_dashboard” “service_metrics” {
config_json = file(“${path.module}/dashboards/${var.dashboard_name}.json”)
folder = var.folder_id
overwrite = true
# 重要なTips: 変数埋め込みが必要な場合は templatefile 関数を活用する
# config_json = templatefile(“${path.module}/dashboards/template.json”, {
# datasource_name = var.datasource_name
# })
}
—
3. 現場で「震えるほど」役立つプロの極意
① 隠れたキーボードショートカット
Dashboardの編集画面でこれを知らないのは時間の浪費です。
- `Ctrl/Cmd + P`: コマンドパレットを開く（パネルの検索や切り替えが爆速に）
- `E`: 選択中のパネルを編集モードへ
- `I`: パネルの作成（Insert）
- `Ctrl/Cmd + S`: ダッシュボードの保存（これに慣れるとGUIの「Save」ボタンが遠く感じます）
② 絶対入れるべき「神プラグイン」
- [Infinity](https://grafana.com/grafana/plugins/yesoreyeram-infinity-datasource/): JSON APIやCSV、GraphQLを直接クエリできる。これさえあれば、Grafanaの対応外データソースを無理やり自前でインポートする必要がなくなります。
- [Business Charts](https://grafana.com/grafana/plugins/volkovlabs-echarts-panel/): Apache EChartsベース。標準のグラフでは表現できない複雑な相関図やヒートマップを極限までカスタマイズ可能です。
③ アラート定義の「DRY原則」
アラート定義はダッシュボードとは別に管理すべきです。`grafana_rule_group` を使い、チームごとの通知先（Contact Point）をコードで一元管理しましょう。
ポイント: アラートの閾値（Threshold）は `variables.tf` に切り出し、環境ごとに微調整できるようにするのが、大規模運用の鉄則です。
—
4. GitHub Actions による自動デプロイパイプライン
コード化した定義は、GitHub Actionsで自動適用します。
.github/workflows/deploy.yaml
name: Grafana Deploy
on:
push:
paths: [‘environments/prod/’]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Terraform Plan
run: terraform plan
- name: Terraform Apply
if: github.ref == ‘refs/heads/main’
run: terraform apply -auto-approve
ここがプロの分かれ道:
必ず `terraform plan` の結果をプルリクエストのコメントに自動投稿する設定を入れてください。誰が、どのパネルを、どう変えようとしているのかを可視化しないIaCは、単なる「ブラックボックスの自動化」に過ぎません。
—
最後に：オブザーバビリティは「文化」である
Terraformで管理することは手段に過ぎません。真の目的は、「誰が作っても、何が起きても、一貫した情報で迅速に意思決定できる状態」を作ることです。
コード化したダッシュボードをチームでレビューし、改善案をPRとして出し合う。このサイクルが定着したとき、あなたのチームは「監視に追われる」状態から「システムの本質を理解し、価値を生み出す」状態へと進化します。
さあ、GUIから卒業し、Gitの履歴と共に成長するオブザーバビリティ・ライフを始めましょう。