監視ダッシュボード設計事例

SLOから逆算するレイヤ設計：SLO→症状→原因→行動

ダッシュボードは「見る」ためではなく「判断する」ための道具です。最初に据えるべきはSLO（例：APIの可用性99.9%、p95レイテンシ300ms以下、5xx比率0.1%未満）。この目標から逆算して、上から順に「ユーザー影響→症状→原因→行動（Runbook）」の列を並べると迷いが減ります。

4つの列で迷子を防ぐ

• 列1：ユーザー影響（SLO、エラーバジェット燃焼率、外形監視成功率）
• 列2：症状（p95/p99レイテンシ、5xx/4xx比率、タイムアウト数、キュー遅延）
• 列3：原因候補（DB接続プール使用率、キャッシュヒット率、スロークエリ数、GCポーズ、スレッド/FD消費、CPU/メモリ/ディスクIO/ネットワーク飽和）
• 列4：行動（直リンクのRunbook、フェイルオーバー/スケール手順、Feature Flagやデプロイのロールバック）

トップ行には「SLO達成率」と「エラーバジェット燃焼率」を大きく配置。次にAPI別のp95レイテンシ、5xx比率、外形監視の結果。3行目でRDSやRedis、メッセージキューの健全性を並べ、最下段にデプロイや設定変更のアノテーションを重ねます。判断の起点が常にSLOになるよう視線誘導を設計します。

1画面で“判断”まで行けるUIの作り方

時間軸と文脈の統一

• 時間範囲は「5分/1時間/24時間」をワンクリック。全パネルで同期。
• デプロイ、Feature Flag、DBマイグレーションのアノテーションを常時表示。
• 7日移動中央値や前週同時刻と比較のバンドを重ね、昼夜・曜日変動を見誤らない。

最初に見る3枚＋深掘りリンク

• パネル数は1画面12枚以内。左上から「SLO/バジェット/外形監視」。
• 色は「緑/黄/赤」。赤の定義は“5分以上継続”など時間条件つきにする。
• 各パネル右上にRunbookへの深掘りリンク。例：「5xx急増→WAF/アプリ/依存先の切り分け手順」。

アラートノイズを減らす設計

• 閾値は平常時のp95＋3σを目安に仮置きし、1週間で実測に合わせて調整。
• 「変化率」条件（例：5分でレイテンシ2倍）を併用し、恒常的な高負荷と区別。
• 「抑制ルール」：メンテナンス時はSLOを一時的に休眠。アノテーションで自動抑制。

AIの活用も現場では有効です。ChatGPTやClaudeでアラート説明文とRunbookの下書きを作成、CopilotでPromQLやログクエリの雛形を生成、Geminiで過去の類似インシデントを検索して再発防止策へつなげる、といった流れは実務に馴染みます。

データ取得と更新間隔の設計ポイント

収集方式と保持

• Pull型（Prometheusなど）で15秒スクレイプを標準、外形監視やUptimeは5秒。
• 高解像度は14日保持、以降は1分にロールアップして90日。容量計画は先に決める。
• ビジネスKPIは60秒粒度で十分。SLOの算出は1分アグリゲーションで誤検出を防止。

メトリクス別の目安

• APIレイテンシ/エラー：10〜15秒
• CPU/メモリ/FD/接続数：15秒
• ディスクIO/ネットワーク：30秒
• DBスロークエリ/レプリケーション遅延：30〜60秒
• キュー長/遅延：10秒

欠損値の扱いはゼロ埋めを避け、欠損は欠損として表示（線を切る）。可視化の補間で誤検知が起きがちなためです。権限設計は「閲覧は全員、編集は最小限、アノテーションは誰でも」を基本に、インシデントのタイムラインをダッシュボードに集約します。

身近な企業の失敗→改善：家具ECのダッシュボード再設計

従業員50名の家具EC「コジマ家具オンライン」。3台のWebサーバとRDS、Redis、決済ゲートウェイ連携という構成。ブラックフライデー前の障害で、カートAPIの5xxが12%に跳ね上がったのに、当時のダッシュボードはCPUとメモリのタイルが並ぶだけ。SLOもなく、デプロイ直後のスロークエリ増加に誰も気づけませんでした。アラートは20件以上同時に鳴り、何から手をつけるか判断できず復旧に42分。

改善ではSLOを「可用性99.9%、p95レイテンシ300ms」に設定し、ダッシュボードを4列で再構成。1行目はSLO、エラーバジェット燃焼率、外形監視。2行目に「カート/在庫/決済」各APIのp95/5xx。3行目にRDSの接続プール使用率、スロークエリ数、Redisヒット率とp99レイテンシ、メッセージキュー長。4行目にGitのコミットID、CDのデプロイ履歴、Feature Flag変更のアノテーションを集約。

閾値は「DB接続プール使用率90%超が5分継続で赤」「Redis p99 5ms超で黄」「キュー長500超で赤」。アラートはSLO関連と「変化率」だけに絞り、他はダッシュボード観察用に降格。RunbookはChatGPTに既存手順を投げて体裁を整え、Claudeで障害ログからタイムライン要約を自動生成、CopilotでPromQLの微調整、Geminiで過去の似た事例を検索して対策に反映しました。その結果、MTTDは18分→3分、MTTRは42分→12分、当日の売上損失は70%減。現場の体感としても「どこを見るか」が即座に分かるようになりました。

運用に落とすための最終チェックリスト

• SLOとエラーバジェットが左上に常設されている
• ユーザー影響→症状→原因→行動の順で視線が流れる
• パネルは12枚以内、色と単位が統一されている
• アノテーション（デプロイ/Flag/メンテ）が全パネルで同期
• 閾値は時間条件つき、変化率検知を併用、ノイズは抑制
• Runbookとチケット起票が各パネルから1クリック
• 高頻度メトリクスは15秒、保持とロールアップ方針が明文化
• インシデント後にダッシュボードをレビューし、恒久改善を反映

サーバ監視運用事業の現場では、ダッシュボードは24/365の意思決定インターフェースです。SLOから逆算したレイヤ、1画面で判断できるUI、更新間隔と保持の納得感、そして失敗からの学びを仕組みに組み込むこと。これらが回り始めると、監視は「鳴るか鳴らないか」から「素早く正しく手を打つ」運用へと自然に進化します。