Grafana as Code - Terraformによるダッシュボードとアラートの構成管理 @ HashiTalks:Japan 2025

Transcript

2. クラスメソッド株式会社 産業支援グループ 製造ビジネステクノロジー部 エンジニア（バックエンド・インフラ） Terraform > EKS(k8s) > 生成AI(Bedrock), サーバーレス(AWS) Hashicorp Ambassador 2023〜2025 ブログ: https://dev.classmethod.jp/author/kazue-masaki/ 自己紹介: Masaki Kazue (かずえ)
3. Grafanaリソース(ダッシュボード、アラート)をTerraformを用いて構成管理する際 の、具体的なTips 注意事項 2024年1月〜4月頃に実施したので、情報が古い部分があるかもしれません 本セッションで話すこと 3
4. 1. Grafanaとは 2. プロジェクト背景 3. Terraformを選んだ理由 4. ダッシュボード編 5. アラート編 6. まとめ 目次 4
6. メトリクス、ログ、トレースなどのデータを可視化するためのオープンソースの監視・ 分析プラットフォームです。 主な特徴 多様なデータソースに対応: Prometheus、Elasticsearch、CloudWatch、MySQL など 柔軟なダッシュボード: グラフ、テーブル、ヒートマップなど、様々な形式でデータ を可視化 アラート機能: Slack、PagerDuty、メールなど様々なチャネルに通知 クエリエディタ: データソースごとに最適化されたクエリエディタを提供 Grafanaとは 6
7. 参考: https://grafana.com/ja/grafana/
9. k8s(EKS)上でアプリケーションを稼働 k8sスタックにおける監視・可視化のデファクトスタンダードである Prometheus + Grafana を採用 AWSのマネージドサービス、Amazon Managed Service for Prometheus(AMP), Amazon Managed Grafana (AMG) を採用 Grafanaのversionは9.4 EKS AMP AMG メトリクス送信 クエリ アプリケーション 基盤 メトリクス保存 可視化 プロジェクト背景 9
10. 当初: 構成管理ツールを使わず、UIから各種Grafanaダッシュボードを作成していた アラート追加時に以下を実現したいと考え、構成管理ツール導入を検討 変更履歴を残したい 別環境への横展開(Dev→Stg→Prod)を容易にしたい 構成管理ツール導入の背景 10
12. Terraformの経験はすでに十分あった GrafanaやPrometheus(PromQL)には初挑戦 → 構成管理ツールまで未経験のものを採用するのは辛い Grafanaリソースの構成管理ツールとして、他により強い候補が見当たらなかった Grizzly: アラート系リソースが(おそらく)未対応だった(現在は対応済) Grafonnet: experimentalだった(2025/11現在でも依然experimental) Terraformを選んだ理由 12
14. 前述の通り、すでにダッシュボードはあった grafanaのダッシュボードはJSONで構造化されており、UIでそのJSONを確認でき る このJSONを使ってterraformリソースとしてはダッシュボード ( grafana_dashboard )のみを定義する Tips1: UIで作り込んで、Terraformに取り込む 14
15. クエリのテスト PromQLの動作確認が即座にできる 視覚的フィードバック グラフの見た目をリアルタイムで確認できる UIの方が効率的な理由 15
16. 1. GrafanaのUIでダッシュボードを作成 2. 動作を確認 3. UIでJSONモデルを表示、コピー 4. JSONファイルとして保存 5. grafana_dashboard の config_json にJSONファイルを指定 resource "grafana_dashboard" "main" { folder = var.folder_uid config_json = file("${path.module}/json/main-dashboard.json") overwrite = true } フロー 16
17. (UIではなく、 )Terraformで作り込むのはつらい 17
18. Grafanaのダッシュボード定義JSONには、環境固有のIDが含まれることがあり、こ れが複数環境での管理を困難にします。 問題となる要素 datasource UID（unique ID）: "datasource": {"uid": "abc123xyz"} Tips2: JSON内に固有ID値が入らないようにする 18
19. # 環境固有のUIDを直接参照 "datasource": { "type": "prometheus", "uid": "abc123xyz" } # 環境間で共通のname を指定 "datasource": "AMP" 対策: データソース参照を名前ベースにする 19
20. GrafanaUIからコピーしたJSONをTerraformに組み込む前に、以下の正規表現変換を 実施 "datasource": \{\n( +)"type": "prometheus",\n( +)"uid": "[a-zA-Z]+"\n( +)\}, ↓ "datasource": "AMP", 正規表現での変換 20
22. Terraformで作成したアラート関連のリソースは、GrafanaのUI上で編集できなくな る (※ ダッシュボード系のリソースは可能) Tips3: Terraformで作ったリソースはUIで変更できない 22
23. provisioned ラベルが付いているリソースはUIから編集不可 編集ボタンも非表示 UIでの表示 23
24. 手動変更による設定ドリフトを防ぐための仕様 各アラート系Grafanaリソースは、UI以外から作成した場合その作成方法 (Terraform,APIなど)の情報(provenance)を持っている 同じprovenanceからでないと編集できない なぜ編集できないのか 24
25. provenance? 参考: https://www.google.com/search?q=provenance+%E6%84%8F%E5%91%B3 25
26. disable_provenance = true を追加すれば可能、とドキュメントには書かれている 実は Terraform→UIはいけるらしいけど? 参考: https://grafana.com/docs/grafana/latest/alerting/set-up/provision-alerting-resources/terraform-provisioning/#enable-editing-resources-in- the-grafana-ui 26
27. もしかして: AMG(Amazon Managed Grafana)ではできない? ドキュメントには disable_provenance についての言及は無く、 「UI編集不可」としか 書かれていなかった 実際に試したところできなかった 参考: https://docs.aws.amazon.com/ja_jp/grafana/latest/userguide/v9-alerting-setup-provision.html 27
28. terraform import コマンドや import ブロックが使用可能 ただしコード⇔実際のリソース間に差分があるとreplaceされる → 以降はUIで変更 不可 前述の disable_provenance の値を true / false 変更しても挙動変わらず UI→Terraformはいけた 28
30. 1. UIで作成→インポート の流れで効率化 2. 固有ID値を排除 して環境間の移植性を確保 3. Terraformで作ったアラートリソースはUIで変更不可 という制約を理解する まとめ 今回紹介したTips 30