実践的なGrafanaダッシュボード設計：Panel、Variable、Annotationを使いこなす秘訣 – ITFROMZERO

Table of Contents

「手動サーバーチェック」という悩み

キャリアを始めたばかりの頃、一番の悩みは夜勤でした。システム遅延の通知が来るたびに、15〜20個のターミナルウィンドウを同時に開き、各サーバーにSSHでログインして top、df -h、free -m を打ち込んでいました。当時は、問題の根本がどこにあるのかもわからず、乱高下する数値の海の中で「雲を掴むような作業」をしていました。

その後、PrometheusとGrafanaを導入して初めて、これまでどれほど無駄な労力を使っていたかに気づきました。手動でコマンドを打つ代わりに、今では集約された一つの画面を見るだけでシステムの健康状態を完全に把握できます。しかし、Grafanaをインストールするのは第一歩に過ぎません。数秒でエラーを発見できる、本当に「優れた」ダッシュボードを作るには、設計思想を持ち、Variable（変数）やAnnotation（アノテーション）を使いこなす必要があります。

効果的なダッシュボードを支える3つの柱

ダッシュボードを、何十もの折れ線グラフ（Graph）が重なり合う戦場にしてはいけません。5年間の運用経験を経て、ダッシュボードを真に有用なものにするための3つの核となる「武器」をまとめました。

Variables（変数）: ダッシュボードに柔軟性を持たせます。50台のサーバーのために50個のダッシュボードを作る必要はありません。1つだけ作成し、変数を使って表示を切り替えるだけです。
Panels（パネル）: 適切なパネルの種類（Gauge、Stat、Time Series）を選択することで、データの読み取り速度が3倍速くなります。
Annotations（アノテーション）: これこそがアマチュアとプロの境界線です。新しいコードのデプロイ、サービスの再起動、メンテナンスなどのイベントをグラフ上に直接マークできます。

1. Variablesの設計：パラメータをハードコードしない

私はかつて、サーバーAのグラフを作成し、それをサーバーBにコピーしてクエリ内のIPを手動で修正するという、愚かな間違いを犯していました。システムが30〜40ノードに拡張されたとき、完全に行き詰まってしまいました。

解決策は Dashboard Settings -> Variables にあります。Query タイプを使用して、Prometheusからサーバーリストを自動的に取得しましょう。

label_values(node_cpu_seconds_total, instance)

次に、クエリ内の固定IPを変数 $node に置き換えます。例えば、CPU使用率（%）を監視する場合：

100 - (avg by (instance) (irate(node_cpu_seconds_total{instance="$node",mode="idle"}[5m])) * 100)

これで、ダッシュボードの上部にドロップダウンメニューが表示されます。サーバーを選択するだけで、下のすべてのデータが自動的に更新されます。迅速かつミスもありません。

2. 適切なパネルの選択：可観測性を優先する

黄金律：最も重要な指標は最上部に、大きく明確に配置すること。

Stat Panel（統計パネル）

Up/Downステータスやリクエストの総数に使用します。サーバーが稼働しているかどうかを知りたいだけなら、折れ線グラフは不要です。青（オンライン）や赤（オフライン）の巨大な数字があれば、1秒で状況を把握できます。

Gauge（ゲージ）

CPU、RAM、ディスクの使用率に最適です。針が赤い領域（90%の閾値など）を指すと、強い視覚的プレッシャーを与えます。詳細な数値を読まなくても、サーバーが「過負荷」であることがすぐにわかります。

Time Series（時系列グラフ）

トレンドを確認する必要がある場合のみ使用します。例えば、20時のトラフィックの急増分や、1時間あたり約200MBのメモリリークなどです。ヒント：データが一時的に途切れてもグラフが途切れないように、Connect null values を有効にしましょう。

3. Annotation：「なぜ止まったのか？」への答え

午前2時にCPUが95%に跳ね上がったと想像してください。「誰が何をしたのか？」と自問するはずです。その答えがアノテーションです。

デプロイスクリプトを実行するたびに、Grafanaに通知を送るcURLコマンドを組み込んでいます。これにより、グラフ上に垂直線が表示されます。それを見れば、「あ、v1.2をデプロイした直後にCPUが上がり始めたんだな」とすぐにわかります。

以下は、CI/CD（JenkinsやGitLab Runnerなど）に統合するためのサンプルコマンドです：

curl -X POST -H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "dashboardUID":"your_id",
  "time":1649850000000,
  "text":"ITFromZeroによるバージョン1.2のデプロイ",
  "tags":["deploy","production"]
}' http://your-grafana-url/api/annotations

デプロイ以外にも、データベースの再起動やDDoS攻撃を受けた際のマーキングにもアノテーションを使用しています。ダッシュボード上の視覚的な運用日誌のようなものです。

ダッシュボードの構成：3秒で問題を特定する

乱雑に配置してはいけません。ダッシュボードを優先順位に従って Rows（行）に分割しましょう：

Row 1 – Overview（概要）: 死活ステータス、アップタイム、クラスター全体の平均CPU/RAM。
Row 2 – System Detail（システム詳細）: 各サーバーの詳細、ディスクI/O、ネットワークトラフィック。
Row 3 – App Metrics（アプリメトリクス）: APIエラー（エラー率 > 5%）、レイテンシ、注文数。

工数を節約するために、Library Panels を活用しましょう。美しく設定したCPUグラフがあれば、ライブラリに保存して、他のダッシュボードでドラッグ＆ドロップで再利用できます。

おわりに

ダッシュボードを作ることは、飛行機のコックピットを設計することに似ています。シンプルであればあるほど、リスクは少なくなります。最初からすべてを詰め込もうとしないでください。まずは最も基本的な指標から始め、実際に遭遇したトラブルに基づいて徐々にVariableやAnnotationを追加していきましょう。ダッシュボードは単なるカラフルな四角形の集まりではなく、システムをより自信を持って制御するための「目」なのです。