Datadogとは｜できること・料金・仕組みと他ツールとの違いを実例で解説

サーバーに入れた Datadog Agent が数値・ログ・トレースを集めて Datadog（SaaS）へ送り、画面のダッシュボードで見て、モニターが異常を通知します。クラウドの数値は API 連携で直接集めます。

flowchart TD
    A[アプリ・サーバー] -->|メトリクス・ログ・トレース| G[Datadog Agent]
    C[クラウド AWS など] -->|API 連携| D[(Datadog SaaS)]
    G -->|HTTPS| D
    D --> V[ダッシュボードで見る]
    D --> M[モニターが通知]

よく出る言葉を先にまとめます。

確認環境：Ubuntu 24.04.4・Python 3.11.15・datadog（Python ライブラリ）0.55.0・ddtrace 4.16.0。DogStatsD の形式で送ったデータグラムを自作の UDP 受信プログラムで受け、Agent の集計（10秒ごと）をまねたプログラムで集計し、ddtrace のトレースとモニター作成の API リクエストを自作の擬似サーバーで受けて中身を記録しました。ホスト数の数え方と料金の試算は Python で計算しました。Datadog Agent 本体は動かしておらず、設定項目とエラー文は Agent 7.84.5 のソース（GitHub）の設定例とコードで、仕様・画面・料金は docs.datadoghq.com と datadoghq.com の料金ページで、他の製品は各公式サイトで確かめました（確認日 2026年10月22日）。

Datadogとは（読み方・どんな会社のサービスか）

この節では、Datadog が何をするサービスで、どこの会社が出しているかが分かります。

Datadog（データドッグ）は、サーバー・コンテナ・クラウド・アプリ・ログのデータを集めて、1つの画面で見たり、異常を通知したりするための SaaS（インターネット越しに使うサービス）です。 自分で監視用のサーバーを立てて運用する必要がなく、ホストに Agent を入れるか、クラウドと API でつなぐとデータが届き始めます。

提供している Datadog, Inc. の概要です。

監視とオブザーバビリティの違い

Datadog は自社を「オブザーバビリティ（observability、可観測性）」のプラットフォームと呼んでいます。似た言葉の「監視」との違いは次のとおりです。

Datadogを使うと何が変わるか

Datadogでできること（製品の早見表）

この節では、Datadog の主な製品と、それぞれで何が見られるかが分かります。

Datadog は機能ごとに製品が分かれていて、使う製品の分だけ料金がかかります。最初は Infrastructure Monitoring から始め、必要に応じて APM・ログを足す順が一般的です。

公式ドキュメント（日本語版）の製品カテゴリは「インフラストラクチャー」「アプリケーションパフォーマンス」「Digital Experience」「Software Delivery」「セキュリティ」「AI Observability」「ログ管理」などに分かれています。

メトリクス・ログ・トレースの関係（調べる順番）

この節では、3種類のデータがそれぞれ何に答え、どうつながるかが分かります。

障害を調べるときは、次の順で行き来します。

flowchart TD
    M[モニターが通知] --> D[ダッシュボードでメトリクスを見る]
    D -->|service と env で絞る| T[APM で遅いトレースを探す]
    T -->|trace_id でつなぐ| L[同じ処理のログを読む]
    L --> F[原因を直す]

この行き来を可能にするのが、統合サービスタグ付け（Unified Service Tagging） です。公式ドキュメントは、env・service・version の3つを予約されたタグとし、同じ値をメトリクス・トレース・ログに付けることで、互いに移動できると説明しています。アプリ側では環境変数 DD_ENV・DD_SERVICE・DD_VERSION で指定します（後の節で、この3つが自動でタグになる様子を実物で見せます）。

Datadog Agentの役割と仕組み

この節では、Agent が何をしていて、どのポートで何を受けるかが分かります。

Datadog Agent は、監視するホストで動くソフトです。 決まった数値を集め、アプリから届くデータを受け、まとめて Datadog に送ります。2026年10月22日時点の最新は Agent 7.84.5（GitHub のリリース、2026年10月21日）です。

Agent が使う主なポートです（設定の既定値。Agent 7.84.5 の設定例と公式ドキュメントで確認）。

設定ファイル datadog.yaml

Linux の設定ファイルは /etc/datadog-agent/datadog.yaml です。Agent 7.84.5 の設定例から、最初に触る項目だけを抜き出すと次のとおりです。

api_key: <API キー>          # 必須。データを送るためのキー（環境変数 DD_API_KEY）
site: ap1.datadoghq.com      # 既定は datadoghq.com（US1）。アカウントのサイトに合わせる
env: prod                    # このホストの env タグ
tags:
  - team:backend
logs_enabled: true           # ログ収集は既定で false
apm_config:
  enabled: true              # 既定で true。受け付けるポートは 8126
# dogstatsd_port: 8125       # 既定 8125。クライアントも同じ UDP ポートに送る

キーは2種類あります。設定例のコメントでは、API キーは「Agent がメトリクスやイベントを送るためのキー」、アプリケーションキーは「Datadog の API をプログラムから使うためのキー」と説明されています。

Agent のコマンド

sudo systemctl status datadog-agent        # 動いているか
sudo systemctl restart datadog-agent       # 設定を変えたら再起動
sudo datadog-agent status                  # 状態のページ（API キー・各チェックの結果）
sudo -u dd-agent -- datadog-agent check <チェック名>   # 1つのチェックを試す
sudo datadog-agent flare                   # サポートに送る診断情報をまとめる

インストールは、Datadog の画面（Fleet Automation）で OS を選ぶと、その環境用のコマンドが表示されるので、それをホストで実行します。Docker・Kubernetes 向けの入れ方も、同じ画面と公式ドキュメントにあります。

DogStatsDでメトリクスを送る（Pythonで実際に送った中身）

この節では、アプリから Agent へ送られる「DogStatsD」のデータが、実際にどんな文字列かが分かります。

DogStatsD の形式は 名前:値|種類|#タグ という1行の文字列です。 公式ドキュメントの形は次のとおりです。

<METRIC_NAME>:<VALUE>|<TYPE>|@<SAMPLE_RATE>|#<TAG_KEY_1>:<TAG_VALUE_1>,<TAG_2>

Agent の代わりに、届いた UDP のデータをそのまま表示するプログラムを用意しました。

"""DogStatsD の代わりに UDP を受けて、届いたデータグラムをそのまま表示する。"""
import socket, sys
port = int(sys.argv[1]) if len(sys.argv) > 1 else 8125
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("127.0.0.1", port))
print(f"listening udp 127.0.0.1:{port}", flush=True)
n = 0
while True:
    data, addr = s.recvfrom(65535)
    n += 1
    print(f"--- packet {n} ({len(data)} bytes)", flush=True)
    for line in data.decode().split("\n"):
        if line:
            print(line, flush=True)

Python の datadog ライブラリ（pip install datadog）で、種類の違うデータを1つずつ送りました。Agent の既定のポートは 8125 ですが、ここでは受信プログラムを 29000 番で待たせています。

from datadog import initialize, statsd
import time

initialize(statsd_host="127.0.0.1", statsd_port=29000)

tags = ["env:dev", "service:shop-api"]
statsd.increment("shop.order.count", tags=tags + ["status:ok"])        # カウント（+1）
statsd.increment("shop.order.count", value=3, tags=tags + ["status:ok"])
statsd.gauge("shop.queue.size", 42, tags=tags)                           # ゲージ（今の値）
statsd.histogram("shop.request.latency", 0.231, tags=tags)               # ヒストグラム
statsd.distribution("shop.request.duration", 231, tags=tags)            # ディストリビューション
statsd.set("shop.user.unique", "user-1001", tags=tags)                   # セット（種類の数）
statsd.timing("shop.db.query_ms", 12.5, tags=tags)                       # タイマー
statsd.service_check("shop.api.can_connect", statsd.OK, tags=tags, message="ok")
statsd.event("デプロイ完了", "v1.4.2 を本番に反映", alert_type="info", tags=tags)
statsd.increment("shop.page.view", sample_rate=0.5, tags=tags)           # 50% だけ送る
time.sleep(0.2)

受信プログラムに届いた中身です。

listening udp 127.0.0.1:29000
--- packet 1 (57 bytes)
shop.order.count:1|c|#env:dev,service:shop-api,status:ok
--- packet 2 (57 bytes)
shop.order.count:3|c|#env:dev,service:shop-api,status:ok
--- packet 3 (47 bytes)
shop.queue.size:42|g|#env:dev,service:shop-api
--- packet 4 (55 bytes)
shop.request.latency:0.231|h|#env:dev,service:shop-api
--- packet 5 (54 bytes)
shop.request.duration:231|d|#env:dev,service:shop-api
--- packet 6 (55 bytes)
shop.user.unique:user-1001|s|#env:dev,service:shop-api
--- packet 7 (51 bytes)
shop.db.query_ms:12.5|ms|#env:dev,service:shop-api
--- packet 8 (58 bytes)
_sc|shop.api.can_connect|0|#env:dev,service:shop-api|m:ok
--- packet 9 (88 bytes)
_e{18,25}:デプロイ完了|v1.4.2 を本番に反映|t:info|#env:dev,service:shop-api

1回の呼び出しが、1行のテキストになって UDP で飛んでいるだけでした。読み方は次のとおりです。

イベントの {18,25} は、タイトル「デプロイ完了」（6文字×UTF-8 で3バイト＝18バイト）と本文のバイト数です。sample_rate=0.5 の shop.page.view は、同じスクリプトを4回動かして届いたのが2回でした。届いた行には @0.5 が付き、受け手はこれを見て「実際は2倍あった」と割り戻します。

シェルからも送れます。公式ドキュメントの例です（/dev/udp は bash の機能です。zsh では nc の形を使います）。

echo -n "custom_metric:60|g|#shell" >/dev/udp/localhost/8125
echo -n "custom_metric:60|g|#shell" | nc -4u -w0 127.0.0.1 8125

env・service・version は環境変数から自動でタグになる

DD_ENV・DD_SERVICE・DD_VERSION を付けて動かすと、コードに書いていない env・service・version のタグが全部の行に付きました。バッファを有効にしたクライアントでは、4つのメトリクスが改行区切りで1つのパケット（278バイト）にまとまって届きました。

$ DD_ENV=prod DD_SERVICE=shop-api DD_VERSION=1.4.2 python send2.py
--- packet 39 (278 bytes)
shop.order.count:1|c|#status:ok,env:prod,service:shop-api,version:1.4.2
shop.order.count:1|c|#status:ok,env:prod,service:shop-api,version:1.4.2
shop.order.count:1|c|#status:ok,env:prod,service:shop-api,version:1.4.2
shop.queue.size:40|g|#env:prod,service:shop-api,version:1.4.2

UDP は「届いたか」を確かめない

DogStatsD は UDP なので、送る側は届いたかどうかを知りません。受け手がいないポート（29099）に送っても、例外は出ずに終わりました。

$ python send2.py
sent to 29099 without error

さらに、同じカウントを3,000回、間を置かずに送り、受信した数を数えました。受け手は上の Python の受信プログラム（処理が遅い）です。

消えた割合は受け手の速さで変わりますが、「消えても送り手は気付かない」点は変わりません。公式ドキュメントも、UDP ではネットワークのエラーをクライアントが検出できないこと、OS のバッファが一杯になるとデータグラムが捨てられることを挙げ、1つのデータグラムに複数のメトリクスを詰めるバッファの利用と、UDP なら1パケット1,472バイト以下を勧めています。

メトリクスの種類とAgentの集計（count・gauge・histogram）

この節では、送った値が Datadog の画面でどんな数値になるかが分かります。

Agent の DogStatsD は、届いた値をすぐには送らず、10秒ごとにまとめて（フラッシュして） から送ります。公式ドキュメントの説明をもとに、その集計をまねた小さなプログラムを書き、公式の例と同じ8つの値 [1,1,1,2,2,2,3,3] をヒストグラムとして送りました。

from datadog import initialize, statsd
initialize(statsd_host="127.0.0.1", statsd_port=29002)
for v in [1, 1, 1, 2, 2, 2, 3, 3]:                     # 公式ドキュメントの例と同じ8つの値
    statsd.histogram("web.request.latency", v, tags=["env:dev"])
for i in range(25):
    statsd.increment("web.request.count", tags=["env:dev"])
for q in [10, 7, 3]:
    statsd.gauge("web.queue.size", q, tags=["env:dev"])
for u in ["u1", "u2", "u1", "u3", "u2"]:
    statsd.set("web.user.unique", u, tags=["env:dev"])

10秒たったときの集計結果です。

flush (interval=10s)
  web.request.count{env:dev}  RATE   2.5/s  (合計 25)
  web.queue.size{env:dev}  GAUGE  3
  web.request.latency.avg{env:dev}  GAUGE  1.88
  web.request.latency.count{env:dev}  RATE   0.8
  web.request.latency.median{env:dev}  GAUGE  2
  web.request.latency.95percentile{env:dev}  GAUGE  3
  web.request.latency.max{env:dev}  GAUGE  3
  web.user.unique{env:dev}  GAUGE  3  (種類の数)

ヒストグラムの5つの値（avg 1.88・count 0.8・median 2・95percentile 3・max 3）は、公式ドキュメントの例の表と同じになりました。

公式ドキュメントでは、HISTOGRAM は Agent 側で集計し、DISTRIBUTION は生の値を送って Datadog のサーバー側（DDSketch というデータ構造）で集計します。HISTOGRAM はホストごとに Agent が集計するので、ホストAとBの95パーセンタイルを後から合わせても、全体の95パーセンタイルにはなりません。全ホストを通したパーセンタイルが必要なら DISTRIBUTION を使います。その分、後の節のとおりカスタムメトリクスの数は増えます。

APM（トレース）で送られるデータの中身

この節では、APM のトレースが「スパン」の集まりであることと、実際に送られる中身が分かります。

トレースは1つのリクエストの処理全体、スパンはその中の1つの処理（DB への問い合わせ、外部 API の呼び出しなど）です。 スパンは親のスパンの ID を持ち、たどると処理の木になります。

Python のトレーサー ddtrace（pip install ddtrace）で、注文処理の中で DB と決済 API を呼ぶ形を作りました。決済は 502 で失敗した扱いにしています。

import ddtrace.auto  # ログに trace_id などを入れる（logging の連携を有効にする）
import json, logging, time
from ddtrace import tracer

class JsonFormatter(logging.Formatter):
    def format(self, r):
        return json.dumps({
            "timestamp": self.formatTime(r, "%Y-%m-%dT%H:%M:%S%z"),
            "status": r.levelname.lower(),
            "logger.name": r.name,
            "message": r.getMessage(),
            "order_id": getattr(r, "order_id", None),
            "dd.service": getattr(r, "dd.service", ""),
            "dd.env": getattr(r, "dd.env", ""),
            "dd.version": getattr(r, "dd.version", ""),
            "dd.trace_id": getattr(r, "dd.trace_id", ""),
            "dd.span_id": getattr(r, "dd.span_id", ""),
        }, ensure_ascii=False)

h = logging.StreamHandler()
h.setFormatter(JsonFormatter())
log = logging.getLogger("shop")
log.addHandler(h)
log.setLevel(logging.INFO)

@tracer.wrap(name="order.create", resource="POST /orders")
def create_order():
    with tracer.trace("db.query", resource="INSERT INTO orders", span_type="sql"):
        time.sleep(0.03)
    with tracer.trace("http.request", resource="POST /payments") as span:
        time.sleep(0.05)
        span.set_tag("http.status_code", "502")
        span.error = 1
        log.error("payment failed", extra={"order_id": 1001})

create_order()
tracer.flush()

送り先には、Agent の代わりに、届いた HTTP リクエストを表示する擬似サーバーを置きました（msgpack を JSON にして表示します）。

"""Datadog Agent の代わりに HTTP を受けて、届いたリクエストを表示する。"""
import json, sys, msgpack
from http.server import BaseHTTPRequestHandler, HTTPServer

class H(BaseHTTPRequestHandler):
    def log_message(self, *a): pass
    def _reply(self, obj):
        b = json.dumps(obj).encode()
        self.send_response(200); self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(b))); self.end_headers(); self.wfile.write(b)
    def do_GET(self):
        print(f"GET {self.path}", flush=True)
        self._reply({"endpoints": ["/v0.4/traces", "/v0.5/traces"], "client_drop_p0s": False} if self.path == "/info" else {})
    def do_PUT(self): self.do_POST()
    def do_POST(self):
        n = int(self.headers.get("Content-Length", 0)); body = self.rfile.read(n)
        print(f"{self.command} {self.path} ({n} bytes)", flush=True)
        for k, v in self.headers.items():
            if k.lower().startswith(("datadog", "x-datadog", "content-type", "dd-")):
                print(f"  {k}: {v}", flush=True)
        ct = self.headers.get("Content-Type", "")
        try:
            if "msgpack" in ct:
                data = msgpack.unpackb(body, raw=False, strict_map_key=False)
                print("  BODY:", json.dumps(data, ensure_ascii=False, default=str)[:4000], flush=True)
            else:
                print("  BODY:", body[:2000].decode(errors="replace"), flush=True)
        except Exception as e:
            print("  decode error", e, flush=True)
        self._reply({"rate_by_service": {"service:,env:": 1}})

HTTPServer(("127.0.0.1", int(sys.argv[1])), H).serve_forever()

環境変数で送り先と3つのタグを指定して実行しました（DD_TRACE_API_VERSION=v0.4 は、中身を読みやすい形で受けるための指定です。指定しないと v0.5 の形式で送られました）。

DD_TRACE_AGENT_URL=http://127.0.0.1:29001 DD_SERVICE=shop-api DD_ENV=dev DD_VERSION=1.4.2 \
DD_TRACE_API_VERSION=v0.4 python app.py

擬似サーバーに届いたリクエストです（スパンの meta は一部の項目を省略しています）。

GET /info
POST /v0.4/traces (1054 bytes)
  datadog-meta-lang: python
  datadog-meta-lang-version: 3.11.15
  datadog-meta-lang-interpreter: CPython
  datadog-meta-tracer-version: 4.16.0
  datadog-client-computed-top-level: true
  datadog-send-real-http-status: 1
  x-datadog-trace-count: 1
  content-type: application/msgpack

[
  [
    {
      "service": "shop-api",
      "name": "order.create",
      "resource": "POST /orders",
      "trace_id": 9540812836095233591,
      "span_id": 4609399469661350964,
      "start": 1792660496041945861,
      "duration": 89878882,
      "meta": {
        "_dd.p.tid": "6ad9d41000000000",
        "env": "dev",
        "version": "1.4.2",
        "language": "python"
      }
    },
    {
      "service": "shop-api",
      "name": "db.query",
      "resource": "INSERT INTO orders",
      "trace_id": 9540812836095233591,
      "span_id": 8906995682161989639,
      "parent_id": 4609399469661350964,
      "duration": 30170201,
      "type": "sql"
    },
    {
      "service": "shop-api",
      "name": "http.request",
      "resource": "POST /payments",
      "trace_id": 9540812836095233591,
      "span_id": 17384192944225342332,
      "parent_id": 4609399469661350964,
      "duration": 50591841,
      "error": 1,
      "meta": {
        "http.status_code": "502"
      }
    }
  ]
]

duration はナノ秒です。3つのスパンを木にすると次のとおりで、APM の画面ではこれが横棒の図（フレームグラフ）で表示されます。

order.create   POST /orders          89.9 ms
├─ db.query     INSERT INTO orders    30.2 ms
└─ http.request POST /payments        50.6 ms  error=1 (502)

Agent が動いていないと、トレースは送れずに捨てられます。送り先にサーバーがいないときに出た表示です。

failed to send, dropping 1 traces to intake at http://127.0.0.1:29098/v0.5/traces: Network error: client error (Connect)

OpenTelemetry で計装したアプリは、Agent の OTLP の受け口（4317・4318）に送る形でも使えます。OpenTelemetry の計装は、関連記事「OpenTelemetry入門｜Pythonで始めるトレース・メトリクス実装」で扱っています。

ログの送り方（JSON形式とトレースとのひも付け）

この節では、Agent にログを読ませる設定と、トレースとつながるログの形が分かります。

公式ドキュメントによると、ファイルのログを集めるには、datadog.yaml で logs_enabled: true にし、Agent の設定ディレクトリの conf.d/<アプリ名>.d/conf.yaml に読むファイルを書きます。

logs:
  - type: file
    path: "/var/log/shop-api/app.log"
    service: "shop-api"
    source: "python"

Datadog は、ログを JSON で書くことを強く勧めています（スタックトレースが1件のログにまとまるため）。上の APM の節のアプリが出したログは次の1行でした。

{"timestamp": "2026-10-22T18:14:56+0900", "status": "error", "logger.name": "shop", "message": "payment failed", "order_id": 1001, "dd.service": "shop-api", "dd.env": "dev", "dd.version": "1.4.2", "dd.trace_id": "6ad9d410000000008467c6b99bf18e37", "dd.span_id": "17384192944225342332"}

ログの dd.span_id は、決済のスパン（http.request）の span_id と同じ値です。dd.trace_id は32桁の16進数（128ビット）で、トレースの _dd.p.tid（上位）と trace_id を16進数にしたもの（下位）をつなげた値でした。

$ python3 -c "print(hex(9540812836095233591))"
0x8467c6b99bf18e37
_dd.p.tid 6ad9d41000000000 ＋ 8467c6b99bf18e37 ＝ 6ad9d410000000008467c6b99bf18e37

最初に import ddtrace.auto を書かずに動かしたときは、"dd.trace_id": "" と空のままでした。公式ドキュメントは、ddtrace-run で起動するか import ddtrace.auto を書くと logging の連携が有効になると説明しています。

Datadog が特別に扱うログの属性（予約属性）は次のとおりです。

ログに入れる項目の決め方は、関連記事「構造化ログ（JSON）設計｜必須フィールド一覧とPython・Node実装例」で扱っています。

ダッシュボードとモニター（アラート）の作り方

この節では、集めたデータを見る画面と、通知の設定の形が分かります。

ダッシュボード

公式ドキュメントでは、ダッシュボードの形は3つです。グラフ1つ1つを「ウィジェット」と呼び、テンプレート変数で host や service を切り替えて同じダッシュボードを使い回せます。

外部に公開する共有リンクも作れます。公開したダッシュボードは、選んだ時間の範囲にかかわらず30秒ごとに更新されます。

モニター（アラート）

モニターは「この条件を満たしたら通知する」設定です。メトリクスのモニターの検出方法は次の5つです。評価する時間の幅は既定で5分、1分〜730時間（1か月）の範囲で指定できます。

ほかに、ホストの死活（Host）、APM、ログ、Synthetic、SLO、複数のモニターを組み合わせる Composite、Datadog が自動で異常を見つける Watchdog などの種類があります。

API でモニターを作るときに送られるリクエストを、擬似サーバーで受けました（キーは仮の値です）。

from datadog import initialize, api
initialize(api_key="dummy-api-key-0000", app_key="dummy-app-key-0000", api_host="http://127.0.0.1:29001")
api.Monitor.create(
    type="metric alert",
    name="[shop-api] キューが溜まっている",
    query="avg(last_5m):avg:shop.queue.size{env:prod} by {host} > 100",
    message="{{#is_alert}}{{host.name}} のキューが {{value}} 件です（しきい値 {{threshold}}）@slack-shop-alerts{{/is_alert}}\n{{#is_recovery}}回復しました{{/is_recovery}}",
    tags=["service:shop-api", "team:backend"],
    options={"thresholds": {"critical": 100, "warning": 50}, "notify_no_data": True, "no_data_timeframe": 10},
)

POST /api/v1/monitor (586 bytes)
  DD-API-KEY: dummy-api-key-0000
  DD-APPLICATION-KEY: dummy-app-key-0000
  Content-Type: application/json

{
  "type": "metric alert",
  "name": "[shop-api] キューが溜まっている",
  "query": "avg(last_5m):avg:shop.queue.size{env:prod} by {host} > 100",
  "message": "{{#is_alert}}{{host.name}} のキューが {{value}} 件です（しきい値 {{threshold}}）@slack-shop-alerts{{/is_alert}}\n{{#is_recovery}}回復しました{{/is_recovery}}",
  "tags": [
    "service:shop-api",
    "team:backend"
  ],
  "options": {
    "thresholds": {
      "critical": 100,
      "warning": 50
    },
    "notify_no_data": true,
    "no_data_timeframe": 10
  }
}

query は「直近5分の平均（avg(last_5m)）を、env:prod のホストごとに（by {host}）出し、100を超えたら」という意味です。message の中の {{#is_alert}}・{{#is_recovery}} は状態で出し分ける部分、{{value}}・{{threshold}} は値としきい値、@slack-… は通知先です。画面で作ったモニターも、同じ項目を持っています。

何を監視し、しきい値をどう決めるかは、関連記事「監視設計の項目一覧｜死活・リソース・ログ監視のしきい値例とテンプレート」で、SLO の考え方は関連記事「SREとは｜SLI・SLO・SLAの違いとエラーバジェット計算」で扱っています。

Datadogの料金の考え方（無料枠・ホスト・データ量）

この節では、Datadog の料金がどの単位で決まるかと、主な製品の単価が分かります。

Datadog の料金は「製品ごと」に、ホスト数・データ量・件数で決まります。 料金ページの価格です（米ドル、1か月あたり。2026年10月22日時点）。

単価に含まれる枠と、プランの違いです（同じく料金ページ、2026年10月22日時点）。

APM は1 APM ホストあたり、取り込むスパン 150GB と、インデックスするスパン100万件が月の枠に含まれます。RUM・Synthetic Monitoring などは、セッション数やテストの実行回数など、製品ごとに別の単位です。

無料で使う方法は2つです。 Free プランは最大5ホスト・メトリクス保持1日で、料金ページで Free があるのは Infrastructure だけです。試用は14日間で、公式の試用ページには「No credit card required」（クレジットカード不要）とあり、全製品を試せます。

ホスト数は「上位1%を除いた最大値」で数える

公式ドキュメントでは、Datadog は1時間ごとに監視しているホストの数を記録し、月末に上位1%を除いた残りの最大値（high-water mark）で請求します。短い急増で請求が増えないようにするためです。30日（720時間）の月で、その効き方を計算しました。上位1%は720時間のうち約7時間分です。

時間数 720 / 普段10台、20台が6時間、30台が10時間 → 請求の台数 30 台
時間数 720 / 普段10台、20台が6時間、30台が6時間  → 請求の台数 20 台

30台の時間が上位1%に収まると請求は20台分、はみ出すと30台分です。オートスケールでホストが増える構成では、増えている時間の長さが料金に直接効きます。

月額の試算

年契約の単価で、小さめの構成を試算しました。

実際の請求は、契約・割引・枠を超えた分・税で変わります。正確な金額は、14日間の試用で自分の環境のホスト数・ログ量・カスタムメトリクス数を測り、営業に見積もりを取るのが確実です。

料金が膨らみやすい3つのポイント（カスタムメトリクス・ログ・ホスト）

この節では、Datadog の料金が想定より増えるよくある原因と、その確かめ方が分かります。

カスタムメトリクスは「名前×タグの値の組み合わせ」で数える

公式ドキュメントでは、カスタムメトリクスは「メトリクス名・ホスト・タグの値の、重複しない組み合わせ」1つにつき1個と数えます。送った回数ではありません。同じ回数を送り、タグだけを変えて、組み合わせの数を数えました。

eps = ["/orders", "/items", "/cart"]
for i in range(3000):
    ep = random.choice(eps); st = random.choice(["200", "500"])
    statsd.increment("api.req", tags=[f"endpoint:{ep}", f"status:{st}"])            # よい例
    statsd.increment("api.req_by_user", tags=[f"endpoint:{ep}", f"user_id:{random.randint(1, 1000)}"])  # 悪い例

api.req: 送った回数 2272 / タグの組み合わせ（カスタムメトリクス数） 6
api.req_by_user: 送った回数 2276 / タグの組み合わせ（カスタムメトリクス数） 1584

（送った回数が3,000より少ないのは、上の節の UDP の取りこぼしです。）ほぼ同じ回数でも、user_id のように値の種類が多いタグを付けると、6個が1,584個になりました。 Pro 10ホストの枠は合計1,000個（100個×10）なので、このメトリクス1つで枠を超えます。DISTRIBUTION は組み合わせ1つにつき5個、パーセンタイルを有効にするとさらに2倍（10個）と数えます。

• 1タグに ID を入れていないかuser_id・order_id・request_id などはログやトレースに入れ、メトリクスのタグにはしない
• 2DISTRIBUTION が要るか全ホストを通したパーセンタイルが要らなければ HISTOGRAM や GAUGE で数を抑えられる
• 3ログを全部インデックスしていないか取り込み（GB）とインデックス（件数）は別に課金される。検索しないログまで保持していないか
• 4ホストが増えている時間は長くないか上位1%を超えて増えた台数は、その月の請求に入る
• 5APM を全ホストに入れていないかトレースを送ったホストが APM ホストとして数えられる

Zabbix・Prometheus＋Grafana・CloudWatch・New Relicとの違い

この節では、よく比べられる監視ツールとの違いを、事実で比べられます。

各製品の公式の説明から、違いが出やすい点を挙げます。

• Prometheus：公式の概要では、メトリクス名と キー=値 の組で時系列を表し、PromQL で問い合わせ、収集は HTTP の pull 型、データは各サーバーのローカルに保存します。可視化には Grafana などを使います。「リクエストごとの課金のように100%の正確さが要る用途には向かない」とも書かれています。
• Zabbix：2026年10月22日時点の最新版は 7.4 です。サーバー・エージェント・プロキシなどの部品を自分で動かします。
• CloudWatch：無料枠に、カスタムメトリクスと詳細モニタリングのメトリクス合わせて10個、アラーム10個、ログ5GB などが含まれます。ログの取り込みは米国東部の Standard で 0.50ドル/GB です。
• New Relic：無料枠は月100GB のデータの取り込みとフルプラットフォームユーザー1人です。

Zabbix の構成・インストール・通信の中身は関連記事「Zabbixとは｜構成・用語・インストールと使い方を実例で解説」で、Prometheus と Grafana で監視を組む手順は関連記事「Prometheus Grafana入門｜監視構築とPromQL一覧」で扱っています。

CloudWatchと併用するとき

Datadog の AWS 連携は CloudWatch のデータを取り込む形なので、多くの場合は併用になります。公式の FAQ によると、次の点が変わります。

CloudWatch だけでアラームを作る方法は、関連記事「CloudWatchアラームをAWS CLIで作成｜SNS通知・カスタム指標」で扱っています。

Datadogの導入の流れ（サイト選び→Agent→連携→モニター）

この節では、アカウントを作ってから通知が届くまでの順番が分かります。

Datadogのよくあるエラーとつまずき

この節では、データが画面に出ないときなどの原因と直し方を引けます。エラー文は、この記事で実際に出たもの、または Agent 7.84.5 のソースにある文言です。

Agent の site は、設定例で既定値が datadoghq.com（US1）です。AP1 や EU1 のアカウントで site を書き忘れると、キーが通らずデータも画面に出ません。

Datadogが合う・合わないの判断表

この節では、状況ごとに Datadog を選ぶかどうかの目安が分かります。

よくある質問

Q. Datadogの読み方は？ A. 「データドッグ」です。公式の表記は英字の Datadog です。

Q. Datadogとは何ですか？何ができますか？ A. サーバー・コンテナ・クラウド・アプリ・ログのデータを集め、1つの画面で見て、異常を通知する SaaS です。インフラ監視・APM・ログ管理・RUM・外形監視などが製品として分かれています。「Datadogでできること（製品の早見表）」の節にまとめています。

Q. Datadogはどこの国の会社ですか？ A. 米国ニューヨークに本社がある Datadog, Inc. で、Nasdaq に DDOG で上場しています。日本には2019年11月に設立された日本法人があり、データの保存先として日本のサイト AP1 を選べます。

Q. Datadogは無料で使えますか？ A. Free プランは最大5ホスト・メトリクス保持1日で、インフラ監視だけです（2026年10月22日時点）。APM・ログを含めて試すなら、クレジットカード不要の14日間の試用があります。

Q. Datadogの料金はいくらですか？ A. 製品ごとに単位が違います。年契約で Infrastructure Pro が1ホスト月15ドル、APM が1ホスト月31ドル、ログは取り込み1GB 0.10ドルとインデックス100万件 1.70ドル（15日保持）です（2026年10月22日時点）。試算は「月額の試算」にあります。

Q. Datadog Agentとは何ですか？ A. 監視するホストで動き、標準のメトリクスを15秒ごとに集め、アプリから DogStatsD（8125/UDP）やトレース（8126/TCP）を受けて、HTTPS で Datadog に送るソフトです。2026年10月22日時点の最新は 7.84.5 です。

Q. DatadogとCloudWatchの違いは？併用できますか？ A. CloudWatch は AWS のサービスで、AWS の中の監視に向いています。Datadog は AWS 以外も含めてまとめて見る SaaS で、AWS のデータは CloudWatch から取り込むので併用になります。取り込みは10分ごとで、Metric Streams を使うと2〜3分になります。

Q. DatadogとPrometheus・Zabbixの違いは？ A. Prometheus と Zabbix はオープンソースで、自分でサーバーを動かして運用します。Datadog は SaaS で、保存・画面・通知の基盤を Datadog 側が持ちます。比べた表は「Zabbix・Prometheus＋Grafana・CloudWatch・New Relicとの違い」の節にあります。

Q. DatadogはOpenTelemetryと一緒に使えますか？ A. 使えます。Agent は OTLP の受け口（gRPC 4317・HTTP 4318）を持ち、有効にすると OpenTelemetry で計装したアプリのデータを受けられます。

Q. Datadogの料金を抑えるには？ A. メトリクスのタグに ID を入れない、検索しないログをインデックスしない、APM を入れるホストを決める、ホストが増える時間を短くする、の4点が効きます。「料金が膨らみやすい3つのポイント」の節のチェックリストで確かめられます。

Q. Datadogの資格（認定試験）はありますか？ A. あります。Datadog Fundamentals、APM and Distributed Tracing Fundamentals、Log Management Fundamentals などの認定試験があり、公式ページでは各試験は多肢選択式90問、受験料100米ドルです。Datadog Fundamentals と APM and Distributed Tracing Fundamentals は日本語でも受けられます（2026年10月22日時点）。

Q. Datadogは何から始めればいいですか？ A. サイト（日本なら AP1 も選べる）を選んでアカウントを作り、1台に Agent を入れ、クラウドと連携し、タグを揃えてからモニターを作る順です。「Datadogの導入の流れ」の節に手順があります。

まとめ

• Datadog は、メトリクス・ログ・トレースを集めて1つの画面で見て、モニターで通知する SaaS。読み方は「データドッグ」。
• データはホストの Agent（7.84.5）が集めて HTTPS で送る。アプリのメトリクスは DogStatsD（8125/UDP）、トレースは 8126/TCP で Agent が受ける。
• DogStatsD は 名前:値|種類|#タグ の1行。UDP なので届かなくてもエラーにならず、バッファを使うとまとめて送れる。
• env・service・version を揃えると、メトリクス・トレース・ログを行き来できる。ログの dd.trace_id でトレースとつながる。
• 料金は製品ごと。Infrastructure Pro は1ホスト月15ドル（年契約）、ホスト数は上位1%を除いた最大値、カスタムメトリクスはタグの値の組み合わせで数える（2026年10月22日時点）。
• Zabbix・Prometheus は自分で運用するオープンソース、CloudWatch は AWS のサービス、New Relic はデータ量とユーザー数の SaaS。

参考・出典

確認日はいずれも 2026年10月22日です。

• Datadog「Pricing」：https://www.datadoghq.com/pricing/
• Datadog「Free Datadog Trial」：https://www.datadoghq.com/free-datadog-trial/
• Datadog Docs「Billing / Pricing」：https://docs.datadoghq.com/account_management/billing/pricing/
• Datadog Docs「Custom Metrics Billing」：https://docs.datadoghq.com/account_management/billing/custom_metrics/
• Datadog Docs「Getting Started with Datadog Sites」：https://docs.datadoghq.com/getting_started/site/
• Datadog Docs「Agent」：https://docs.datadoghq.com/agent/
• Datadog Docs「Agent Architecture」：https://docs.datadoghq.com/agent/architecture/
• Datadog Docs「Linux（Agent）」：https://docs.datadoghq.com/agent/supported_platforms/linux/
• Datadog Agent のリリース（GitHub）：https://github.com/DataDog/datadog-agent/releases
• Datadog Agent の設定例（Linux、GitHub）：https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example
• Datadog Docs「Datagram Format and Shell Usage」（DogStatsD）：https://docs.datadoghq.com/developers/dogstatsd/datagram_shell/
• Datadog Docs「High Throughput Data Submission with DogStatsD」：https://docs.datadoghq.com/developers/dogstatsd/high_throughput/
• Datadog Docs「Metric Types」：https://docs.datadoghq.com/metrics/types/
• Datadog Docs「Metric Submission: DogStatsD」：https://docs.datadoghq.com/metrics/custom_metrics/dogstatsd_metrics_submission/
• Datadog Docs「Distributions」：https://docs.datadoghq.com/metrics/distributions/
• Datadog Docs「Unified Service Tagging」：https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging/
• Datadog Docs「Host Agent Log collection」：https://docs.datadoghq.com/agent/logs/
• Datadog Docs「Python Log Collection」：https://docs.datadoghq.com/logs/log_collection/python/
• Datadog Docs「Correlating Python Logs and Traces」：https://docs.datadoghq.com/tracing/other_telemetry/connect_logs_and_traces/python/
• Datadog Docs「Attributes and Aliasing」：https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/
• Datadog Docs「Dashboards」：https://docs.datadoghq.com/dashboards/
• Datadog Docs「Monitor Types」：https://docs.datadoghq.com/monitors/types/
• Datadog Docs「Metric Monitor」：https://docs.datadoghq.com/monitors/types/metric/
• Datadog Docs「Variables（モニターの通知）」：https://docs.datadoghq.com/monitors/notify/variables/
• Datadog Docs「AWS Integration and CloudWatch FAQ」：https://docs.datadoghq.com/integrations/guide/aws-integration-and-cloudwatch-faq/
• Datadog Docs（日本語版）トップ：https://docs.datadoghq.com/ja/
• Datadog「認定プログラム」：https://www.datadoghq.com/ja/certification/overview/
• Datadog「Leadership」：https://www.datadoghq.com/about/leadership/
• Terraform Provider for Datadog「datadog_monitor」（モニターの query の例）：https://github.com/DataDog/terraform-provider-datadog/blob/master/docs/resources/monitor.md
• Wikipedia「Datadog」（英語版。創業・上場・日本法人）：https://en.wikipedia.org/wiki/Datadog
• Prometheus「Overview」：https://prometheus.io/docs/introduction/overview/
• Zabbix「License」：https://www.zabbix.com/license
• Zabbix Documentation「What is Zabbix」（7.4）：https://www.zabbix.com/documentation/current/en/manual/introduction/about
• Amazon CloudWatch「料金」：https://aws.amazon.com/cloudwatch/pricing/
• New Relic「Pricing」：https://newrelic.com/pricing

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。