ダッシュボードは「眺めるもの」ではない：Datadogで障害を0秒で特定する「戦闘指揮所」の作り方
「CPU使用率が80%を超えました」というアラートで画面を開き、何が起きているかを探し回る……そんな作業に時間を溶かすのはもう終わりにしよう。
オブザーバビリティとは、単なる監視ではない。「システムが今どう動いていて、なぜその状態にあるのか」を、推論の余地なく即座に理解することだ。本稿では、Datadogを「ただのグラフ表示ツール」から「エンジニアの認知負荷を最小化する戦闘指揮所」へ変貌させるための、極限の設計術を伝授する。
—
1. 「見るべき指標」の選別：黄金のKPI設計
多くのエンジニアは、ダッシュボードを「メトリクスの墓場」にする。重要なのは、「その数値が動いたとき、今すぐアクションを起こすべきか？」を基準に指標を絞ることだ。
必須の「Redline」ダッシュボード構成
1. Latency (P99/P95): ユーザー体験の劣化はここから始まる。平均値は嘘をつく。
2. Traffic (RPS/RPM): 負荷の突発的な増減は予兆検知の要。
3. Errors (HTTP 5xx/Unhandled Exceptions): アラートのトリガーとなる最優先事項。
4. Saturation (Memory/Disk/Thread Pool): 「あとどれくらい耐えられるか」というリソースの限界点。
—
2. 実践！生産性を爆速化する「隠れたテクニック」
キーボードショートカット：マウス操作は敗北
ダッシュボードをマウスでカチカチ動かしているようでは、障害対応のスピードは上がらない。
- `g` + `d`: ダッシュボード一覧へ即遷移。
- `t`: タイムレンジの素早い切り替え（`1h`, `4h`, `1d`の入力を癖づける）。
- `Cmd/Ctrl + K`: Datadogコマンドパレット。検索や移動はこれだけで完結させる。
絶対に入れるべき「神」設定
- `Event Overlay`: デプロイイベントをグラフに重ねろ。パフォーマンスの劣化がコード変更と相関しているか、一瞬で判別できる。
- `Toplist Widget`: 「どのエンドポイントが一番重いか」「どのホストが一番メモリを食っているか」を並び替える。詳細を探る手間が消える。
—
3. ベストプラクティス：コードとしての監視（Terraform/JSON）
ダッシュボードをUIでポチポチ作るのは「技術的負債」の始まりだ。Datadogの設定はTerraformで管理し、リポジトリに格納せよ。
以下は、最も重要な「Service Overview」を定義する際のベストプラクティス構成例だ。
Terraformによるダッシュボード管理の断片
resource “datadog_dashboard” “service_overview” {
title = “Service: Production Overview”
layout_type = “ordered”
# 重要なレイテンシの可視化
widget {
timeseries_definition {
request {
# P99を基準に、異常なスパイクを見逃さない
q = “p99:trace.http.request.duration{service:my-api} by {endpoint}”
type = “line”
}
title = “P99 Latency by Endpoint”
}
}
# 異常検知を自動化するAnomaly Detection
widget {
timeseries_definition {
request {
q = “anomalies(avg:system.cpu.idle{host:prod-}, ‘basic’, 2, direction=’below’, alert_window=’last_5m’)”
}
title = “CPU Anomaly Detection”
}
}
}
—
4. チーム開発のための「共有化ルール」
ダッシュボードが乱立し、誰も見なくなるのを防ぐために、以下のルールをチームに徹底してほしい。
1. Ownerタグの義務化: 誰がメンテナンスするのか不明なダッシュボードは削除対象とする。
2. 「Why」を書く: Widgetのディスクリプションには、そのグラフが異常を示した際、最初に確認すべきRunbook（障害対応手順書）のURLを必ず含める。
3. Template Variablesの統一: すべてのダッシュボードで `$env`, `$service`, `$host` を共通変数として定義する。これにより、一つの画面から全環境へシームレスにジャンプできる。
—
最後に：オブザーバビリティは「文化」である
ダッシュボードを作って満足してはいけない。真のエンジニアは、障害が起きたときに「このダッシュボードのこのWidgetを見れば、原因が10秒で特定できる」という確信を持って設計を行う。
ツールに支配されるな。ツールを支配し、システムの鼓動を掌握せよ。
今すぐダッシュボードを整理し、ノイズを削ぎ落とし、本当に見るべき「シグナル」だけを浮き彫りにする作業に取り掛かってほしい。
君たちのプロダクトがより堅牢なものになることを期待している。