Datadogログ収集の3経路とパイプライン設計：インデックス制御で保管費を抑える実装手順

Datadogでログを扱うとき詰まるのは、画面の見た目ではなく手前の3か所です。どの経路で届けるか、どの属性に寄せるか、インデックスに何割を入れるか。この3点を決めずに全ログを流し込むと、翌月は取り込み費よりインデックス費が上回る。この記事では、Agentのファイル収集とコンテナ収集、AWSのForwarder LambdaとCloudWatch連携の選び分け、log_processing_rulesによる送信前フィルタ、パイプラインでの標準属性化、除外フィルタの評価順を、公式ドキュメントの設定名と2026年8月時点の公表価格に沿って整理します。

まとめ：Datadogログ管理で先に決める収集経路とインデックス方針

決めるべきは3点です。第一に収集経路。ホストとコンテナはDatadog Agent、AWSのマネージドサービスはForwarder Lambdaかクラウド連携、独自プロセスはHTTPインテークに寄せる。TCP送信は配送と信頼性を保証しないと公式ドキュメントが明記しており、欠損が許されないログには選びません。

第二に、送信前に落とす量。Agent側の log_processing_rules に exclude_at_match を書けば、ヘルスチェックのアクセスログはDatadogへ到達する前に消えます。取り込み課金は年間契約で1GBあたり0.10ドル（2026年8月時点の公表価格）で、送信前に削れば取り込み費とインデックス費が同時に下がる。

第三に、インデックスへ入れる割合。15日保持のインデックスは100万イベントあたり1.70ドル（年間契約）で、取り込みの17倍の単価です。インデックスフィルタも除外フィルタも「最初に一致した1本」で確定するため、この評価順を知らずにルールを積むと後ろの設定は黙って無視される。

Agentのファイル収集とコンテナ収集で分かれるdatadog.yamlの設定範囲

ホストとコンテナでは、同じAgentでも設定を書く場所が違います。ホストはメイン設定ファイルと各インテグレーションの設定、コンテナは環境変数とアノテーションが主戦場になる。Agentを置けない環境向けのHTTPインテークは、ペイロード1MB・単一ログ25KB推奨・タグ100個が上限です。インストール方式はDatadog Agent導入の3方式とdatadog.yamlの設定で扱うため、ここはログ固有の設定に絞ります。

logs_enabledを有効化してからログが届くまでの確認手順4段階

Agentは既定でログを送りません。datadog.yaml の logs_enabled を true に変更するのが起点で、ここを触らずインテグレーション側だけ設定して止まる例が多い。

1. logs_enabled を true にしてAgentを再起動する
2. Agentのステータス出力で Logs Agent セクションが出るか確認する
3. 対象ファイルにAgent実行ユーザーの読み取り権限があるか確認する
4. Live Tail画面で source を指定して到達を確認する

権限で落ちるケースは症状が分かりにくく、Agent側のエラーだけでは気付けません。ステータス出力にファイルパスが出ているのに件数が0なら、まず権限を疑う。

service・sourceの決め方とcontainerCollectAllの扱い

source は単なるラベルではありません。Datadogはこの値でインテグレーション既定のパイプラインを自動適用するため、nginxのログに nginx を指定すればステータスコードやレスポンスタイムのパースが最初から効きます。独自の文字列を入れると既定が当たらず、自作のGrokパーサを書く羽目になる。service はAPMと突き合わせる軸なので、APM側のサービス名と完全に一致させます。命名規約はDatadog運用のベストプラクティスで整理したタグ設計と絞り込みに沿えば、ログとメトリクスで名前がずれる事故を防げます。

Kubernetesでは containerCollectAll で全コンテナのログを一括収集できますが、初期設定のまま本番に持ち込むのは避ける。サイドカーやシステム系のPodまで入り、取り込み量が数倍に膨らむためです。1〜2日流して内訳を見てから不要なNamespaceを除外し、残りにPodアノテーションで source と service を明示します。

AWS環境でForwarder LambdaとCloudWatch連携を選び分ける基準

AWSのマネージドサービスは、Agentを置く場所がありません。RDSのスロークエリログ、ALBのアクセスログ、Lambdaの実行ログはCloudWatch LogsかS3に出るため、Datadogへ橋渡しする経路を別に用意します。AzureはEvent Hubs経由、Google CloudはPub/Sub経由が標準経路で、関数コードを自前でデプロイする手順はない。到達遅延は経路ごとに変わり、Agentの秒単位に対しForwarderやPub/Sub経由はバッファのぶん遅れます。

Forwarder LambdaがCloudWatch LogsとS3を束ねる構成

Datadog Forwarderは、Datadogが配布するAWS Lambda関数です。CloudWatch Logsのサブスクリプションフィルタから起動する経路と、S3バケットのイベント通知から起動する経路を1つの関数で受けられる。CloudFormationテンプレートで配置し、APIキーはSecrets Managerに置く構成が既定です。

判断は、どこまで1本のForwarderに集約するかに尽きます。アカウントとリージョンをまたいで寄せると管理は楽ですが、同時実行数の上限に当たると全ログが同時に遅延する。ログ量が多い環境では、少なくとも本番と非本番で分けます。

ExcludeAtMatchで転送前に落とすノイズログの指定方法

ForwarderにはCloudFormationパラメータ ExcludeAtMatch があり、正規表現を書くと一致したログはDatadogへ送られません。Agent側の exclude_at_match と同じ役割をAWS側の経路で担う設定です。

効き目が大きいのはLambdaのランタイムログです。START、END、REPORT の3行は1実行につき必ず出るため、実行回数が多い関数では全件数の大半を占める。REPORT行以外を除外パターンに入れるだけで転送量が下がります。ただしコールドスタートの分析中はREPORT行が主役なので、調査期間だけ除外を外します。

log_processing_rulesで送信前に絞るフィルタとマスキングの書き方

Agentの log_processing_rules は、Datadogへ送る前にAgentのプロセス内で適用されます。ここで落としたログは一切届かないため、取り込み課金もインデックス課金も発生しない。複数のルールは順に適用され、各ルールは前のルールの結果に対して働きます。

exclude_at_matchとinclude_at_matchの適用順と併用時の挙動

exclude_at_match は指定パターンを含むログを送信対象から外し、include_at_match は一致したログだけを送ります。注意すべきは後者で、複数書くとすべてのパターンに一致する必要があり、OR条件にはなりません。OR条件で残したいときは1つの正規表現に交替をまとめて書く。ルールを増やすほどAND条件が積み上がり、想定より少ないログしか届かなくなります。設定変更の直後はLive Tailで件数の推移を確認します。

mask_sequencesとmulti_lineで機密値と例外を1件に収める書式

個人情報やトークンを送らないようにするのが mask_sequences です。pattern で対象を、replace_placeholder で置換後の文字列を指定し、$1 の形でキャプチャグループの一部だけを残せます。マスキングはAgent側で行うのが原則。パイプライン側のプロセッサで書き換えても、その時点で生の値はすでにDatadogのサーバへ到達しています。

multi_line は、指定パターンを新しいログの始まりとみなし、次に一致するまでの行を1件に束ねるルールです。パターンはログの先頭から一致する制約があるため、タイムスタンプの書式を指定するのが定石。1回の例外で40行出ていたものが1件になれば、インデックス課金は40分の1になります。単一ログが上限を超えたときはAgent 7.69以降の exclude_truncated で外せますが、アプリ側でJSON形式のログを出せるなら構造化ログをJSONで出力してslogやstructlogで実装する方法に沿って例外をひとつのフィールドへ収める方が壊れにくい。

パイプラインとプロセッサでログを標準属性へ寄せる処理順序の設計

Datadogに届いたログは、パイプラインを順に通って属性が付きます。パイプラインはフィルタとプロセッサの組で構成され、画面上の並び順で上から評価される。既定のパイプラインは source をフィルタ条件に持つため、自作を上に置くとパース結果を前提にしたプロセッサが空振りします。既定で拾える部分は既定に任せ、足りない属性だけを後段で補う。

Grokパーサとリマッパーでtimestampとstatusを写す設計

Grokパーサは、生のテキストログから名前付きの属性を切り出すプロセッサです。切り出した後、日付リマッパーで timestamp、ステータスリマッパーで status、サービスリマッパーで service を標準属性へ写す。省くと画面はすべて受信時刻で並び、エラーレベルの色分けも効きません。

Grokの記述は資産にも負債にもなります。ログ形式を変える権限が自チームにあるなら、書く前にJSON出力へ寄せる方が総コストは下がる。形式を変えられない他社製ミドルウェアに限ってGrokを書きます。

ログベースメトリクスへ寄せてインデックス件数を減らす判断基準

ログベースメトリクスは、パイプラインを通過したログから件数や数値属性を集計して保持する機能です。元のログをインデックスしなくても生成されるため、件数の推移だけ見たいログを外す受け皿になる。生成したメトリクスを閾値監視へ載せる手順はDatadogモニターのタイプ選定と閾値設計｜評価ウィンドウと通知テンプレートの実装手順で扱っています。

判断基準は明快です。個別のログ本文を読む必要があるならインデックス、件数や分位数だけ見るならログベースメトリクス。アクセスログのステータスコード別件数、バッチの処理件数、決済の成功失敗数は後者に該当します。この切り分けを先に済ませてから除外フィルタを書けば、量を落としてもDatadogダッシュボードのウィジェット選定とテンプレート変数の設計で組んだ画面やモニターは壊れません。

インデックスと除外フィルタの評価順で保管コストを抑える制御設計

ここが費用を左右する中心部です。Datadogは取り込んだログを、インデックスへ入れるかどうかで別々に課金します。2026年8月時点の公表価格では、15日保持のインデックスが100万イベントあたり1.70ドル、オンデマンドでは2.55ドル。課金単位の全体像はDatadogの料金体系と費用が膨らむ課金単位で扱っています。

インデックスフィルタが最初の一致1本で確定する仕様と並び順の設計

ログは、フィルタ条件に最初に一致したインデックスへ入ります。2番目以降には入りません。この仕様のため、並び順がそのまま優先順位になる。監査ログのように長期保持が必要なものを最上位に、アプリケーションログを中位に、条件を持たない受け皿を末尾へ置きます。逆順にすると、末尾のはずの短期インデックスへ全部吸い込まれる。

1アカウントで作れるインデックスは既定で100本までですが、実際には10本も使わない構成がほとんどです。分ける基準は保持期間の要件だけに限定し、環境やサービスの切り分けはタグで行う。サービスが増えるたびにインデックスとフィルタを足すと、並び順の見直し漏れで新しいログが末尾の受け皿へ落ちます。

除外フィルタのサンプリング率と1日あたりの上限で量を抑える設計

除外フィルタは、インデックスへ入れないログを指定する仕組みです。クエリの既定値は全ログを表す *、サンプリング率は0〜100%で設定し、属性値でグループ化した適用もできる。ここでも評価順の制約があり、処理は最初に一致した有効な除外フィルタだけで行われます。「サンプリング10%の除外」と「特定サービスの全除外」を両方書いたつもりが片方しか動かない事故はここで起きる。infoレベルを service でグループ化して90%除外すれば、サービスごとに1割ずつ残ります。

1日あたりの上限は、インデックス単位で百万件を単位として設定します。リセット時刻の既定は14時UTC、警告閾値は上限の50%以上で設定できる。デプロイ失敗で例外が大量に出た1日に月額予算を使い切る事故も、上限があれば頭打ちになります。ただし上限到達中は新しいログを検索できないため、警告閾値のイベントを通知先へ流す運用とセットにする。通知の設計はアラート疲れの原因と監視実装からの対策で整理しています。

インデックスせず残す選択肢とFlex Logs・アーカイブの使い分け

除外フィルタで外したログは消えません。公式ドキュメントは、除外後もLive Tail、ログベースメトリクスの生成、アーカイブへの保存が続くと記しています。失われるのは過去に遡った検索だけ。障害が起きた3日前のログを絞り込みたいとき、インデックスに入っていなければ検索窓には出てきません。

Flex Logsの保存とコンピュートを分ける課金構造と選択条件

Flex Logsは、保存と検索の計算資源を別々に課金する保管方式です。2026年8月時点の公表価格では、保存が100万イベントあたり0.05ドル（年間契約、オンデマンドは0.075ドル）、Flex Computeがインスタンス時間あたり0.05ドルから。標準インデックスの1.70ドルと比べ、保存単価は30分の1以下です。

選択条件は検索頻度です。週に何度も遡るログは標準インデックス、月に1〜2回の調査に使うログはFlex Logs。検索がほぼ発生せず保存義務だけがあるログは、次項のアーカイブへ置きます。

S3アーカイブとRehydrateで監査ログを長期保管する設計

アーカイブは、取り込んだログをS3、Azure Blob Storage、Google Cloud Storageへ書き出す機能です。クラウドアーカイブへの書き出しは取り込み料金に含まれ、別途の転送課金は発生しない。第三者の宛先へ転送する場合のみ、送信1GBあたり0.25ドルが別建てになります。

アーカイブしたログは、必要になった時点でRehydrateしてインデックスへ戻せます。監査対応で半年前のログを求められる状況では、この経路が現実解。設計時に決めるのは保存先バケットのライフサイクルルールとRehydrateの権限者で、範囲を広く取ると請求に跳ねるため期間を絞る手順も運用手順書に書いておく。

Datadogでログを一元管理しない方が安い場面と移行時の失敗パターン

ここは判断を言い切ります。Datadogのログ管理の価値は、メトリクスやAPMと同じ画面で突き合わせられる点にある。裏を返せば、突き合わせる相手がいない環境では価値が出ません。

月間ログ量が数十GB未満のときに一元管理を見送る条件と代替手段

次の3条件がすべて当てはまるなら、Datadogへのログ集約は見送ります。サーバが数台規模で構成が固定されていること、APMやRUMを導入せずログ単独で使うこと、調査が月に数回に留まること。この条件下ではCloudWatch Logs Insights等で足ります。

逆に、コンテナで台数が動的に変わる、1リクエストが複数サービスをまたぐ、APMのトレースIDからログへ飛びたい、のいずれかに当てはまるなら集約する。ホストが入れ替わってもタグで追える点と、トレースとログが同じIDで結ばれる点は、単体のログ検索サービスでは再現できません。製品の全体像はDatadogとは何か、機能と導入の背景で解説しています。

全ログをインデックスして初月の請求が跳ねる典型的な失敗パターン

最も多い失敗は、除外フィルタを何も入れずに本番へ展開することです。取り込みは1GBあたり0.10ドルなので、月100GBでも10ドル程度に収まる。ところが同じログが1件500バイトなら約2億件で、全部インデックスすると15日保持で340ドル、取り込み費の34倍が乗ります。初日はインデックス上限を低めに置き、件数の内訳を1〜2日測り、上位を占めるログが見えた時点で除外フィルタを書いてから上限を運用値へ上げる。

もう1つの失敗は経路の入れ替えです。Forwarder経由からAgent経由へ、あるいはOpenTelemetry Collector経由へ切り替えると、ログに付く属性の名前と値が変わります。service が変わればモニターの条件が空振りし、保存済みの検索条件もテンプレート変数も一致しなくなる。旧経路を止める前に新経路を並走させ、同じ service と source で届くことを確認してから落とします。OTLP経由の属性マッピングはDatadog OpenTelemetry連携の4方式とDDOTの選び分けで扱っています。

収集経路の選定から除外フィルタの調整までは、一度作って終わりではなく、サービスの増減に合わせて数か月おきに見直す運用作業です。社内に監視の専任を置けない場合は、保守運用・内製化支援で設計と定期見直しを引き受けています。既存環境の棚卸しからインデックス方針の設計、運用手順の内製化までを段階的に移管する形も選べます。

よくある質問：Datadogのログ収集と保管コストでつまずく点

ログ収集の設定と費用について、問い合わせの多い5点に答えます。

Datadogの設定を入れてもログが届かないときは何を見ますか？

確認は3段階です。まず datadog.yaml の logs_enabled が true か。次にAgentのステータス出力にLogs Agentのセクションが出ており、対象ファイルが一覧に載っているか。最後にAgent実行ユーザーが対象ファイルを読めるかどうか。ファイルが出ているのに件数が0なら、権限か include_at_match での絞り込みを疑います。このルールは複数書くとAND条件になる点も確認します。

Forwarder LambdaとDatadog Agentはどちらを先に入れるべきですか？

Agentを先に入れます。AgentはメトリクスとAPMの土台にもなるため、動いていればホストとコンテナのログはそのまま拾えます。Forwarderは、Agentでは届かないマネージドサービスのログ（RDS、ALB、Lambdaなど）を補う位置づけ。両方をいきなり入れると、同じログが二重に届いたときの切り分けが難しくなります。

インデックスしなかったログは後から検索できますか？

そのままでは検索できません。除外フィルタで外したログはLive Tailには流れ、ログベースメトリクスの生成とアーカイブへの保存も続きますが、過去に遡った検索の対象には入らない。後から調べる可能性があるログは、Flex Logsに保存するかS3アーカイブに置いてRehydrateで戻す設計にします。

ログの保管コストを短期間で下げるには何から手を付けますか？

順番は3つです。第一にログベースメトリクスへの置き換えで、件数だけ見ているログをメトリクス化し本体はインデックスから外す。第二に multi_line の設定で、スタックトレースが行ごとに課金されている環境ではこれだけで件数が大きく落ちます。第三は除外フィルタのサンプリング。これで足りない場合に、標準インデックスからFlex Logsへの移行を検討します。

既存のCloudWatch Logsを全部Datadogへ移すべきですか？

全部を移す必要はありません。CloudWatch Logsに残したまま、Datadogへ送るのは調査で使うログに絞る構成が実務的です。判断軸は、APMのトレースやメトリクスと突き合わせる場面があるかどうか。突き合わせないログはCloudWatch側に置く方が費用は下がる。移す場合も、Forwarderの ExcludeAtMatch でノイズを落としてから送ります。

関連記事

• Datadogの使い方｜アカウント作成から最初の監視までの手順：ログ収集の前段となる初期導入の流れを扱っています。
• Datadog Agent導入の実装手順｜ホスト・Docker・DaemonSet：本記事の前提となるAgentの設置方式を解説しています。
• Datadog運用のベストプラクティス｜タグ設計とコスト抑制：ログとメトリクスで名前をそろえるタグ命名規約をまとめています。
• Datadogの料金体系と費用が膨らむ課金単位：ログ以外も含めた課金単位の全体像を整理しています。
• 構造化ログとは｜JSONでログを機械可読にする仕組み：Grokに頼らずJSONで出す側の設計を解説しています。