Datadog API は、監視 SaaS である Datadog をコードから操作するためのものだ。ダッシュボードやアラートを画面でポチポチ作るのではなく、設定そのものをコード管理（IaC）に乗せたいチームにとって中心的なツールになる。
API で何が変わるか
監視設定を Terraform などで宣言的に管理できると、環境ごとの設定差異がなくなり、レビュー対象としてダッシュボードやモニターを扱える。新しいサービスをデプロイするときに監視も同時に湧いて出る、という運用が組める。これが手動運用との実質的な差だ。
カスタムメトリクスの送信機能を使えば、インフラ指標だけでなく「1 時間あたりの注文数」のようなビジネス KPI を同じ画面に並べられる。障害対応とビジネス影響を 1 つのダッシュボードで見られるのは実務で効く。
カスタムメトリクスのコスト爆発に注意
カスタムメトリクスは、タグの組み合わせ 1 つ 1 つが課金対象（メトリクスのカーディナリティ）になる。ユーザー ID やリクエスト ID のように値の種類が多いタグを安易に付けると、メトリクス数が指数的に膨らみ、請求額が想定の何倍にも跳ねる。タグ設計はコスト設計と直結している、という意識が要る。
料金は構造を理解してから
Datadog の料金は「ホスト数ベースの月額」が基本だが、インフラ監視・APM・ログ管理がそれぞれ別モジュールの個別料金になっている。気づかないうちに複数モジュールが積み上がり、想定より高くつく事例が多い。
無料枠はホスト 5 台・メトリクス保持 1 日と限定的で、本格利用は有料前提。個人や小規模なログ収集が目的なら Grafana Cloud など軽量な選択肢の方がコスト構造が合う。
コストがデータ量で決まる構造
Datadog の課金は、監視対象のホスト数だけでなく、送信するカスタムメトリクスの数やログの量にも連動する。「とりあえず全部送る」構成にすると、監視コストがインフラコストを上回る事態が起きうる。何を常時記録し、何をサンプリングし、何を送らないかを設計する必要がある。メトリクスのタグを高カーディナリティ（ユーザー ID など値の種類が膨大な項目）にすると、意図せず爆発的にコストが増える点はとくに注意が要る。
メトリクスのタグは値の組み合わせごとに別系列として課金されます。一意な値をタグにすると系列数が青天井に増え、請求が想定の桁を超えます。個別の識別子はログやトレース側で扱い、メトリクスのタグは値の種類が限られるものに限定してください。
API を使う場面
ダッシュボードやモニターの定義を API 経由でコード管理すると、環境ごとの監視設定を再現可能にできる。手作業で画面から設定した監視は、担当者が変わると誰も内容を把握していない状態になりがちだ。監視設定をリポジトリで管理し、変更をレビュー対象にする運用に移すために API を使う、というのが実務での主要な用途になる。