この記事のポイント：Datadog Dashboardを、製品やメトリクスの一覧ではなく、障害初動で答えたい質問の順に整理する方法を紹介します。「利用者影響・サービス健全性」「サービス・処理経路」「依存関係・プラットフォーム」「実行基盤・リソース」の4つの確認領域と、Overviewから詳細調査へ移る設計を扱います。

はじめに

Datadog DashboardへCPU、メモリ、Load Balancer、Database、LogsなどのWidgetを追加していくと、多くの情報を一画面で確認できるようになります。一方、障害が発生したときに、どこから見ればよいか分からないDashboardになることもあります。

本記事で対象とするのは、障害初動に関わる運用担当者、SRE、プラットフォーム・インフラ担当者、開発者です。経営層や業務担当者がKPIを確認するDashboardは、対象者と判断内容が異なるため扱いません。

また、Dashboardだけで原因を特定することや、アラートをDashboardで置き換えることも目的にしません。目指すのは、利用者影響を確認し、次に調査する領域を選べる入口を作ることです。

Widgetを増やすだけでは初動の判断順は決まらない

Dashboardを作るとき、監視対象の製品や取得できるメトリクスを基準にWidgetを並べる方法があります。この方法は表示項目を洗い出すときには便利ですが、利用者が確認する順番とは一致しない場合があります。

例えば、Database CPU、Webの応答時間、HTTP 5xx、Host CPU、アラート状態のMonitorが同じ画面に並んでいても、最初に何を確認し、どの状態なら次へ進むのかは分かりません。情報がそろっていても、利用者が確認順をその場で組み立てなければなりません。

Datadogの公式ガイドでも、Dashboardは日常的に答えたい質問から設計し、すべての情報を同じ画面へ詰め込まないことが案内されています。先に決めたいのはWidgetの種類ではなく、Dashboardを見る人が答えたい質問です。

初動用Dashboardであれば、少なくとも次の質問に答えられるようにします。

  1. 利用者へ影響が出ているか
  2. どのサービスや処理経路が劣化しているか
  3. どの依存先やプラットフォームを確認するか
  4. 個別の実行基盤やリソースに異常があるか

4つの確認領域は固定的な階層ではない

本記事では、公開されている監視設計の考え方を参考に、障害初動で答えたい質問を「利用者影響・サービス健全性」「サービス・処理経路」「依存関係・プラットフォーム」「実行基盤・リソース」の4つの確認領域へ整理した一例を示します。これは固定的な標準ではなく、対象者やシステム構成に合わせて調整するための整理方法です。

確認領域 答えたい質問 表示候補
利用者影響・サービス健全性 誰に、どの機能で、どの程度の影響があるか SLO／SLI、可用性、Synthetic、主要処理の成功率、Monitor、Incident
サービス・処理経路 どのサービス、処理、依存呼び出しが劣化しているか Traffic、Errors、Latency、サービス固有のSaturation、依存呼び出し
依存関係・プラットフォーム どの依存先、マネージドサービス、共有基盤が影響しているか Load Balancer、Database、Queue、Storage、DNS、CDN、外部API、クラウドサービス状態
実行基盤・リソース 個別の実行環境に飽和や障害があるか Host、Container、Process、CPU、Memory、Disk、Network

この4区分はDatadogが定めた標準構成ではありません。障害初動で、全体の影響から原因候補へ進む順番をそろえるための実践パターンです。

また、第3領域と第4領域の順番は固定しません。Databaseの応答悪化が見えているなら依存関係を先に確認し、特定Hostのアラートから始まったなら実行基盤を先に確認します。対象者やシステム構成に合わせて、領域の名称、順番、表示量を変えます。

4領域より先に共通情報を置く

4つの領域へ進む前に、Dashboard上部で調査の前提を確認できるようにします。

  • 対象のシステム、サービス、環境、リージョン
  • Dashboardの時間範囲
  • データ鮮度やNo Dataの有無
  • 所有チームや連絡先
  • 直近のデプロイ、構成変更、関連イベント
  • Runbook、Incident、詳細Dashboard、Explorerへのリンク

時間範囲や対象環境がずれたまま詳細を見始めると、同じグラフでも異なる判断になります。上部の共通情報は、4領域の一つではなく、すべての確認に使う前提です。

Datadogのテンプレート変数を使えば、対象システムや環境をDashboard上部で切り替えられます。本記事では具体的な設定方法には踏み込まず、「対象を共通条件で確認できること」を設計上のポイントとして扱います。

画面上では、4つの領域をGroupとして分けます。次の例では、第1領域だけを展開し、残りの領域は見出しとして表示しています。

検証用Dashboardのスクリーンショットに、説明用のサンプルメトリクスを合成したWidget配置例。数値とグラフは実データではありません。

4つの確認領域を質問で分ける

1. 利用者影響・サービス健全性

最初に確認するのは、Monitorが発報しているかだけではなく、利用者へどのような影響が出ているかです。

SLOや可用性、Syntheticテストの結果、主要処理の成功率などを使い、「誰に」「どの機能で」「どの程度」の影響があるかを確認します。MonitorやIncidentは重要な入口ですが、MonitorがOKであることだけでは、利用者影響がないとは判断できません。

この領域では、まず影響範囲と対応の優先度をそろえます。

2. サービス・処理経路

次に、利用者のリクエストが通るサービスや処理経路を確認します。Webサービスであれば、Traffic、Errors、Latencyを中心に、依存呼び出しや主要トランザクションの変化を見ます。

SaturationもCPUやメモリだけではありません。Queueの滞留、接続プール、同時実行数、残容量など、サービス固有の上限へ近づいていないかを確認します。

架空の例として、Web画面の応答時間が悪化している場合、リクエスト数の急増、HTTP 5xx、特定処理のLatency、Database呼び出し時間を並べると、次に確認する対象を選びやすくなります。

3. 依存関係・プラットフォーム

サービスの劣化と関連していそうな依存先を確認します。Database、Queue、Load Balancer、Storageだけでなく、DNS、CDN、認証基盤、外部API、他チームが管理するサービスも対象です。

製品名だけで配置場所を決める必要はありません。Databaseへの呼び出しLatencyはサービス・処理経路で見せ、Databaseの接続数や稼働状態は依存関係・プラットフォームで見せることがあります。同じ製品でも、答えたい質問が違えば配置先が変わります。

4. 実行基盤・リソース

Host、Container、Processなど、処理を実行している単位の状態を確認します。CPU、Memory、Disk、Networkは、全体平均だけでなく上位値や偏りも確認できるようにします。

平均CPUが低くても、一部Hostだけが高負荷になっている場合があります。Diskも全体の空き容量だけでは、特定デバイスの逼迫を見落とすことがあります。実行基盤の領域では、サービスの異常を説明できるリソースの偏りや飽和があるかを確認します。

サーバーレスやPaaS中心の環境では、この領域を小さくしても問題ありません。4領域を埋めること自体を目的にせず、運用担当者が確認できる範囲に合わせます。

Golden Signals・RED・USEで表示指標を選ぶ

4つの確認領域は「どこから確認するか」を整理する枠です。各領域で「何を測るか」は、Golden Signals、RED、USEなどの考え方を使って選びます。

考え方 主な指標 使いやすい領域
Golden Signals Latency、Traffic、Errors、Saturation 利用者影響、サービス、依存関係
RED Rate、Errors、Duration サービス、処理経路、依存呼び出し
USE Utilization、Saturation、Errors 実行基盤、リソース、プラットフォーム

4領域へWidgetを均等に置く必要はありません。利用者影響を確認できないのにCPUグラフだけを増やす、取得できるからという理由で指標を追加する、といった状態を避けます。

OverviewとDeep-diveの役割を分ける

初動確認用のOverview Dashboardへ詳細を詰め込むと、調査の入口と深掘り画面の役割が混ざります。

仕組み 役割
Alert 対応開始を促し、対象と優先度を伝える
Overview Dashboard 利用者影響と、次に確認する領域を判断する
Deep-dive Dashboard／Explorer サービス、依存関係、実行基盤、Logs、Tracesから仮説を検証する
Incident／Runbook 対応手順、役割分担、判断結果を管理する

Overview Dashboardは、影響範囲と次に確認する領域を判断する入口として使います。詳細な状態は、目的に応じたDashboardやExplorerで確認します。画面の分け方は、システムの特性や運用体制に合わせて調整します。

ただし、すべての詳細を一つのDeep-dive Dashboardへ集める必要はありません。規模が大きい環境では、サービス、依存関係、実行基盤、Logs、Tracesなどの詳細Dashboard群やExplorerへ分け、Overviewから必要な画面へ移動できる方が分かりやすい場合があります。

標準へ入れないWidgetを決める

標準Dashboardでは、何を入れるかと同じくらい、何を入れないかを決めることが重要です。

標準へ入れない候補 対応
初動時の質問に答えない 定期確認用や分析用のDashboardへ分ける
想定読者が行動へつなげられない 所有者や利用場面を確認してから採用する
メトリクス、タグ、前提条件を確認できていない 未確認事項として残し、実データ確認後に判断する
一部環境だけで使う 環境固有の補助グループや個別Dashboardへ分ける
既存Widgetと同じ判断を重複して示す より判断しやすい表示へ統合する

正式なメトリクス名やディメンションが未確認の項目を、完成Widgetとして置く必要はありません。Noteで確認条件を残すか、実データ確認後に追加します。空表示が発生した場合は、Query Error、データ未流入、絞り込み条件、収集設定などを切り分けて確認します。

設計レビューのチェックリスト

最後に、初動用Dashboardを次の順で確認します。

  1. 想定読者と利用場面を説明できるか
  2. 最初に利用者影響とサービス健全性を確認できるか
  3. 各Widgetが答える質問を一文で説明できるか
  4. 製品名ではなく、確認したい質問で配置しているか
  5. 対象、環境、時間範囲、データ鮮度を確認できるか
  6. Overviewから必要な詳細画面へ移動できるか
  7. Monitor、Dashboard、Explorer、Runbookの役割が混ざっていないか
  8. 実データや前提条件を確認していないWidgetを完成扱いにしていないか
  9. 対象環境に不要な領域や重複Widgetを削れるか
  10. 障害や構成変更の後に、表示内容を見直す担当が決まっているか

まとめ

障害初動用のDatadog Dashboardは、製品や取得できるメトリクスを並べるだけでなく、利用者が答えたい質問の順に整理します。

本記事で紹介した4つの確認領域は、固定的なアーキテクチャの分類ではありません。「利用者影響・サービス健全性」から始め、「サービス・処理経路」「依存関係・プラットフォーム」「実行基盤・リソース」へ原因候補を絞るための整理枠です。

対象者やシステム構成に合わせて順番と表示量を変え、各領域ではGolden Signals、RED、USEなどを使って必要な指標を選びます。Overviewで影響と調査開始点を決め、詳細DashboardやExplorerで仮説を確認できる形にすることがポイントです。

最後までお読みいただき、ありがとうございました。

参考資料