Grafana ダッシュボードはグラフを並べる場所ではない – 運用判断の順番を設計する

Grafana のダッシュボードは、グラフを並べる場所ではありません。運用者が異常に気づき、影響範囲を絞り、原因へ降りていく順番を固定するための画面です。CPU、メモリー、ログ件数、エラー数、Top N、直近ログを同じ画面に置いても、見る順番が設計されていなければ、障害時には情報量だけが増えます。

監視画面を作るときは、何を表示できるかではなく、運用者が何を判断する必要があるかから考えるべきです。最初に全体状態を見るのか、異常の種類を分けるのか、対象 host や service を絞るのか、最後に raw log へ降りるのか。この流れがダッシュボードの構造になります。

この記事では、Grafana ダッシュボードを「情報の置き場」ではなく「運用判断の順番」として設計する考え方を整理します。

ダッシュボードは問いの順番で作る

ダッシュボードを作るとき、最初に決めるべきなのはパネルの種類ではありません。運用者が画面を開いたときに、どの問いへ順番に答えるのかです。

順番	問い	見るもの
1	今、異常があるのか	全体件数、エラー率、alert 状態、主要 SLO
2	異常の種類は何か	status 別、level 別、source 別、service 別の内訳
3	どこで起きているのか	host、namespace、app、device、site、source
4	何が多いのか	Top N、request line、error message、unit、remote address
5	具体的な事象は何か	直近ログ、trace、関連イベント、詳細メトリクス

この順番がないままパネルを増やすと、障害時に「どれを見ればよいのか」が分からなくなります。ダッシュボードは、画面を見た人の判断を減らすためにあります。

最初の画面で詳細を見せすぎない

最初の画面に raw log や細かい per-host メトリクスを詰め込むと、重要な状態が埋もれます。最初に必要なのは、異常の有無と大まかな方向です。詳細は、その後に降りる場所として用意します。

たとえば WAF のダッシュボードであれば、最初に audit entries、WAF blocks、status 別件数を見るだけで十分な場合があります。そこで 403 が増えていると分かってから、Top request line や直近ログへ進めばよいです。

最初に置くもの	後段に置くもの
総件数、エラー件数、エラー率	個別ログ本文
status 別、level 別、source 別の内訳	特定 request line の詳細
Top N	該当対象の raw log
全体 trend	特定 host の細かいメトリクス

最初の画面は、原因をすべて説明する場所ではありません。原因へ向かう入口を作る場所です。

件数、比率、Top N、時系列を使い分ける

Grafana ではさまざまな可視化を使えますが、見た目で選ぶと画面が散らかります。運用上の問いに合わせて、件数、比率、Top N、時系列、一覧表を使い分けます。

表現	向いている問い	例
単一値	今どれだけ発生しているか	過去 24 時間の 403 件数、現在の firing alerts
比率	全体に対して異常がどの程度か	エラー率、CPU request / allocatable、メモリー使用率
時系列	いつ増えたか、継続しているか	status 別件数、ログ量、HTTP 5xx
Top N	どの対象が多いか	Top request line、Top remote address、Top namespace
一覧表	個別事象を読む	Recent WAF blocks、journal logs、raw syslog

同じデータでも、問いが違えば表現は変わります。たとえば 403 は、単一値なら現在の規模、時系列なら発生タイミング、Top N なら対象 URL、一覧表なら具体的なリクエスト内容を確認できます。

ダッシュボード変数を増やしすぎない

Grafana の変数は便利ですが、増やしすぎると画面を開いた時点で選択肢が多くなります。変数にするのは、運用上の切り口として使うものに絞ります。

変数に向くもの	理由
source	ログ種別を切り替える入口になる
host	発生元を絞れる
namespace	Kubernetes の運用単位として使いやすい
service / app	アプリケーション単位の切り分けに使える
status / level	異常の種類を絞れる

一方で、request ID、URL、送信元 IP アドレスのように値が多すぎるものは、変数にすると使いにくくなりがちです。必要な場合は検索欄やログ詳細側で扱う方が自然です。

ログダッシュボードは raw log から始めない

Loki を使うと、Grafana に raw log を表示できます。しかし、ログダッシュボードを raw log から始めると、運用者は毎回ログを読んで判断しなければなりません。これは検索画面としては便利でも、ダッシュボードとしては弱い構成です。

ログダッシュボードでは、最初にログ量や分類を見せ、その後に raw log へ降りる方が扱いやすくなります。たとえば network syslog なら、総件数、deny / drop 件数、authentication failure 件数、protocol 別件数を見てから raw syslog を読む流れです。

対象	先に見るもの	最後に読むもの
ModSecurity audit log	status 別件数、WAF blocks、Top request line	Recent WAF blocks
network syslog	denied / dropped、authentication failure、protocol 別件数	Raw syslog
Ubuntu journal	error、warning、unit 別件数	Journal logs
Ceph log	HEALTH、WARN / ERR、ログ量の増減	該当 daemon の詳細ログ

raw log は必要です。ただし、最初に読むものではなく、絞り込んだ後に読むものです。

メトリクスとログで見る順番を変える

Prometheus のメトリクスと Loki のログは、同じダッシュボードに並べることもできます。しかし、役割は違います。メトリクスは状態や傾向を見るためのものです。ログは出来事の説明を読むためのものです。

たとえば Kubernetes のリソースを見る画面では、CPU request / allocatable、memory request / allocatable、Pod restarts、unavailable workloads のようなメトリクスを先に見る方が自然です。一方で、WAF や syslog の画面では、status 別件数や event 件数を見てからログ詳細へ進みます。

対象	最初に見るべきもの	理由
Kubernetes resource	メトリクス	容量、request、restart、availability の状態を見たい
WAF	ログ集計	遮断理由や request line の傾向を見たい
network syslog	ログ集計	deny、drop、認証失敗の発生を見たい
Ceph	メトリクスとログの併用	容量や PG 状態はメトリクス、異常説明はログで見る

何でも同じテンプレートで表示しようとすると、画面は整って見えても判断しにくくなります。対象ごとに、最初に見るべきものは違います。

1 枚に詰め込まない

ダッシュボードを作っていると、関連しそうな情報をすべて 1 枚に入れたくなります。しかし、1 枚に詰め込みすぎると、画面を開く目的が曖昧になります。全体を見る画面、詳細を見る画面、調査用の画面は分けた方が運用しやすくなります。

画面	役割	置くもの
Overview	異常の有無を短時間で見る	主要件数、エラー率、alert、Top N
Drilldown	対象や原因へ降りる	source / host / service 別、時系列、内訳
Raw / Detail	具体的な事象を読む	raw log、trace、詳細テーブル
Capacity	容量や飽和を見る	CPU、memory、storage、request / allocatable

運用者が最初に開く画面と、調査中に開く画面は同じである必要はありません。むしろ分けることで、最初の判断が速くなります。

赤いグラフを増やしても判断は速くならない

ダッシュボードに赤いグラフが多いと、危険そうには見えます。しかし、何をすればよいのかが分からなければ、運用上の価値は低いです。色は状態を伝える補助であり、判断の代わりにはなりません。

重要なのは、異常を見つけた後に次の確認先が自然に分かることです。WAF blocks が増えているなら Top request line へ進む。特定 host の journal error が増えているなら unit 別件数へ進む。Ceph の warning が増えているなら HEALTH detail や該当 daemon のログへ進む。そうした導線があると、ダッシュボードは判断を助ける道具になります。

参考資料

• Grafana documentation: Dashboards
• Grafana documentation: Panels and visualizations
• Grafana Loki documentation: Log queries

参考書籍

関連する記事

まとめ

Grafana ダッシュボードは、グラフを並べる場所ではありません。運用者が異常に気づき、種類を分け、対象を絞り、詳細へ降りる順番を設計する画面です。

最初に全体状態を見せ、次に status、level、source、service のような分類を見せ、最後に raw log や詳細メトリクスへ降りる構造にすると、障害時の判断が速くなります。件数、比率、Top N、時系列、一覧表は、見た目ではなく問いに合わせて選ぶべきです。

監視画面の価値は、情報量ではなく判断のしやすさで決まります。Grafana のダッシュボードを作るときは、何を表示できるかではなく、どの順番で運用判断を進めるのかから設計する必要があります。