メトリクス

メトリクスの正体はデータポイントの列

Datadog のメトリクスは「値とタイムスタンプの組」というデータポイントの連なりで、この連なりを時系列 (タイムシリーズ) として保存します。秒未満のタイムスタンプは最も近い秒に丸められ、同じ秒に複数の値が届いた場合は後から届いた値で上書きされます (2026 年 8 月時点・出典: Metrics)。この「1 秒 1 点」という構造を知っておくと、後述する集約やロールアップの挙動が腹落ちしやすくなります。メトリクスの概念そのものは用語辞典のメトリクスの項でも整理しています。実務での価値は明快で、数百台の環境でも「どこが悪化しているか」を数十秒で絞り込める一覧性にあります。ログを 1 行ずつ読んで全体像をつかむことは人間には不可能ですが、数値の推移なら 1 枚のグラフで語れます。

count から distribution まで、5 つのタイプを見分ける

メトリクスには型があり、意味がそれぞれ違います。送信時の型は SET を含む 6 種 (COUNT・RATE・GAUGE・SET・HISTOGRAM・DISTRIBUTION) があり、Datadog のアプリ内ではこれらが COUNT・RATE・GAUGE・HISTOGRAM・DISTRIBUTION の 5 つのタイプに対応付けられます (2026 年 8 月時点・出典: Metric Types)。本記事はこのアプリ内 5 タイプを軸に整理します。COUNT は一定間隔内に起きた事象の総数で、リクエスト数や DB 接続数に使います。RATE は同じ事象を秒あたりに正規化した値です。GAUGE はその間隔内に最後に送られた値のスナップショットで、空きディスク容量やメモリ使用量のような「いま測ればこの値」という連続量に向きます。HISTOGRAM は Agent 側で集約して平均・中央値・最大・95 パーセンタイルなどの派生メトリクスを作る型、DISTRIBUTION は生の値をすべて Datadog 側へ送りサーバー側で集約する型で、インフラ全体を横断したパーセンタイル計算ができます。型選びを誤ると数字そのものが狂います。たとえば累積カウンタを GAUGE で送ると増分ではなく積算値のグラフになり、アラートのしきい値設計が根本から成り立ちません。

インテグレーション・Agent・DogStatsD・API、どれで送るか

システムの健康状態を映す標準メトリクスは、1,000 を超えるインテグレーションを有効にするだけで自動的に集まります (2026 年 8 月時点・出典: Metrics)。自前の数値を送りたい場合の経路は主に 3 つで、Datadog Agent のカスタムチェック、アプリケーションから UDP で送る DogStatsD、そして HTTP API です。さらに、すでに取り込んだログ・トレース・RUM イベントから件数や統計値をメトリクスとして生成する方法もあり、「コードに 1 行も手を入れずにエラー件数のメトリクスを作る」といった芸当ができます。経路の選択は保守コストに直結します。アプリ内の計測は DogStatsD 経由が定石ですが、まず既存のログから生成する方法で済むかを先に検討すると、計測コードの散在を防げます。

クエリは 2 段の集約でできている

グラフに描かれる線は生データそのものではありません。クエリは「メトリクス名を選ぶ → タグで絞る → 時間方向に集約する → 空間方向に集約する」という段階を踏み、時間集約 (ロールアップ) は必ず適用されます。たとえば 4 時間分を表示すると、データポイントは 2 分間隔のバケツにまとめられ、既定では各バケツの平均が描かれます (2026 年 8 月時点・出典: Metrics)。集約方法は avg のほか sum・min・max・count を選べ、rollup 関数で粒度も指定できます。空間集約はホストやタグをまたいだまとめ方で、数百台を region 別の 4 本の線に束ねるのがその典型です。ここを理解する実益は「見えているグラフを疑えるようになる」ことです。瞬間的なスパイクは広い表示範囲では平均に均されて消えるため、ピークを追うなら max ロールアップに切り替える、という判断が自分でできるようになります。

保持期間は 15 ヶ月、ただし粒度は粗くなる

メトリクス (タグと値) の保持期間は 15 ヶ月です (2026 年 8 月時点・出典: Data Retention Periods)。15 ヶ月という長さの意味は「前年同期と比べられる」ことにあります。季節性のあるサービスで「この負荷は異常か、毎年恒例か」を判断するには 12 ヶ月では足りず、13 ヶ月目以降が効いてきます。一方で、長期間の表示ほど時間集約のバケツは大きくなり、細かい凹凸は均されていきます。「3 ヶ月前のあの 30 秒のスパイク」を後から精密に検死することはできないため、瞬間の異常はその場でモニターに検知させ、メトリクスの長期保持は傾向分析と容量計画に使う、という使い分けが現実的です。なおログの保持期間はインデックス設定に依存する別物で、保持期間の用語解説で混同を整理しています。

カーディナリティの掛け算が課金の「本数」を決める

カスタムメトリクスの課金理解で最初に押さえるべきは、単価ではなく数え方です。Datadog はカスタムメトリクスを「メトリクス名とタグ値 (host タグを含む) の一意な組み合わせ」1 つを 1 個として数えます (2026 年 8 月時点・出典: Custom Metrics)。公式ドキュメントの例では、request.Latency というメトリクスに endpoint タグ 2 値と status タグ 2 値が付くと、それだけで 2 × 2 = 4 個のカスタムメトリクスです。

この掛け算構造ゆえに、user_id や request_id のような値の種類が際限なく増えるタグを 1 つ足すだけで、時系列数は桁違いに跳ね上がります。いわゆるカーディナリティ事故です。送信側に固定のレート制限はなく、割当を超えた分は使用量に応じて課金される仕組みのため、事故は請求書で発覚しがちです。防波堤としては、タグ構成を後から制御できる Metrics without Limits の活用と、カスタムメトリクスの本数を定期的に棚卸しする運用が公式に用意されています。料金体系の全体像は料金の読み解きで扱っています。

最初に決める命名とタグの規約

命名には公式の制約があります。メトリクス名は英字で始まり、ASCII の英数字・アンダースコア・ピリオドのみで構成し、200 文字以内 (UI の見やすさでは 100 文字未満推奨)。それ以外の文字はアンダースコアに変換され、Unicode は使えず、大文字小文字は区別されます (2026 年 8 月時点・出典: Custom Metrics)。制約の範囲内でどう名付けるかはチームの規約次第ですが、「サービス名.対象.性質」のようにピリオドで階層を切る形に揃えると、メトリクス一覧が自動的に木構造として読めるようになります。タグ側の規約はさらに重要で、環境は env、サービスは service のようにキー名を全チームで統一しておかないと、後から「本番だけ」を横断集計できない画面が量産されます。命名とタグは送信を始めた瞬間から履歴に蓄積されるため、走り出してからの変更は過去データとの連続性を失います。最初の 1 本を送る前に 30 分だけ規約を決める、その 30 分が後の数年を楽にします。

よくある誤解 - 平均の平均・count と rate

第一の誤解は「平均の平均」です。ホストごとの平均レイテンシをさらに平均しても、全体の正しい平均にはなりません。リクエスト数が 10 倍違うホスト同士の平均を対等に足し合わせてしまうからです。全体のパーセンタイルや正確な平均が要る場面では、生データをサーバー側で集約する DISTRIBUTION 型を使うのが公式の用意した答えです (2026 年 8 月時点・出典: Metric Types)。第二の誤解は COUNT と RATE の混同で、COUNT は間隔内の総数、RATE は秒あたりの数です。集計間隔が変わると COUNT の値は変わりますが RATE は変わらないため、「グラフの値が期待の 10 分の 1 になった」ときは型とロールアップをまず疑ってください。第三の誤解は「HISTOGRAM のパーセンタイルは合成できる」というもので、Agent 側で集約済みの 95 パーセンタイル同士を平均しても全体の 95 パーセンタイルにはなりません。誤解はどれも「集約は情報を捨てる操作である」という一点に帰着します。どの段階で何が捨てられるかを意識することが、メトリクスを読む技術のほぼすべてです。