Datadog カスタムメトリクス完全ガイド：導入・送信方法・可視化ベストプラクティス

2026年5月12日

Contents

1 Datadog カスタムメトリクスとは
2 前提条件と料金モデル
3 カスタムメトリクスの送信方法
4 Metric Summary とグラフエディタでの単位設定
- 4.1 Metric Summary における単位設定
- 4.2 ダッシュボードウィジェットでのオーバーライド
5 実装例とデバッグ手順
6 ダッシュボードへの可視化ベストプラクティスと落とし穴対策
7 まとめ

スポンサードリンク

Datadog カスタムメトリクスとは

Datadog のカスタムメトリクスは、標準で提供されるインフラ系指標に加えて、アプリケーションやビジネスロジック独自の数値を可視化できる機能です。無料プランでも一定量まで無償で送信できますが、利用上限や課金タイミングは公式ドキュメント（Custom Metrics Limits）で随時更新されているため、導入前に必ず最新情報を確認してください。この記事では、設定手順・送信方法・料金モデルの注意点を実務で使える形でまとめます。

前提条件と料金モデル

このセクションでは、カスタムメトリクスを利用するために必要な最低限の設定と、課金が発生するタイミングについて解説します。正しい認識がないまま運用すると、予期せぬコストが蓄積される可能性があります。

無料枠とレートリミット

公式 Docs に記載されている数値はバージョンやリージョンごとに変わります。執筆時点の目安は以下です（2026‑05 時点）：

項目	現行上限（目安）
無料メトリクスポイント	月間 5,000 ポイントまで（プラン変更やプロモーションで変動あり）
API 送信レートリミット	1 分間 3,000 ポイント（リージョン別に若干差異）

重要：上記はあくまで目安です。導入直前に https://docs.datadoghq.com/ja/metrics/custom_metrics/ を確認し、最新の無料枠・レートリミットを取得してください。

課金モデルの正しい理解

カスタムメトリクスは 送信されたポイント数 に対して従量課金されます。アラート設定を除外したからといって、メトリクス自体の使用料が免除されるわけではありません。以下の点に注意してください。

ポイント単位で課金：送信されたデータポイント（時系列の 1 データ）ごとに料金が加算されます。
アラートは別費用：カスタムメトリクスをベースにしたアラートを作成すると、追加で Alert Evaluation の課金が発生します。不要なアラートだけ除外すれば、こちらのコストは抑えられます。
リージョン別エンドポイント：EU リージョン向けには api.datadoghq.eu、US 以外にも api.ddog-gov.com（政府クラウド）などがあります。使用する Datadog インスタンスに合わせてエンドポイントを切り替えてください。

エージェント設定 `custom_metrics_enabled` のバージョン依存

Datadog Agent 7.33 以降では、デフォルトでカスタムメトリクス送信が有効化されています。そのため、古いエージェント（7.32 以前）を使用している場合は datadog.yaml に以下の設定が必要です。

# Agent &lt; 7.33 のみ必須
custom_metrics_enabled: true

# Agent < 7.33 のみ必須

custom_metrics_enabled: true

最新バージョンにアップデートすれば、上記行は省略可能です。エージェントのバージョンは datadog-agent version コマンドで確認してください。

カスタムメトリクスの送信方法

カスタムメトリクスは DogStatsD, HTTP API, 統合エージェント の 3 通りから選択できます。各手段の特徴と導入手順を H3 レベルで整理しました。

DogStatsD を使ったローカル送信

DogStatsD は UDP（または TCP）経由で Datadog Agent にメトリクスを転送する軽量プロトコルです。エージェントがインストールされているサーバー上で動作させるケースに最適です。

設定手順

Agent の DogStatsD ポートを有効化（デフォルトは 8125）

yaml # /etc/datadog-agent/datadog.yaml dogstatsd_port: 8125 # UDP デフォルト use_tcp: false # 必要に応じて true に変更

エージェントを再起動

bash sudo systemctl restart datadog-agent

言語別 StatsD クライアントでメトリクス送信
後述の実装例（Python / Java / Node.js）をご参照ください。

Datadog API での直接送信

API 経由はエージェントが不要なサーバーレス環境や外部サービスからメトリクスを送る際に利用します。リージョンごとのエンドポイントに注意してください。

手順概要

API キー取得：Datadog コンソール → Integrations → APIs で api_key をコピー。
HTTP POST リクエスト（例は EU エンドポイント）

bash curl -X POST "https://api.datadoghq.eu/api/v1/series" \ -H "Content-Type: application/json" \ -H "DD-API-KEY: <YOUR_API_KEY>" \ -d '{ "series": [ { "metric":"myapp.request.latency", "points":[[ $(date +%s), 123 ]], "type":"gauge", "tags":["env:prod","service:web"] } ] }'

レートリミットの確認：1 分間に 3,000 ポイントが保証されます。超過すると 429 Too Many Requests が返りますので、バックオフやバッチ送信で対処してください。

統合エージェントからの自動収集

Docker、Kubernetes、AWS ECS など公式インテグレーションは、コンテナ/ポッドに付与されたタグを自動的に取得し、カスタムメトリクスとして送信できます。設定例は以下です。

Docker 統合の例

# /etc/datadog-agent/conf.d/docker.d/conf.yaml
init_config:

instances:
  - url: &quot;unix://var/run/docker.sock&quot;
    custom_metrics:
      - name: &quot;docker.cpu.percent&quot;
        type: gauge
        tags:
          - &quot;env:prod&quot;

# /etc/datadog-agent/conf.d/docker.d/conf.yaml

init_config:

instances:

- url: "unix://var/run/docker.sock"

custom_metrics:

- name: "docker.cpu.percent"

type: gauge

tags:

- "env:prod"

設定後はエージェントを再起動し、datadog-agent status でカスタムメトリクスが有効化されたことを確認します。

Metric Summary とグラフエディタでの単位設定

Datadog の UI では Metric Summary と Dashboard の Graph Editor の二箇所で単位を管理できます。ここではそれぞれの手順と、単位不一致を防ぐベストプラクティスを紹介します。

Metric Summary における単位設定

コンソール左メニュー → Metrics → Summary を開く。
対象メトリクス（例：myapp.request.latency）を検索し、右側の Edit unit ボタンをクリック。
ドロップダウンから seconds, milliseconds, bytes など適切な単位を選択、もしくはカスタム文字列を入力して保存します。

ダッシュボードウィジェットでのオーバーライド

任意の Dashboard に Timeseries ウィジェットを追加。
Display タブ → Unit override を有効にし、Metric Summary とは別の単位（例：milliseconds）を設定可能です。
設定はウィジェットごとに保存されるため、同一メトリクスでも用途に応じた表示が実現できます。

ポイント：Metric Summary の単位は全体的なデフォルトになるので、ウィジェットで上書きする場合は意図しない混乱を防ぐために「どのウィジェットで何単位か」をドキュメント化しておくとよいでしょう。

実装例とデバッグ手順

以下では主要言語（Python、Java、Node.js）向けの DogStatsD クライアント サンプルを示します。コード実装後は必ずエージェントステータスで送信状況を確認し、レートリミットや名前空間衝突がないか検証してください。

Python（datadog‑statsd）

pip install datadog

1 2	pip install datadog

from datadog import statsd

# メトリクス名はプレフィックスで階層化
metric_name = &quot;myapp.request.latency&quot;
value_ms    = 250   # ミリ秒単位

statsd.gauge(metric_name, value_ms,
             tags=[&quot;env:staging&quot;, &quot;service:web&quot;])

from datadog import statsd

# メトリクス名はプレフィックスで階層化

metric_name = "myapp.request.latency"

value_ms = 250 # ミリ秒単位

statsd.gauge(metric_name, value_ms,

tags=["env:staging", "service:web"])

デバッグコマンド

datadog-agent status | grep myapp.request.latency

1 2	datadog-agent status \| grep myapp.request.latency

Java（dd-java-agent + StatsD client）

アプリ起動時にエージェントを添付

bash java -javaagent:/opt/datadog/dd-java-agent.jar \ -Ddd.service=myapp \ -jar myapp.jar

コード例（NonBlockingStatsDClient 使用）

import com.timgroup.statsd.NonBlockingStatsDClient;
import com.timgroup.statsd.StatsDClient;

public class MetricsExample {
    private static final StatsDClient statsd = new NonBlockingStatsDClient(
            &quot;myapp&quot;,          // プレフィックス
            &quot;localhost&quot;, 8125);

    public static void main(String[] args) {
        double latencyMs = 180.0;
        statsd.gauge(&quot;request.latency&quot;, latencyMs,
                     &quot;env:prod&quot;, &quot;service:api&quot;);
    }
}

import com.timgroup.statsd.NonBlockingStatsDClient;

import com.timgroup.statsd.StatsDClient;

public class MetricsExample {

private static final StatsDClient statsd = new NonBlockingStatsDClient(

"myapp", // プレフィックス

"localhost", 8125);

public static void main(String[] args) {

double latencyMs = 180.0;

statsd.gauge("request.latency", latencyMs,

"env:prod", "service:api");

}

デバッグコマンド

datadog-agent status | grep request.latency

1 2	datadog-agent status \| grep request.latency

Node.js（hot-shots）

npm install hot-shots

1 2	npm install hot-shots

const StatsD = require('hot-shots');
const statsd = new StatsD({
  host: '127.0.0.1',
  port: 8125,
  prefix: 'myapp.'
});

const latencyMs = 95;
statsd.gauge('request.latency', latencyMs,
             ['env:dev','service:web']);

const StatsD = require('hot-shots');

const statsd = new StatsD({

host: '127.0.0.1',

port: 8125,

prefix: 'myapp.'

});

const latencyMs = 95;

statsd.gauge('request.latency', latencyMs,

['env:dev','service:web']);

デバッグコマンド

datadog-agent status | grep request.latency

1 2	datadog-agent status \| grep request.latency

共通デバッグチェックリスト

チェック項目	確認方法
送信レート超過	エージェントログに `Rate limit exceeded` が出力されるか
名前空間衝突	`datadog-agent status` の Metrics セクションで同名・同タグが重複していないか
タグ付与漏れ	送信コードの `tags=` パラメータが必ず2つ以上（環境・サービス）設定されているか

ダッシュボードへの可視化ベストプラクティスと落とし穴対策

カスタムメトリクスを有効活用するためのダッシュボード設計指針と、実務でよく起こるミスを防ぐチェックリストをまとめました。

作成手順とポイント

Dashboard の作成：左上 Dashboards → New Dashboard → 名前入力。
ウィジェット追加：+ Add Widget → Timeseries を選び、検索ボックスにメトリクス名（例 myapp.request.latency）を入力。
タグでフィルタリング：env:prod, service:web など必要なタグだけ残すことで、環境別・サービス別の視認性が向上します。
単位オーバーライド：Metric Summary と同じ単位に統一するか、ウィジェットごとに適切に上書きしてください。

ベストプラクティス

項目	推奨手法
メトリクス名の階層化	`myapp.` → `myapp.db.`, `myapp.api.` のようにプレフィックスで分類
タグ付与の徹底	環境 (`env:`) とサービス (`service:`) を必ず2つ以上設定し、CI でコードレビューを実施
単位の一貫性	Metric Summary に統一単位を設定し、ウィジェットでは必要に応じてのみ上書き
アラートは最小化	カスタムメトリクスベースのアラートは `notify_no_data:false` で不要な評価コストを削減

落とし穴対策チェックリスト

項目	対策例
無料枠超過による予期せぬ課金	定期的に Usage ページでポイント使用量をモニタリング
リージョンミスマッチ	EU ユーザーは必ず `api.datadoghq.eu`、US は `api.datadoghq.com` を利用
エージェントバージョン差異	新規インストール時は 7.33 以降を推奨し、`custom_metrics_enabled` の記述は省く
レートリミット超過によるデータ欠損	バッチ送信やサンプリングで 1 分間 3,000 ポイント以下に抑える
単位不一致での分析エラー	Metric Summary とウィジェット単位を定期的にレビュー

まとめ

Datadog のカスタムメトリクスは、正しく設定すれば無料枠内でも十分活用でき、アラートやダッシュボードと組み合わせることで高度な可観測性を実現できます。導入時に 最新の無料枠・レートリミット を公式 Docs で確認し、リージョン別エンドポイント と Agent バージョン依存設定 に注意することがコスト管理の鍵です。また、メトリクス送信はポイント単位で課金されるため、アラート除外だけでは料金を抑えられない点を忘れずに設計してください。

本稿で紹介した手順とベストプラクティスを参考に、まずは小規模なサンプルメトリクスから導入し、使用量やレートリミットの挙動を確認しながら段階的に拡張していくことをおすすめします。これにより、正確かつコスト効率の高い Datadog カスタムメトリクス運用が実現できます。

スポンサードリンク

-Datadog

comment コメントをキャンセル

: Datadog

DatadogとNew Relic比較（2026年版）—PoCと移行ガイド

DatadogとNew Relicの2024〜2026年の主要アップデートと設計思想を整理し、APM／メトリクス／ログ／Synthetics／RUM／セキュリティ／コストごとにPoC検証項目と移行手順を提示します。OpenTelemetryのdual-writeやTerraformを活用した移行実務、コスト試算テンプレートも付録として提供します。

: Datadog

2026年版 Datadog 料金プランとコストシミュレーション

Datadogはモジュラー型従量課金モデルで、インフラ監視に加えAPM・ログ・カスタムメトリクスなどをオプション料金として提供しています。

: Datadog

Datadog APM導入ガイド：概要・言語別設定・Docker/Kubernetes実装手順

Datadog APM を導入すればサービス間のリクエスト経路をコードレベルで可視化し、ボトルネックやエラー原因を迅速に特定できます。本稿では概要・前提条件から主要言語別設定、コンテナ環境でのエージェント連携、データ可視化方法、運用ベストプラクティス、CI/CD への自動組み込みまでを網羅しています。

2026年版 Sony α1 中古価格と購入ポイント徹底解説

Galaxy Book3 360 レビュー（2025年版）｜S Pen搭載13〜14型2-in-1

Datadog カスタムメトリクス完全ガイド：導入・送信方法・可視化ベストプラクティス

Datadog カスタムメトリクスとは

前提条件と料金モデル

無料枠とレートリミット

課金モデルの正しい理解

エージェント設定 custom_metrics_enabled のバージョン依存

カスタムメトリクスの送信方法

DogStatsD を使ったローカル送信

設定手順

Datadog API での直接送信

手順概要

統合エージェントからの自動収集

Docker 統合の例

Metric Summary とグラフエディタでの単位設定

Metric Summary における単位設定

ダッシュボードウィジェットでのオーバーライド

実装例とデバッグ手順

Python（datadog‑statsd）

デバッグコマンド

Java（dd-java-agent + StatsD client）

デバッグコマンド

Node.js（hot-shots）

デバッグコマンド

共通デバッグチェックリスト

ダッシュボードへの可視化ベストプラクティスと落とし穴対策

作成手順とポイント

ベストプラクティス

落とし穴対策チェックリスト

まとめ

エージェント設定 `custom_metrics_enabled` のバージョン依存