Grafana Grafana

Grafana をコードとして運用する：全体像

ファイルに置けるもの、API が必要なもの、そしてそれらがどう組み合わさるか。

8 min learn.level.初級

クリックで操作する Grafana は、2 つ目のコピーが必要になったり、ロールバックが必要になったり、「このパネルを誰が変更したのか」という質問に答える必要が出てきたりするまでは、問題なく機能します。このガイドでは、UI ではなくファイルから Grafana を実行する方法の全体像を示すので、YAML を書き始める前に、どのリソースにどのメカニズムを使うかがわかります。

UI が問題になる理由

ダッシュボード、データソース、アラートを手作業で作成すると、時間とともに 3 つのことが悪化します。

  • 何も再現できない。 状態は Grafana のデータベースにあります。インスタンスを再構築するには、すべてのクリックをやり直すことになります。
  • 変更が見えない。 レビューのステップがなく、Grafana 自身のバージョンログ以外の履歴もありません。
  • 環境がドリフトする。 staging と本番は徐々に乖離し、それがどのようにかは誰にもわかりません。

解決策は、データベースをキャッシュとして、リポジトリを真実として扱うことです。Grafana が必要とするすべてのものは、起動時にファイルからプロビジョニングされるか、ファイルを読み取るツールによって適用されます。

階層

層形式制御するもの適用するもの
サーバー設定grafana.ini と GF_* 環境変数ポート、データベース、認証、SMTP、ログ、feature toggle起動時の Grafana
データソースのプロビジョニングYAMLデータソースとその認証情報起動時の Grafana
ダッシュボードのプロビジョニングYAML のプロバイダー + JSON ファイルダッシュボードとフォルダーGrafana。一定の間隔で再スキャン
アラートのプロビジョニングYAMLアラートルール、コンタクトポイント、ポリシー、ミュートタイミング、テンプレート起動時の Grafana
プラグインのプロビジョニングYAMLインストール済みのプラグインアプリの設定起動時の Grafana
TerraformHCLAPI を持つすべてのもの：フォルダー、データソース、ダッシュボード、アラート、チーム、サービスアカウントterraform apply
Grafana OperatorKubernetes のカスタムリソースインスタンス、フォルダー、ダッシュボード、データソース、アラートルールクラスター内のコントローラー
Git SyncRepository リソースGit リポジトリに保存され、双方向に同期されるダッシュボードGrafana 自身

どれを使うべきか

  • コンテナまたは VM 内の 1 つの Grafana、小規模なチーム： サーバー設定とファイルによるプロビジョニング。追加の可動部分がありません。
  • GitOps（Flux または Argo CD）を使う Kubernetes： インスタンスには Grafana の Helm チャートを使い、プロビジョニングファイルを ConfigMap として使うか、各ダッシュボードとデータソースを個別の Kubernetes オブジェクトとして扱いたい場合は Grafana Operator を使います。
  • 多数のインスタンス、または Grafana Cloud： Terraform。スタック、サービスアカウント、チームも作成できるためです。
  • 多くの人が作成するダッシュボード： Git Sync、または JSON を生成する Grafana Foundation SDK のようなコードライブラリ。

これらはうまく組み合わせられます。一般的な構成は、データソースとアラートにはファイルによるプロビジョニングを、ダッシュボードには Git Sync または Terraform を使うものです。

ファイルではできないこと

一部のリソースには、プロビジョニングのファイル形式がありません。それに備えて計画してください。

  • ユーザー、チーム、組織、サービスアカウント は、API または Terraform（あるいは SSO とロールマッピングを持つ ID プロバイダー）で作成します。
  • フォルダーとダッシュボードの権限 は、API、Terraform、または Operator で管理します。
  • 最初の admin パスワード は、初回実行時にのみ設定されるため、後で変更するには CLI や API の呼び出しが必要です。

認証と Terraform のガイドが、これらの回避策を説明します。

プロビジョニングされたものはロックされる

プロビジョニングされたリソースは、ファイルによって所有されることを意図しています。データソースは editable: false とマークでき、プロバイダーのダッシュボードは UI での保存を拒否でき、プロビジョニングされたアラートのリソースは UI ではまったく編集できません。それが要点です。誰かが手作業で変更できるなら、Git は真実ではなくなります。UI は、データの探索やパネルの下書きには依然として有用であることを忘れないでください。ダッシュボードのガイドの作成のワークフローが、それらの下書きを Git に戻す方法を示します。

変更のメンタルモデル

  1. リポジトリ内のファイル（ダッシュボードの JSON、データソースの YAML、アラートルール）を編集します。
  2. プルリクエストを開き、diff をレビューし、マージします。
  3. 配信メカニズムがそれを適用します。コンテナの再起動、ダッシュボードの再スキャン、Flux の調整、または terraform apply です。
  4. Grafana 自身のデータベースが一致するように更新されます。何か問題が起きたら、commit を revert します。

次に進む先

compose ファイルからローカルの Grafana を実行し（次のガイド）、設定のルールを学び、その後、データソース、ダッシュボード、アラートを 1 つずつ追加します。リファレンスとしては、Grafana のドキュメントを参照してください。

人気のガイド