obsdog

Datadog Fundamentals 認定 / 04 / 06

データ収集

このドメインで学ぶこと

このドメインでは、Datadog にデータを集める 4 つの経路と、集めたデータを後から活かすタグ付けの作法を学びます。経路は、アプリケーションからカスタムメトリクスを送る DogStatsD、クラウド事業者の API を Datadog 側から定期的に呼ぶクローラー方式のクラウドインテグレーション、ホスト上の Agent が conf.d の設定に従って対象を監視する Agent インテグレーション、HTTP でメトリクスやイベントを直接投稿する API エンドポイントです。試験では「この場面ではどの経路が適切か」「COUNT で送ったメトリクスがアプリ内で何の型になるか」「サンプルレートを下げると何が起きるか」「タグの値に使ってはいけないものは何か」のように、仕組みの理解を実務の一場面に当てはめて問われます。数値や既定値は 2026 年 9 月時点の公式ドキュメントに基づきます。

公式ガイドの内容範囲

  • DogStatsD
  • クローラー (クラウドインテグレーション)
  • Agent インテグレーション
  • API エンドポイント
  • タグ付けのベストプラクティス
  • メトリクスと時系列

重要ポイント

  • DogStatsD は Agent に同梱されたメトリクス集約サービスで、StatsD に Histogram 型・サービスチェック・イベント・タグ付けの 4 つの拡張を加える。
  • DogStatsD は UDP で受け取り、アプリケーションは応答を待たない (既定は UDP 8125 番)。届いた値は 10 秒の flush 間隔で 1 点に集約される。
  • DogStatsD の COUNT はアプリ内では RATE として保存され、GAUGE は区間の最後の値、SET は区間内の一意な値の個数になる。
  • HISTOGRAM は Agent 側で max / median / avg / count と 95 パーセンタイルに集約し、DISTRIBUTION はサーバー側で集約する。
  • サンプルレートは 0 から 1 の値で 1 が 100 % 送信。COUNT は受信値を 1 / サンプルレート倍に補正し、GAUGE と SET は補正しない。
  • クラウドインテグレーションはクローラーが事業者の API を定期的に呼ぶ方式。既定間隔は AWS 10 分 (RDS は 3 分)・Azure 2 分・GCP 5 分。
  • Agent インテグレーションは conf.d の conf.yaml.example を conf.yaml に改名し、Agent を再起動して有効化する。既定間隔は 15 秒。
  • API キーはヘッダー DD-API-KEY で渡し、必要なエンドポイントでは Application キーを DD-APPLICATION-KEY で併せて渡す。
  • タグは先頭が文字で 200 文字以内、小文字に正規化される。ユーザー ID やタイムスタンプのように際限なく増える値をタグにしない。
  • カスタムメトリクスはメトリクス名とタグ値 (host タグ含む) の一意な組み合わせごとに数える。タグの値が増えるほど数が増える。

用語と概念

DogStatsD

Datadog Agent に同梱されたメトリクス集約サービスで、アプリケーションからカスタムメトリクス・イベント・サービスチェックを受け取る入口です。StatsD プロトコルを実装しつつ、Histogram 型・サービスチェック・イベント・タグ付けという Datadog 固有の拡張を持ち、この拡張は Datadog 公式クライアントライブラリで使えます。UDP で受け取るので、アプリケーションは応答を待たずに処理を続け、DogStatsD が止まっても巻き込まれません。届いた値は 10 秒の flush 間隔ごとに 1 点へ集約されます。

送信型とアプリ内型の対応

メトリクスには送信時の型 (COUNT / RATE / GAUGE / SET / HISTOGRAM / DISTRIBUTION) とアプリ内で表示される型があり、両者は一致しないことがあります。DogStatsD の COUNT は Agent 間で比較しやすいよう秒あたりに正規化され、アプリ内では RATE として保存されるため小数で表示され得ます。GAUGE は flush 間隔の最後の値、SET はその間隔の一意な値の個数を GAUGE として保存します。HTTP API で直接送ったデータは Agent を通らず、DISTRIBUTION 以外は集約されずに保存されます。

HISTOGRAM と DISTRIBUTION

どちらも値のばらつきを扱う型ですが、集約する場所が違います。HISTOGRAM は Agent 側で flush 間隔ごとに統計を計算し、既定で max / median / avg / count と 95 パーセンタイルを別々のメトリクスとして送ります。集約はホスト単位なので、複数ホストを合わせた正しいパーセンタイルは出せません。DISTRIBUTION は生データを Datadog に送りサーバー側で集約するため、インフラ全体を横断した p50 から p99 のパーセンタイルを後から追加でき、タグの取捨選択もできます。サービスのようにホストから独立した対象の計測に向きます。

サンプルレート

UDP 送信の負荷すら惜しい高頻度の処理では、DogStatsD クライアントに 0 から 1 のサンプルレートを渡して一部だけ送れます。1 は 100 % 送信、0.5 なら半分です。DogStatsD は受け取った値を型に応じて補正し、非サンプリング時の値を推定します。COUNT は 1 / サンプルレート倍、DISTRIBUTION は 1 / サンプルレート回として数え、GAUGE と SET は補正せず、HISTOGRAM は count の統計だけを補正します。通信量は減る一方で精度と粒度を失うため、別ホストへ多数のメトリクスを送る場面向きです。

クローラー方式のクラウドインテグレーション

AWS / Azure / Google Cloud のクラウドインテグレーションは、Datadog 側に資格情報を登録し、クローラーが事業者の API を定期的に呼びメトリクスやタグを取り込む認証ベースの方式です。Agent 無しで EC2 の CloudWatch メトリクスが得られる反面、事業者 API の制約で遅延があり、既定間隔は AWS 10 分 (RDS は 3 分)、Azure 2 分、GCP 5 分です。AWS は Metric Streams で 2 から 3 分に短縮できます。過去データは取り込まず、ホストレベルの可視性が要るなら Agent も入れるのが推奨です。

Agent インテグレーションと conf.d

Agent ベースのインテグレーションは Agent と一緒にインストールされ、Python の check メソッドで収集するメトリクスを定義します。有効化は conf.d/<インテグレーション名>.d/conf.yaml.example を conf.yaml に改名し、必須パラメータを書いて Agent を再起動する 3 段です。instances に複数の対象を並べれば同じチェックで複数インスタンスを監視できます。既定の収集間隔は 15 秒で min_collection_interval で変えられ、読み込みは agent status の Checks 節で確かめます。

API エンドポイントと認証

Datadog API は JSON を返す REST 形式です。認証は API キーをヘッダー DD-API-KEY で渡し、ユーザー権限が要るエンドポイントでは Application キーを DD-APPLICATION-KEY で併せて渡します。ホスト名はサイトごとに違い、US1 は api.datadoghq.com、EU1 は api.datadoghq.eu です。メトリクス送信は POST /api/v2/series で、メトリクスとログの送信にはレート制限がありません。管理系エンドポイントは制限超過で 429 が返り、X-RateLimit 系ヘッダーで枠が分かります。

タグの規則と統一サービスタグ付け

形式は key:value か value 単体で、推奨は key でグループ化できる key:value です。先頭は文字で、文字・数字・アンダースコア・マイナス・コロン・ピリオド・スラッシュ以外はアンダースコアに変換されます。長さは 200 文字まで、小文字に正規化されるので camelCase は避けます。最初のコロンより前が key なので env:staging:east の key は env です。統一サービスタグ付けでは env / service / version の 3 つを揃え、メトリクス・トレース・ログを結び付けます。

カスタムメトリクスとカーディナリティ

カスタムメトリクスはメトリクス名とタグ値 (host タグを含む) の一意な組み合わせごとに 1 つと数えます。endpoint が 2 種類、status が 2 種類なら request.Latency は 4 つです。DogStatsD やカスタムチェックから送るメトリクスはすべてカスタム扱いなので、リクエスト ID のように際限なく増える値をタグにすると数が爆発し課金に直結します。コンテナではカーディナリティを low (kube_namespace) / orchestrator (pod_name) / high (container_id) から選び、既定は low です。

理解度チェック

学んだ内容を 5 問で確認します