インテグレーション

インテグレーションは「入口の束」- 有効にすると何が流れ込むか

Datadog インテグレーションとは、外部システムのデータを Datadog に取り込むための接続部品の総称です。公式ドキュメントは 2026 年 9 月時点でこれを 3 つの主要な型に分けています。Datadog Agent と一緒にインストールされ Python の check メソッドで収集項目を定義する「Agent ベース型」、Datadog 側に認証情報を登録して API でデータを取りに行く「認証 (クローラー) 型」、Node.js や Python などアプリの言語ごとに組み込む「ライブラリ型」の 3 つです (出典: Introduction to Integrations)。AWS / Azure / Slack / PagerDuty の連携は 2 つ目の型に属します。有効にすると、対象のメトリクスに加えてログ / イベント / タグが同じ画面に流れ込み、対象ごとの標準ダッシュボードが初日から使えます。数は料金ページの Pro プラン説明に「1,000+ integrations」と記載があります (2026 年 9 月時点・出典: Datadog Pricing)。この仕組みが無いと、監視対象が 1 つ増えるごとに収集スクリプトと専用画面を自作することになります。あると「対象の名前を選んで認証情報を渡す」だけで、収集と可視化の土台が揃った状態から運用を始められます。

Agent 側の統合とクラウドアカウント側の統合は別物

同じ「インテグレーション」の名で呼ばれますが、Agent 側の統合とクラウドアカウント側の統合は動く場所も取れるものも違います。Agent 側は、Agent の設定ディレクトリ直下にある conf.d フォルダの <統合名>.d/conf.yaml (同梱の conf.yaml.example を改名して使う) に接続先を書くと、その Agent が対象を定期的に見に行く型です (2026 年 9 月時点・出典: Introduction to Integrations)。クラウドアカウント側は、AWS の IAM ロールや Azure の App Registration の認証情報を Datadog に渡し、Datadog 側からクラウドの API を叩いてもらう型です。

取れる細かさも違います。公式ガイドは、クラウド事業者側の監視はホストを外側から 5〜25 分間隔でサンプリングするのに対し、Agent を入れると既定で 50 を超えるメトリクスが取れ、Agent レベルで付けたタグが全てのメトリクス / ログ / トレースに載ると説明しています (2026 年 9 月時点・出典: Why should I install the Datadog Agent on my cloud instances?)。エージェントレス連携との使い分けの詳細は Agent の解説に譲ります。ここでは「同じ EC2 でも、Agent 側で見える中身とクラウド側で見える外形は別のデータ」という点だけ押さえてください。

AWS 連携で最初に決めるのはロール、収集対象、リージョンの 3 点

AWS 連携は認証 (クローラー) 型の代表で、2026 年 9 月時点の公式ドキュメントでは CloudWatch を通じて 90 を超える AWS サービスのメトリクス / イベント / ログを集めると説明されています。セットアップ方法は CloudFormation (手早く始めるときの推奨) と Terraform による自動構成、そして手動のロール委任の 3 通りが用意されています (出典: Amazon Web Services)。どの方法でも、最初に決めるのは次の 3 点です。

メトリクスの取得方式には API ポーリング (平均 10 分ごとに新しいメトリクスを取得) と CloudWatch Metric Streams (遅延 2〜3 分 / 別途セットアップが必要) の 2 つがあり、ログの送り方にも Amazon Data Firehose の Datadog 宛先と Forwarder Lambda 関数の 2 経路があります (同出典)。ポーリングとストリームのどちらを選ぶかは CloudWatch 側の費用と鮮度の交換条件になるので、詳しくは CloudWatch との使い分けに譲ります。Azure と Google Cloud も構図は同じで、Azure は監視したいサブスクリプションへのアクセス権を持つ App Registration の認証情報を Datadog に登録する形、Google Cloud はサービスアカウントを作って Datadog 側のプリンシパルに権限借用を許す形です。Google Cloud はメトリクスがセットアップ後 約 15 分で表示されると明記されています (2026 年 9 月時点・出典: Azure / Google Cloud Platform)。

入れると課金はどう変わるか - 連携で拾われたホストの数え方

AWS 連携を有効にした瞬間に変わるのが、ホストの数え方です。公式の課金ドキュメントは 2026 年 9 月時点で、Datadog は「Agent が動いている AWS ホスト」と「AWS 連携が検出した全ての EC2 インスタンス」に課金し、両方に該当するホストが二重に数えられることはない、と説明しています。二重計上の判定には EC2 のインスタンスメタデータが使われるため、IMDSv2 を必須にしているインスタンスでは Agent 7.64.0 以上で設定項目 ec2_prefer_imdsv2 を true にする必要があります (出典: AWS Integration Billing)。驚かれるのは「Agent を入れていない検証用 EC2 も、連携が拾えば 1 ホスト」という点です。インフラ監視 Pro のホスト単価は 2026 年 8 月時点で月 15 ドル (年契約・出典: Datadog Pricing) なので、放置された EC2 が 10 台あれば月 150 ドルが誰も見ない画面のために積まれます。

つまり「マネージドサービスの統合をたくさん有効にしたから請求が跳ねる」という心配は筋が違い、見るべきは EC2 の台数です。防ぎ方も用意されていて、統合ページの Metric Collection タブでタグ条件による収集対象の限定ができます。公式の例は datadog:no タグを持つ EC2 を除外する書き方で、既存アカウントに制限を追加した場合は検出済みのインスタンスが最大 2 時間ほど一覧に残ることも記されています (同出典)。費用はもう 1 枚あり、API ポーリングはサブ統合ごとに 10 分おきに CloudWatch API を呼ぶため、リソースの多いアカウントでは AWS 側の CloudWatch 請求に影響し得ると FAQ が注意しています (2026 年 9 月時点・出典: AWS Integration and CloudWatch FAQ)。料金体系の全体像は料金の読み解きで扱っています。本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。

なぜタグが揃う効果は「見える化」より先に効くのか

インテグレーションの効き目として最初に語られるのは標準ダッシュボードですが、実務で先に効くのはタグの方です。AWS 連携は EC2 ホストにインスタンスタイプやアベイラビリティゾーンといった EC2 固有の情報をタグとして付け、Agent 側で付けたタグはその Agent が送る全てのメトリクス / ログ / トレースに載ります (2026 年 9 月時点・出典: Amazon Web Services / Why should I install the Datadog Agent on my cloud instances?)。この 2 系統のタグが同じホストで合流すると、「本番環境の c5 系インスタンスだけの CPU」「決済サービスが載るホストの RDS 接続数」のように、クラウド側の属性とアプリ側の属性を掛け合わせた絞り込みが 1 行のクエリで書けるようになります。これが無いと、ホスト名の一覧を Excel で突き合わせて「このホストは何のサービスだったか」を人が思い出す作業が障害のたびに発生します。注意点は表記の正規化で、Datadog に取り込まれる際に大文字は小文字に、空白はアンダースコアに変換されます。公式は AWS 側の Team:Frontend App というタグが Datadog 側では team:frontend_app になる例を挙げています (2026 年 9 月時点・出典: AWS Integration Billing)。AWS 側のタグ規約を大文字混じりで運用している組織は、連携を入れる前に Datadog 側の見え方を決めておくと、後からダッシュボードとモニターを全部書き直す事態を避けられます。タグ設計そのものの考え方はタグ付けの解説にまとめています。

切り分けの順序から逆算すると、導入順は Agent、クラウド統合、SaaS 統合

公式ドキュメントは導入順を指定していませんが、障害の切り分けの順序から逆算すると、入れる順番には合理的な型があります。オンプレや EC2 で動く自社アプリと、RDS や ELB などのマネージドサービスが混在し、通知先は Slack という構成を例に取ります。この構成では、まず Agent 側の統合 (OS / ミドルウェア / ログ)、次にクラウドアカウント側の統合 (AWS / Azure / Google Cloud)、最後に Slack や PagerDuty などの SaaS 統合、という順を勧めます。

理由は 3 つあります。第一に、調査は自分のコードとホストから始まるので、粒度の細かい Agent 側のデータが最初に必要になること。第二に、クラウド統合を先に入れると連携が拾った EC2 が全て課金対象になる一方、まだ中身が見えないため「払っているのに調べられない」期間が生まれること。第三に、通知は見えるものが揃ってから接続した方が、最初の 1 週間に飛ぶ誤検知の量を抑えられることです。ただし例外もあり、Lambda 中心のサーバーレス構成では Agent を入れる場所が無いため、クラウド統合から始めるのが自然です。自分の構成でどこから調査が始まるかを先に言葉にすると、順序は自然に決まります。

導入前チェック 5 項目

統合を有効にする前に、組織として決めておくと後戻りが少ない項目を 5 つに絞ります。どれも後から直せますが、直すときは既に流れ込んだデータとの不整合が付いてきます。

この 5 項目のうち請求に直結するのは 2 と 3 で、どちらも AWS 統合ページの Metric Collection タブが設定場所です (2026 年 9 月時点・出典: AWS Integration Billing)。連携を有効にしたあと最初に開く画面はダッシュボードではなく、このタブとインフラ監視のホスト一覧です。ホスト一覧では AWS のロゴだけが付いたホストは連携経由のみで監視されているホスト、Agent のロゴが付いたホストは Agent で監視されているホストと見分けられるので (同出典)、「Agent を入れるつもりだったのに連携だけで数えられている」ホストをここで洗い出せます。取り込んだあとの見え方はインフラ監視の解説、ログの流量設計はログ管理の解説へ続きます。