カスタムメトリクス

概要

カスタムメトリクスは、Datadog の対応済み統合から自動で流れてくる指標ではなく、利用者側が定義して送り込む指標を指します。注文が確定するまでの秒数、再試行の回数、社内バッチの処理件数のように、その事業でしか意味を持たない数字がここに入ります。実務で重要なのは数え方です。1 個の単位はメトリクス名ではなく、名前とタグ値の組み合わせであるため、名前を 1 つに束ねてタグで分類しても総数は減りません。割当はプランとホスト数から決まり、消費はアカウント全体で合算されます。送信の入口が多く、ログやスパンから生成した指標も同じ枠を消費するので、意図せず増えていることに気づきにくい領域でもあります。

対応済み統合で取れるものと、自分で送るもの

Datadog には多数の統合が用意されていて、対応済み一覧に載っているサービスから流れてくる指標は標準扱いです。それ以外、つまり利用者が自分で定義して送るものがカスタムメトリクスになります。2026 年 8 月時点の公式ドキュメントでは、DogStatsD 経由の送信と自作の Agent チェックが代表例として挙げられ、Marketplace の統合から来る指標や、対応済み一覧に載っていない統合の指標もカスタムとして数えられると説明されています。

表に載らない経路もあります。HTTP の API へ直接送る場合、AWS Lambda から送る場合、そしてログ・APM のスパン・RUM のイベントを材料に生成する場合も、できあがった指標はカスタムとして扱われます。MySQL や PostgreSQL のように、標準の統合でありながら収集対象を利用者が追加できるものもあり、追加した分はカスタムに寄ります。「自分で送った覚えがあるかどうか」で線を引くと外れる、というのが最初に押さえるべき点です。

1 個の数え方は、名前ではなくタグ値の組み合わせ

公式ドキュメントは、カスタムメトリクス 1 個を「メトリクス名とタグ値の一意な組み合わせ」と定義しています。ホストを表すタグも組み合わせに含まれます。ドキュメントが挙げている例では、request.Latency という 1 つの名前に対して、エンドポイントを表すタグが 2 種類、ステータスを表すタグが 2 種類あると、それだけで 4 個になります。 この数え方は、直感とずれた結果を生みます。ダッシュボードに並ぶ名前が 20 個だとしても、それぞれに 3 種類のタグが付き、各タグが 5 通りの値を取れば、実際に数えられる個数は掛け算で伸びていきます。名前を整理して 20 個から 10 個に減らしても、失った分類をタグに移し替えたなら総数は変わりません。減らしたいときに効くのは、名前ではなくタグ値の種類を絞ることです。この掛け算の性質はタグの設計と表裏一体で、タグ設計を見せ方の話だと考えていると足元で個数が増えます。 請求のための集計はさらに一段あります。公式の課金ドキュメントによれば、対象となるのは 1 時間ごとに観測された個数の月平均です。1 日だけ急増した実験のせいで月全体が跳ね上がるわけではない反面、常時流し続けている指標はそのまま平均に乗ります。

割当はホスト数で決まり、消費はアカウント全体で合算される

2026 年 8 月時点の公開情報では、割当はホスト 1 台あたりカスタムメトリクス Pro が 100 個、Enterprise が 200 個です。ここで実務上の意味が変わるのが、公式の課金ドキュメントが明記している合算のしかたです。割当はホスト単位に配られるのではなく、アカウント全体で合算して判定されます。 つまり Pro で 10 台を監視しているなら、全体の枠は 1,000 個です。1 台のアプリケーションサーバーが 400 個を送っていても、他の 9 台が控えめなら超過にはなりません。逆に言えば、ホストごとに 100 個以内かどうかを見ていても意味がなく、見るべきはアカウント全体の合計です。台数を増やすと枠も増えるため、監視対象を減らす作業が個数の余裕を削る方向に働くという、少し意地の悪い関係もあります。 超過分の扱いについて、公式の課金ドキュメントは「割当を 100 個超えるごとに、契約プランに記載された単価で課金する」と説明しています。単価そのものは契約内容によるため、金額の見積もりは契約書と請求明細で確認する必要があります。ここを推測で埋めても数字にならないので、超過が見えた時点で契約側の単価を押さえるのが実務の順序です。

送る前に決めておくと、後から効いてくること

命名と値の制約は、あとから直すと過去のデータと切り離されるため、最初に決める価値があります。2026 年 8 月時点の公式ドキュメントの規則では、名前は英字で始まり、使えるのは ASCII の英数字・アンダースコア・ピリオドで、Unicode は使えません。長さは最大 200 文字ですが、ドキュメントは 100 文字未満を勧めています。そして名前は大文字小文字を区別します。この最後の 1 点が事故になりやすく、片方のサービスが order.Latency、もう片方が order.latency を送ると、2 つの別物として並び、どちらのグラフも本来の半分しか描かれません。 値の側にも制約があります。値は 32 ビットに収まる数値である必要があり、日付やタイムスタンプを値として送る使い方は想定されていません。タイムスタンプの受付窓は未来方向に 10 分、過去方向に 1 時間です。この窓は設計を縛ります。夜間バッチで前日分をまとめて送り直す、障害復旧後に溜まった計測値を一括で流し込む、といった運用は成立しません。過去を埋めたいなら、メトリクスではなくログや別の保管先を使う判断が必要になります。 送信レートについては、公式ドキュメントは固定の上限を課していないと述べています。これは安心材料ではありません。上限で止まらないということは、組み合わせが増え続けても送信は通り続け、気づく契機が請求か集計の重さになるという意味です。Datadog Agent の設定を配布で管理しているなら、タグに入れる値の種類を設定側で制限しておくほうが、あとから探すより安く済みます。

これが無いと何に困るか、そして数え方の取り違え

標準の統合が出してくれるのは、CPU 使用率・キューの長さ・レスポンスの分布といった、どの会社でも同じ形をした指標です。一方で「決済が確定するまでの秒数」「再試行が何回目で成功したか」「社内の締め処理が何件残っているか」は、その事業の外側には存在しない数字なので、誰も代わりに測ってくれません。カスタムメトリクスが無い監視は、サーバーが生きていることまでは言えても、事業が動いていることは言えません。障害対応で本当に困るのはこの差です。インフラの指標がすべて緑のまま、注文だけが 30 分止まっていた、という状況を検知できるかどうかが分かれます。 取り違えとして目立つのは、名前の数を減らせば個数が減るという理解です。数えているのは組み合わせなので、名前を束ねてタグで分けた時点で総数は動きません。もう 1 つは、送っていないつもりの経路の見落としで、ログやスパンから生成した指標も同じ枠を消費します。生成の設定を追加した人と、個数の増加に気づく人が別部署だと、原因の特定に時間がかかります。 近い概念との線引きも押さえておくと迷いません。メトリクスは数値の時系列そのものを指す一般名で、カスタムかどうかは出どころによる区分です。個数が増える現象そのものはカーディナリティとして扱われます。数え方と規則の一次情報は Datadog の公式ドキュメント Custom Metrics と Custom Metrics Billing にあります。