Datadog と Cloud Monitoring の比較 - GCP 監視の境目
Google Cloud だけで動くシステムに Datadog を足す意味はあるのか。Cloud Logging / Monitoring / Trace の取り込み量課金と Datadog のホスト課金を単位から並べ、同じ GKE 構成で費目がどう決まるかを式で見て、1 プロジェクト完結か横断かで境目を引きます。具体的な単価は各社の公式料金ページを参照する構成です。
結論 - 1 プロジェクト完結なら Cloud Monitoring、横断なら Datadog
先に結論を条件文で書きます。監視対象が Google Cloud の 1 プロジェクトに収まり、見る人も 1 チームで、ログ検索が主用途なら、Cloud Monitoring と Cloud Logging で足ります。逆に、プロジェクトが複数ある、GKE のコンテナをサービス単位で追いたい、AWS やオンプレミスと同じ画面で見たい、のどれかに当たるなら Datadog を足す価値が出ます。理由は設計単位の差です。Google Cloud の観測系はプロジェクトと請求先アカウントを単位に無料枠と課金が決まり、Datadog はホストと SKU を単位に課金が決まります (2026 年 9 月時点・出典: Google Cloud Observability の料金)。CloudWatch との比較や Azure Monitor との比較と違う GCP 固有の論点は、この「プロジェクト」という箱です。
GCP の観測は 3 製品とプロジェクトの単位でできている
Google Cloud のドキュメントは、オブザーバビリティの製品群として Cloud Logging / Cloud Monitoring / Cloud Trace にエラーレポートと Cloud Profiler を並べ、Cloud Monitoring を「指標データを収集し、アプリケーションとサービスのパフォーマンスをモニタリングして可視化できるツール」と説明しています (2026 年 9 月時点・出典: Cloud Monitoring のドキュメント)。Compute Engine の VM には Ops エージェントを配り、オンプレミスやハイブリッド環境は BindPlane で集める構成が同ページの案内です。複数プロジェクトの指標を 1 か所で見るには「指標スコープ」の構成が別に要り、ここが「プロジェクトの箱」を意識させる最初の場所です。ログ検索と指標の可視化は追加契約なしで始まる一方、箱をまたぐ設計は自分で組む、というのが GCP 標準の性格です。
課金の単位はどこが違うか
課金の単位は、Google Cloud が取り込んだ量、Datadog が対象の数です。Google Cloud の料金ページ (2026 年 9 月時点) では、Cloud Logging は取り込み GiB あたりの単価で、30 日分の保存と検索が単価に含まれ、プロジェクトごとに月次の無料枠があります。Cloud Monitoring は標準メトリクスが非課金で、他は取り込み MiB あたりの単価、Cloud Trace はスパン数 (100 万件単位) の単価です。Datadog は 2026 年 8 月時点でインフラ監視 Pro がホストあたりの月額 (年契約)、ログは取り込み GB あたりの単価と、保持日数別のインデックス済みイベント数 (100 万件単位) の単価の 2 軸です。
| 層 | Google Cloud | Datadog |
|---|---|---|
| ホスト / メトリクス | GCP 標準メトリクスは非課金。他は取り込み MiB 単位 (請求先アカウントごとに月次の無料枠) | インフラ監視 Pro のホスト月額 (ホストあたりコンテナ 5 台分の割当込み) |
| ログ | 取り込み GiB 単位 (30 日保存込み・プロジェクトごとに月次の無料枠) | 取り込み GB 単位 + インデックス済みイベント数単位 (保持日数別) |
| トレース | スパン数単位 (月次の無料枠あり) | APM のホスト月額 + 取り込み割当 (超過は GB 単位) |
| 外形監視 | 稼働時間チェックの実行回数単位 (プロジェクトごとに月次の無料枠) | 実行回数課金 (Synthetics の解説を参照) |
| 監視 API の読み取り | 返却された時系列の件数単位 (請求先アカウントごとに月次の無料枠) | 該当なし (Datadog 側の課金項目には無い) |
単位が違うので、安さは「量か台数か」で決まります。ログの量が多くホストが少ない構成では取り込み量課金が重くなり、ホストが多くログが少ない構成ではホスト課金が重くなる、という単純な対応です。SKU の積み上がり方は料金体系の読み解き方に委ねます。本記事は課金の仕組みを解説するものです。具体的な単価や料金は各社の料金ページで確認してください。
Datadog は GCP をどこから見て、GCP 側に何を払うのか
Datadog の Google Cloud インテグレーションは、サービスアカウント経由で Cloud Monitoring API のメトリクスを読みます。公式は組織またはフォルダー単位の自動検出を推奨し、後から作るプロジェクトも範囲に入ります (2026 年 9 月時点・出典: Google Cloud Platform)。見落としやすいのが GCP 側の費用で、この読み取りは Monitoring API の読み取り課金 (返却された時系列の件数で数え、請求先アカウントごとに月次の無料枠がある) の対象です (同時点・出典: 同料金ページ)。既定ではこの費用とクォータがサービスアカウントの属するプロジェクトに集まり、プロジェクト別の帰属に切り替えるには Datadog サポートでの有効化とロールの追加が要ります。ログは Pub/Sub と Dataflow のテンプレートで転送します (同時点・出典: Google Cloud Log Forwarding Setup)。
同じ GKE 構成で費目を並べると - 損得を分ける変数
式にするため、GKE ノード N 台、コンテナ 100 個、ログを毎日一定量 (月に L GiB) 取り込む構成を仮定します。メトリクスは GCP 標準のもののみと仮定します。Google Cloud 側はメトリクスが非課金なので、月額は「(L − プロジェクトの月次無料枠) × Cloud Logging の取り込み単価」だけで決まり、ノード数 N は式に現れません。Datadog 側は「N × インフラ監視 Pro の単価 + L × ログ取り込み単価 + インデックス済みイベント数 × インデックス単価」で、インデックス件数は GB からは出ないため、取り込んだログのどれだけをインデックスするかを設計で決めることになります。
| 費目 | Google Cloud | Datadog |
|---|---|---|
| ノード N 台の監視 | 標準メトリクスのみなら非課金 | N × インフラ監視 Pro のホスト単価 (コンテナ割当を超えた分は別) |
| ログ取り込み | (L − 無料枠) × 取り込み単価・30 日の保存と検索込み | L × 取り込み単価 (保存と検索は含まない) |
| ログの保存 / 検索 | 上に含む | インデックス済みイベント数 × 保持日数別の単価。除外して取り込みのみなら 0 |
| 合計の性格 | ログ量に比例し、ノード数に無関係 | ノード数に比例する固定部 + インデックス率で大きく動く変動部 |
ログ主体で 1 プロジェクトなら Google Cloud 標準の方が低くなりやすい、というのがこの表の素直な読みで、ノード数が少なくログ量が多いほどその傾きは強まります。Datadog の合計が下限 (取り込みのみ) と上限 (全件インデックス) の間で大きく開くのは、インデックスする割合を設計で決められるからで、ログ管理の除外設定が費用の主役になります。逆にノード数が多くログが少ない構成では、Google Cloud 側の式に現れないノード数が Datadog 側の固定部として立ち上がる一方、ログの取り込み量課金の重さは薄れます。Datadog を選ぶなら、両式の差を「横断の画面とコンテナ粒度で回収できるか」に置き換えて判断します。答えを出すには、自分の N と L、そして各社の料金ページの単価を式に入れるだけで足ります。
Cloud Monitoring が勝る点
追加の契約も接続設定も要らないことが、最初の強みです。Google Cloud 標準のメトリクスは非課金で、Cloud Logging はプロジェクトごとに月次の無料枠があり、取り込んだログは 30 日分の保存と検索が単価に含まれ、検索と分析に追加料金はかからないと料金ページに明記されています (2026 年 9 月時点・出典: Google Cloud Observability の料金)。Cloud Trace と稼働時間チェックにも月次の無料枠があり、小さなシステムなら請求ゼロで観測を始められます。二つ目は費用の予見性で、ホスト台数を数えずに取り込んだ GiB とスパン数だけで月額が読めます。三つ目は箱と権限の一致で、プロジェクト単位の観測はそのプロジェクトの利用者に閉じ、外部にサービスアカウントの権限を渡す判断が発生しません。1 プロジェクトの小規模なら、この仕事を増やさない選択は合理的です。
Datadog が活きる 3 場面と二重取り込みの避け方
逆に Datadog の設計単位が効くのは、プロジェクトという箱をまたぐときです。
- 1. 組織横断 - 組織やフォルダー単位の自動検出で、後から増えるプロジェクトも同じ画面と同じタグで並ぶ
- 2. GKE のコンテナ粒度 - ノードに置いた Agent がコンテナとサービス単位の指標とトレースを取り、コンテナ監視の画面で追える
- 3. GCP 外との相関 - AWS やオンプレミスのホストと GCP のリソースを、1 つのダッシュボードと 1 つのアラート設計で扱える
3 場面のどれかに当たるなら、次は二重に取り込まない設計です。インテグレーションには収集するサービスを名前空間で選び、包含 / 除外のフィルターを書く設定があり、公式はこれを「Cloud Monitoring API の費用を最適化する」設定と説明し、例に *_cost と *_count の除外を挙げています (2026 年 9 月時点・出典: Google Cloud Platform)。リージョンの除外や、datadog:true のラベルを付けたホストだけ取り込むフィルターも同じ画面にあります。GKE ノードに Agent を置けば粒度の細かい低遅延の指標は Agent 側で取れるため、API 経由の収集は Agent が届かないマネージドサービスに絞る分担にすると、GCP 側の読み取り課金と Datadog 側のホスト数の両方が締まります。