Datadog 05

Datadog の三本柱 — 異常を見つけ、原因へたどる順番

メトリクス、ログ、トレースは同じものを別表示しているわけではありません。監視の問いごとに得意な信号を使い分け、一本の調査経路にします。

TL;DR

  1. メトリクスは「異常に気づく」、ログは「何が起きたか」、トレースは「どこで遅いか」。
  2. 三本柱は、検知→局所化→原因確認の順でつなげる。
  3. タグと相関IDをそろえると、Datadog上で信号を横断できる。

01数値・出来事・処理経路を、同じ目的で使い分ける。

各信号が得意とする粒度を区別して、調査の材料をそろえる。

数値・出来事・処理経路を、同じ目的で使い分ける。
三つの円の外側は個別の役割、重なる中央は障害調査での組み合わせを示す。

CPU 80%というメトリクスだけでは理由は不明だが、同時刻のトレースとOOMログを組み合わせると仮説を具体化できる。

メトリクス・ログ・トレースのデータ量を増やすこと自体を目的にしない。答えたい問いと保持範囲を先に決める。

02信号を見始める順序を決めると、迷子になりにくい。

広い時間帯の異常から、ひとつのリクエストの原因へ段階的に絞る。

信号を見始める順序を決めると、迷子になりにくい。
左から右へ進むほど、全体傾向から遅いspan、個別ログへ調査粒度が細かくなる。

p95レイテンシ上昇の時間帯を選び、遅いDB spanを見つけ、同じtrace_idのログから企業IDやクエリ条件を確認する。

平均値だけで正常と判断しない。特定ユーザーだけの遅延は、分位値と個別トレース・ログで初めて見える場合がある。

03サービス名・環境・バージョン・相関IDが、信号を結ぶ鍵になる。

同じサービス・環境・リリースを指す共通語彙を決める。

サービス名・環境・バージョン・相関IDが、信号を結ぶ鍵になる。
中央の共通タグと相関IDが、周囲の三信号を検索可能な一本の関係にしている。

service:cost-provider、env:stg、version:0.0.1を揃えると、デプロイ前後のメトリクス・ログ・トレースを同条件で比較できる。

タグ表記がcost_apiとcost-apiのように揺れると別サービスとして集計される。命名規則を入口で統一する。

結論

  1. 三本柱は代替関係ではなく、調査の異なる段階を支える。
  2. メトリクスで異常を見つけ、トレースとログで原因を掘る。
  3. 共通タグと相関IDが、Datadogを横断調査の道具にする。