ホスティングインフラ向けのGrafanaダッシュボードを作成する

メトリクスの一覧から、明確なダッシュボードの目標像へ

ダッシュボードの作成は、色とりどりのパネルを選ぶことから始まるのではなく、運用上の問いから始まります。「チームは現在、データ収集の不具合、ストレージ容量の不足、あるいは継続的な負荷に対して対応する必要があるのか？」 Grafanaはデータソースへのクエリをパネルとして表示し、問いに応じてそれらを可視化することができます。 したがって、このインターフェースは意思決定のためのツールであり、必ずしもサービスの状態を示す証拠そのものではありません。

最上位レベル（例えば「ホスティングステータス」など）には、ごく少数のシグナルのみを集約すべきです。つまり、 プロメテウス、CPU使用率、利用可能なメモリ、ネットワークトラフィック。その目的は優先順位付けにあります。つまり、どの領域を調査すべきかを見極めることです。ただし、これだけでは、なぜWebサーバーの動作が遅いのか、あるいはどの程度のデータ量で容量警告が発生するのかについては説明されていません。

その中には、次のようなものがあります ロールビュー Webシステム、データベース、キャッシュ、メール、または仮想化システム向けです。そこでは、同種のインスタンスを、その役割に関連するメトリクスを用いて比較することができます。例えば、データベースロールにはリバースプロキシとは異なる詳細値が必要ですが、共通の概要ページでは、こうした違いを単一の指標の中に隠す必要はありません。

診断ビューでは、最終的に各インスタンスごとの時系列データ、マウントポイントやデバイスの概要、および運用イベントを確認できます。 すべてのホストとサービスを一覧表示する大規模なダッシュボードでは、情報の割り当てが困難になります。Grafanaのダッシュボードは、さまざまな可視化やデータソースを統合できますが、それでも、すべての詳細な質問に対する回答を同じページに盛り込むべきではありません。

Prometheusのデータベースとラベルを徹底的に確認する

ダッシュボードを構築する前に、Prometheus と対象となるエクスポーターにアクセスできる状態にしておく必要があり、Grafana には設定済みの Prometheus データソースが必要です。 Prometheusは、設定ファイル内でスクレイプジョブ、ターゲットインスタンス、および読み込むルールファイルを定義します。設定の変更は再読み込みできますが、誤った設定は反映されません。

重要なのは一貫性のある ラベル構造. レーベル job そして instance 送信元と宛先を特定する；次のような補足ラベル： environment 或いは role これにより、本番環境、テスト環境、サーバー機能を明確に区別することが可能になります。こうしたルールがなければ、同じ変数が、名称は似ているものの、メンテナンス時間帯や責任範囲、容量制限が異なるホストを混在させてしまう可能性があります。

エクスポーターのエンドポイントは、無制限に一般に公開されるべきではありません。メトリクスには、ホスト名、マウントポイント、ネットワークインターフェース、その他のインフラストラクチャの詳細が漏洩する可能性があります。 また、GrafanaがPrometheusにクエリを実行できるかどうか、および既存の時系列データが想定された期間にわたって実際にデータを提供しているかどうかを確認してください。空のパネルは、どんなに魅力的な可視化でも修正することはできません。

• Prometheus または「Explore」セクションで、実際に存在するメトリック名、ラベル、およびラベル値を確認してください。
• 各ターゲットについて、スクレイピングが正常に実行されているか、および期待されるインスタンスが一意に指定されているかを確認する。
• ファイルシステムおよびネットワークのメトリクスについては、自身の環境に合わせてマウントポイントやインターフェースを絞り込んでください。
• ダッシュボードのサンプルは、この検証が完了してから初めて、ローカルのメトリクスおよびラベル構造に反映されます。

Node Exporter は、ファイルシステム、ネットワーク、ディスク情報などのコレクターを記録します。ただし、実行時にどの行が表示されるかは、OS、カーネル、コンテナ、マウント、および有効化されているコレクターによって異なります。また、開発ブランチの README には、すでにインストールされている安定版の機能については自動的に記載されていません。

したがって、開発ドキュメントとは別に、インストールされているNode Exporterのバージョンとその観測可能なメトリクスを確認してください。 調査時点では、Node Exporter 1.12.1 が 2026 年 7 月 14 日にリリースされています。ただし、このリリース情報は、特定のホスト上でどのビルドが実行されているかを確認する代わりにはなりません。サードパーティ製のダッシュボードテンプレートは参考情報であり、自社のインフラストラクチャに関する信頼できるインベントリリストではありません。

発言内容に基づいてパネルの種類を選択する

パネルの種類は質問に応じて決まります。 スタットパネルは、最新かつ明確に名付けられた主要指標に適しています。単一の計算値と、必要に応じて小さな推移線を表示することができます。その際、ラベルにはどの指標とどの技術的なチェックポイントが示されているかを正確に明記する必要があります。単一の計測値から、ウェブサイトやアプリケーションの状態を一般化して推測してはなりません。

負荷、成長、および相互関係については、 時系列 より適切です。例えば、CPU使用率がデプロイ中に一時的に上昇するだけなのか、それとも数時間にわたって高い状態が続くのかを示してくれます。 時間範囲、適切な単位、そして他のシグナルとの比較があって初めて、単一の値は信頼性の高い観察結果となります。Grafanaはこれに対応するさまざまな可視化機能をサポートしており、その示唆する内容はクエリや表示方法によって異なります。

テーブルは、多くの同種のエンティティに適しています。ホスト、マウントポイント、またはデバイスは、すべての行を共通の時間軸グラフに配置することなく、測定値や運用上のコンテキストに基づいて行単位で比較することができます。 一方、時間的な関連性を把握するには、時系列データの方が適している場合がほとんどです。したがって、エンティティを比較したいのか、それとも推移を調査したいのかによって、表示方法を選択してください。

各パネルには、単位、フィルタの範囲、および解釈の限界がわかるような正確なラベルが必要です。 「マウントポイントごとのファイルシステムに基づく利用可能ストレージ」という表記は、「ディスク」という表記よりも意味が明確です。クォータ、予約済みブロック、または欠落したiノードが、それでも書き込みの問題を引き起こす可能性があるためです。 同様に、赤いパーセンテージ表示は、利用可能状態や原因を示すものではありません。色は注意を引くことはできますが、診断の代わりにはなりません。

運用上の閾値を単なる飾りとして設定してはいけません。サービスロール、成長率、冗長性、および想定される応答時間が把握されている場合、警告色を使用することは有効です。こうした文脈が欠けている場合は、パネルには中立的な値を表示し、適切な詳細ビューへ誘導すべきです。そうすることで、 パネルでの発言 そして、関係者全員にとって理解しやすい技術的な限界。

ホスティングの概要を段階的に作成する

概要ページは、利用可能なすべての指標から始まるのではなく、運用中に即座に判断が必要ないくつかの質問から始まります。具体的には、「設定された目標は達成されているか」「ホストの負荷は上昇しているか」「重要なボリュームが不足していないか」「データトラフィックに顕著な変化はないか」といった点です。 そのためには、まずは4つのパネルグループのみを設定してください。Grafanaはクエリと表示結果をパネルにまとめます。したがって、それぞれの異なる可視化は、具体的な運用上の疑問に答えるものであるべきです。

まずは、収集状況の明確な概要、CPU負荷の時系列データ、マウントポイントごとの空きメモリの表または時系列データ、およびネットワークスループットの時系列データがあれば十分です。 Statパネルは、単一の現在の値を表示するのに適しており、短い期間の推移を表示することも可能です。しかし、異常の継続時間、発生頻度、発生時刻が重要な場合には、時系列データの代わりにはなりません。

この表は計画の基礎となるものであり、厳格なテンプレートではありません。Node Exporter は、ファイルシステム、ネットワーク、その他のホストデータに関するコレクターの範囲を記載していますが、表示されるメトリクスやラベルは、システム、マウント、コンテナ、および有効化されたコレクターによって異なります。 その後で、HTTPエラー、データベース接続、キューなど、アプリケーション固有のパネルを追加してください。詳細については、 ホスティング向けモニタリング・スタック その過程で、インフラおよびサービスのメトリクスの分類について理解を深めることができます。

この記事におけるPromQL式は、明示的に 修正すべき例. 適用する前に、Explore エリアでメトリック名、ラベル値、および生成される系列の数を確認してください。各パネルのラベルは、そのパネルが伝えることができる情報に限定して簡潔に記述してください。また、単位、選択されたフィルターの範囲、および除外されたインターフェースや疑似ファイルシステムについても、パネルの構成や説明に明示的に含めてください。

信頼性の高い概要画面は、意図的に簡潔に保たれています。すべてのホスト、デバイス、マウントポイント、コンテナラベルを同時に表示してしまうと、優先順位が分からなくなってしまいます。 その後、詳細ページが診断を引き継ぎます。そこでは、個々のインスタンス、ボリューム、またはサービスを個別に確認することができます。このようにして、トップページは、視覚的にごちゃごちゃした無関係な指標の集まりではなく、全体像を把握するためのツールとして機能し続けます。

PromQLと変数を正しく組み合わせる

クエリでは、メトリクスとその閾値を同時に指定する必要があります。 まず、Prometheus または Grafana Explore で、自身の環境に実際に存在するシリーズとラベルを確認してください。その後、Grafana 変数を使用して、固定のラベル値を置き換えることができます。複数選択が有効になっている場合、その内容は正規表現として使用されるため、ラベルマッチャーは =~ の代わりに = を使用します。

CPU使用率に関しては、累積カウンターだけでは直接的な意味を持ちません。以下の例では、アイドルモード以外で消費されたCPU時間から、インスタンスごとの使用率（％）を算出しています。これは、以下の前提に基づいています。 node_cpu_seconds_total および使用されているラベルが存在し、Grafana変数が $job そして $instance 適切に定義された。

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle", job=~"$job", instance=~"$instance"}[$__rate_interval])
  ) * 100
)

生成された時系列データを複数の時間範囲にわたって検証し、実際に取得されたサンプルと比較してください。不適切な範囲ウィンドウを設定すると、結果が欠落したり、信頼性の低いものになったりする可能性があります。また、PromQLによる解析においては、以下の点も重要です。 rate() 集計の前に適用し、計算時にカウンターのリセットが反映されるようにする。

次の例では、ストレージビューにおいて、選択された各項目ごとの利用可能割合を計算します。 マウントポイント. 事前に両方のメトリクスとそのラベルセットを確認してください。分子と分母が異なるフィルターによって異なる系列に制限されている場合、除算の結果として空の結果や予期しない結果が生じる可能性があります。

100 * node_filesystem_avail_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}
/ node_filesystem_size_bytes{job=~"$job", instance=~"$instance", mountpoint=~"$mountpoint"}

疑似ファイルシステムを、単に無作為に合計するのではなく、インストールごとにフィルタリングしてください。 ファイルシステムコレクターはファイルシステムの統計情報を提供しますが、表示されるすべての項目が容量決定に関連しているわけではありません。クォータ、予約済みブロック、iノード、および書き込み権限については、別途確認が必要です。したがって、パネルには、選択されたファイルシステムメトリクスに基づく利用可能な容量のみを表示すべきです。

ネットワークの例では、バイトカウンタの変更率が計算され、インスタンスごとに合計された後、ビット毎秒に換算されます。 この合計は、対象となるインターフェースが業務上関連している場合にのみ意味があります。したがって、表示されているすべてのインターフェースを無検証で合計するのではなく、自身の環境に合わせて、理にかなったインターフェースフィルターを追加してください。

sum by (instance) (
  rate(node_network_receive_bytes_total{job=~"$job", instance=~"$instance"}[$__rate_interval])
) * 8

乗数「8」は、1バイトのカウンタから算出されたレートをビット毎秒に変換します。 ループバック、コンテナ、およびトンネルインターフェースは、物理的な接続や特定のサービスに関して信頼性の高い情報を提供しない合計値を生成する可能性があります。そのため、どのインターフェースが考慮対象となり、どのインターフェースが除外されているかをパネルに明記してください。

変数は管理しやすく、カスケード形式で記述する：まず $environment, 、それから $job そしてその後 $instance; メモリ関連のパネルは $mountpoint 補足します。Grafanaはデータソースから動的に変数を生成し、それらを相互に依存させることができます。ただし、読み込みのたびにラベル値のクエリを大量に実行すると、ダッシュボードの初期化が遅くなる可能性があります。

業務知識に基づいて閾値を分類する

時間の経過と運用上のイベントを対比させることで、閾値の信頼性が高まります。 Grafanaの注釈機能を使用すると、パネル上でメンテナンス、リリース、インフラの変更をマークし、ダッシュボード変数を参照することができます。これにより、例えば、負荷の変化がデプロイメントと時期的に一致しているかどうかを確認することができ、グラフの推移だけを見て早合点して障害と結論づけることを防ぐことができます。

バックアップ、キャッシュのウォームアップ、または予定されたデータ処理の際には、一時的なCPU使用率の急上昇が見込まれることがあります。これらが問題となるのは、その状態が長時間続き、待ち時間やエラーと重なり、かつそのサービスロールについて予定された説明がない場合です。 CPU使用率の数値だけでは、可用性の低下やアプリケーションの動作遅延の原因を証明するものではありません。

ストレージ使用量の増加には、別の視点からの検討が必要です。重要なのは、影響を受けるマウントポイント、その機能、増加率、そして容量を拡張できるタイミングです。 空き容量が少ないデータボリュームは、同程度の使用率のアーカイブボリュームよりも緊急性が高い場合があります。また、バックアップウィンドウ、冗長性、復旧経路によっても、運用上の優先順位はさらに変化します。

不審なネットワークトラフィックも、一概にアラームを発する理由にはなりません。トラフィックの増加は、新バージョンのリリース、顧客側のイベント、レプリケーション、あるいは誤って含まれてしまった仮想インターフェースなどが原因である可能性があります。 したがって、インスタンス、方向、インターフェースフィルター、および同時発生しているサービスコンテキストを照合してください。これらの要素が組み合わさって初めて、Web、データベース、またはネットワークの測定値についてドリルダウンを行うべきかどうかが判断できます。

メールサーバーの場合、ホストビューだけでは説明として不十分なことが特に多い。CPU、メモリ、ネットワークからは異常が確認できる場合もあるが、送信品質や配信可能性を評価することはできない。その メールホスティングとレピュテーションの運用上の関連性 これに伴い、具体的なシグナルや依存関係を補足する。

一律の閾値ではなく、役割ごとに、各状態がどのような対応を引き起こすべきかを記録します。具体的には、「監視」「キャパシティの計画」「待機チームへの通知」、あるいは「直ちに確認」などです。これらは 運用コンテキスト-このルールにより、外見上同じパーセンテージ値が同一に扱われることを防ぎます。これにより、環境の成長、メンテナンスウィンドウ、または冗長性が変化した場合でも、閾値を合理的に調整できるようになります。

クエリとダッシュボードのスケーラビリティを維持する

各パネルが長期間にわたり膨大な行数をクエリし、同じ複雑な計算を何度も実行すると、ダッシュボードは読みづらくなり、動作が遅くなる可能性があります。 したがって、選択および表示は、その業務上の課題に関連するエンティティに限定してください。どのクエリが実際に負荷をかけているかは、見た目の複雑さだけでなく、実行時間と結果の量に基づいて確認する必要があります。

変数についても負荷テストを行う必要があります。ダッシュボードを開いた際に大規模なラベルクエリを実行する値リストは、初期化を遅らせる可能性があります。 カスケード方式を採用するのが有効です。まず環境またはロール、次にジョブ、そして最後にインスタンスまたはマウントポイントを指定します。こうすることで選択範囲が狭まり、概要ダッシュボードが過去のラベル値や一時的なラベル値をすべて同時に提供しようとしなくなります。

頻繁に使用され、計算負荷の高い PromQL 式については、 録音のルール 特定のオプション。 Prometheusはルールを評価し、その結果を新しい時系列データとして保存します。その後、パネルは完全な元の式ではなく、この事前に計算された時系列データを参照します。これにより、繰り返し行われるダッシュボードのクエリを高速化できますが、選択条件、集計方法、保持期間が業務上の要件に合致しているかどうかの確認に代わるものではありません。

ルールは、固定の評価間隔を持つグループ単位で実行されます。グループの評価にその間隔よりも長い時間がかかる場合、個々の反復処理がスキップされることがあります。 したがって、事前計算をすべてのクエリに対する画一的な解決策と見なすべきではありません。まず、実際に頻繁に使用されているパネルがどれか、1つの式が処理する行数がどれくらいか、そしてロールベースのビューによってクエリがすでに十分に絞り込まれているかどうかを確認してください。

ルールファイルを展開する前に、その構文をローカルで確認することができます。以下のターミナルコマンドは、指定されたファイルの構文をチェックしますが、実行中のPrometheusの設定を変更したり、ルールを有効にしたりすることはありません。

promtool check rules /path/to/example.rules.yml

さらに、各ルールの実行時間と有用性にも注意を払ってください。新しい時系列データは、別途保存して照会する必要があります。ホスト数が少ない小規模なダッシュボードの場合、明確にフィルタリングされた出力の方がシンプルで保守しやすい場合があります。特に、負荷のかかる同じ計算を確実に何度も行う必要がある場合は、事前計算を行う価値があります。

したがって、スケーラビリティは技術的な最適化だけで実現されるものではありません。意味のあるパネルの数を減らし、ラベルの選択肢を限定し、詳細ビューを分離しておくことで、障害発生時にダッシュボードが判読不能になるのを防ぐこともできます。速度と専門的な情報伝達は、併せて検討する必要があります。

クエリの変更は、運用変更と同様に計画的に行うこと：ダッシュボードのコピーで出力を確認し、既知の期間の結果と比較した上で、初めて概要に反映させる。そうすることで、目立つ読み込み時間の遅延、欠落しているシリーズ、意図しない集計結果などが、インシデントが発生してから初めて明らかになるのではなく、追跡可能になります。

しかし、クエリが簡潔であるからといって、それが正しい質問に答えている証拠にはなりません。行数を減らすことで、重要なロール、マウントポイント、またはインターフェースが見落とされるようなことがあってはなりません。したがって、パネルにどのエンティティが含まれており、詳細表示のためにどのエンティティが除外されているかを、意識的に文書化してください。

空のパネルや誤った信号の解釈

パネルが空白であることは、あくまで診断上のヒントであり、サービスが正常か障害中かを示すものではありません。以下の順序で確認してください：Prometheusにそのメトリクスが存在するか、使用されているラベルとフィルターが適切か、選択した時間範囲にデータが含まれているか、そしてインストールされたエクスポーターのバージョンがそもそもこのデータ系列を提供しているか。 Prometheusは再読み込み時に誤った設定を引き継がないため、予期しないターゲット状態や設定状態も関連している可能性があります。

パネルに予期せぬ収集状態が表示された場合は、まず設定されたスクレイプ対象と、Prometheus内の実際のデータセットを確認してください。エクスポーター、ネットワークパス、証明書、またはアクセス情報は、あくまで可能性のある不具合箇所として検討し、すでに特定された原因として扱わないでください。 ウェブサイトやアプリケーションの可用性を判断するには、その分野に即した独自の指標が必要であり、収集パネルだけではその判断材料にはなりません。

予想以上に多くの時系列データが生成される原因は、多くの場合、マッチャーの範囲が広すぎることや、テンプレートから引き継がれた余分なラベルにある。まずは、集計を行わず、Grafana変数も使用しない生のクエリを確認すること。そうすれば、インスタンス、デバイス、マウントポイントなどを意図的に分けて表示する必要があるかどうかが把握できる。 どのエンティティが業務上比較可能であるかが明確になってから、集計を行うべきです。

ファイルシステムの値については、疑似ファイルシステム、コンテナマウント、または一時パスによって、テーブルや集計値が不正確になる可能性があります。 Node Exporter にはファイルシステム統計用のコレクターが記載されていますが、実際に表示される行はシステムやコレクターの設定によって異なります。そのため、明確に文書化されたルールに基づいてのみフィルタリングを行い、具体的な環境において対象となるマウントポイントを必ず確認してください。

ネットワークスループットについても同様です。すべてのインターフェースの合計には、ループバック、トンネル、仮想、またはコンテナインターフェースが含まれる可能性があり、その結果、運用上意味のない数値が算出されることがあります。 対象となるトラフィック経路にどのインターフェースが含まれるかを明確に定義してください。この判断がホストの役割ごとに異なる場合は、グローバルフィルターよりもロール別ビューの方が理解しやすいことがほとんどです。

バイト数やCPU使用率が着実に上昇している場合、それは多くの場合、負荷のピークではなく、 カウンター. このようなメトリクスは累積値を計測します。スループットやCPU使用率については、適切な時間枠におけるレートが必要となります。Prometheusでは、集計機能と組み合わせる場合、 rate() 集計の前に適用する。ウィンドウが短すぎると変動が強調され、長すぎると変動が見えにくくなる可能性がある。

結果が依然として不自然である場合は、個別のインスタンス、個別のマウントポイントまたはインターフェース、およびより短い期間と比較してみてください。その後に初めて、式を変更すべきです。このように段階的に範囲を絞り込むことで、フィルタが複雑になるにつれて表示上の問題が隠れてしまうのを防ぐことができます。

インポートされたダッシュボードテンプレートは、あくまで出発点に過ぎません。メトリック名やラベルは、OS、エクスポーターのバージョン、コンテナ化、有効化されているコレクターによって異なる場合があります。そのため、インポートしたクエリの構文だけでなく、常に既存の行も確認するようにしてください。

全体像から、確固たる経営判断へ

チームが主に、どのホストやどのロールに注意を払う必要があるかを把握できれば、シンプルなインフラダッシュボードで十分です。 スクレイプによる到達性、負荷、利用可能なメモリ、ネットワークトラフィックは、そのための最初の手がかりとなります。しかし、これらは、アプリケーションの応答が遅い理由や、特定のサービスがユーザーに利用可能かどうかを確実に明らかにするものではありません。Grafanaはさまざまなデータソースを可視化できますが、統一されたインターフェースだけでは原因分析の代わりにはなりません。

異常が繰り返し発生したり、複数のシステムロールに影響を及ぼしたりした場合は、概要に ドリルダウン . リンクされた、あるいは個別に表示されるロールビューでは、Webサーバー、データベース、キャッシュサーバー、メールサーバーなどが、それぞれ重要なメトリクスに焦点を当てることができます。 診断ビューでは、インスタンスごとの時系列データ、デバイスやマウントポイントのテーブル、および変更の発生時刻に関する情報が補完されます。これにより、トップページは関連する技術的な詳細を見失うことなく、行動指向性を維持しています。

データベースを段階的に拡張しましょう。ホストメトリクスの安定が確認できたら、エラー率、応答時間、キュー、データベースの状態など、アプリケーション固有の値を追加していきます。 ログやトレースは、メトリクスの推移によって原因を絞り込めたものの、その原因が説明できない場合に特に役立ちます。すべてのビューにすべてのデータタイプを含める必要はありません。追加する各データ系列には、具体的な問いと、その管理に関する責任ある判断が必要です。

ダッシュボードの責任範囲を明確に定義してください。ラベルや変数のメンテナンスを担当するのは誰か、インフラの変更後にフィルターを確認するのは誰か、閾値を決定するのは誰か、そして未使用のパネルを評価するのは誰か。レコーディングルールも、ルールファイルや保存された時系列データを補完するものであるため、このメンテナンスの対象に含まれます。 固定されたグループ間隔はデータフローの一部であり、期待される更新頻度を考慮に入れる必要があります。

モニタリングでは、監視とコミットメントを区別します。 グリーンパネルは、セキュリティやパッチの状態、データの整合性、あるいは一般的な可用性を保証するものではありません。パッチ適用やセキュリティのプロセス、バックアップ、権限管理、インシデント対応には、それぞれ独自の管理体制が必要です。ダッシュボードはヒントを提供し、意思決定を支援することはできますが、これらの運用業務を、そこから導き出されたパーセンテージ値で置き換えてはなりません。

小規模な環境では、一貫したラベルが付けられた、把握しやすいインフラストラクチャパネルのセットから始めるのが適切な場合が多い。ホスト、ロール、またはテナントの数が増えていくにつれ、ますます巨大化するダッシュボードよりも、明確なラベル、ロール別ビュー、および事前に計算されたクエリの方が重要になってくる。 重要なのは、各ビューが次の確認を可能にし、その解釈の限界を可視化していることです。

デプロイや新しいエクスポーター、サーバーロールの変更があった場合は、定期的に運用モデルを確認してください。不要なパネルや変数を削除することは、新しいメトリクスを追加することと同様に、ダッシュボードの見やすさを向上させます。ダッシュボードは、その表示内容が実際のアーキテクチャや責任範囲の変化に合わせて進化していくことで、柔軟性を維持できます。