Datadog 11–13

Datadog の運用設計 — ダッシュボード・Monitor・SLOの役割分担

観測画面、異常通知、品質目標は同じものではありません。見るためのダッシュボード、起こすためのMonitor、判断基準としてのSLOを分けると、運用のノイズが減ります。

TL;DR

  1. ダッシュボードは継続観察、Monitorは異常時の行動開始、SLOは品質目標と許容失敗量を扱う。
  2. ダッシュボードはAPMで不足する管理サービスの指標を、必要な分だけ補う。
  3. SLOはCUJ→成功条件→SLI→目標値の順に定義する。

01目的が違う道具を、一つの画面で代替しようとしない。

観察・通知・品質判断を、それぞれ専用の道具へ割り当てる。

目的が違う道具を、一つの画面で代替しようとしない。
三列の「見る・起こす・判断する」と、各列の出力を対応させて読む。

RDS容量の傾向はDashboard、5xx急増はMonitor、30日成功率の目標達成はSLOで扱う。

同じグラフを三か所へ複製するより、判断の入口を一つに決めて相互リンクする。

02APMで既に見えるものを複製せず、判断に必要な差分を足す。

既存のAPMで答えられない運用上の問いだけを追加する。

APMで既に見えるものを複製せず、判断に必要な差分を足す。
左のアプリ信号はAPM、右のAWS管理サービス指標はDashboardという境界を見る。

cost-apiのlatencyはAPMで見て、SQS backlog・RDS接続数・ECS稼働Task数だけを運用Dashboardへ置く。

「いつか使うかも」でウィジェットを増やさない。インシデントや容量判断に使った実績を基準に残す。

03数値を先に決めず、重要な利用体験の成功条件を測定可能にする。

ユーザーが価値を得る経路から、測定と目標へ順番に落とす。

数値を先に決めず、重要な利用体験の成功条件を測定可能にする。
CUJから成功条件、SLI、SLO、エラーバジェットへ進む一本道を左から読む。

GET /cost/awsが正しい値を時間内に返すことをCUJとし、成功率とp95をSLI、30日目標をSLOにする。

目標値を先に高く置かない。実測ベースラインとユーザー期待、運用コストを見て調整する。

結論

  1. ダッシュボードは観察、Monitorは通知、SLOは品質判断に使う。
  2. ダッシュボードは必要な管理サービス指標だけを補う。
  3. SLOはCUJから設計し、エラーバジェットをチームの意思決定に使う。