Observability Pipelines
ログとメトリクスを Datadog へ送る前に、自社環境で動く Worker が集約し、加工し、宛先へ振り分ける前処理の層です。減らす、伏せ字にする、複数の宛先へ配るという判断を、データが環境の外へ出る前に済ませられます。
何ができるか
自社のサーバーや Kubernetes 上で Observability Pipelines Worker を動かし、Agent や Syslog や Kafka などから受けたログを、フィルターや伏せ字化やメトリクス化のプロセッサーで加工したうえで、Datadog Logs、オブジェクトストレージ、SIEM 製品といった複数の宛先へ送ります。パイプラインの設計と Worker の配備は Datadog 側の画面から行います。
どのような場面で使うか
個人情報や秘密情報を含むログを社外に出す前に伏せ字にしたい、Datadog と自社の SIEM の両方へ同じログを配りたい、デバッグログや重複したログを取り込み前に落として請求を抑えたい、といった場面で使います。ログ管理の移行期に旧基盤と Datadog へ二重送信する用途も公式テンプレートに含まれます。
身近な例え
社外へ郵便を出す前の社内郵便室です。各部署から集まった封書を 1 か所で受け取り、宛先ごとに仕分け、見せてはいけない部分を黒く塗り、同じ知らせを複数の宛先へ写しで送り、不要な広告は捨てる。建物の外へ出る前にこの作業を済ませるので、外の配送会社 (Datadog を含む各宛先) には整えた分だけが届きます。
Datadog に届く前に処理する層が Observability Pipelines
Observability Pipelines は、ログとメトリクスを自社のインフラの中で集めて加工し、複数の宛先へ振り分ける製品です。公式ドキュメントはこれを「データが環境を離れる前に、オブザーバビリティデータへの制御を与えるもの」と位置づけ、機密情報の伏せ字化、付加情報の追加、ノイズの除外、Datadog や SIEM やクラウドストレージへの振り分けをテンプレートで組めると説明しています (2026 年 9 月時点・出典: Observability Pipelines)。ログ管理 の ログパイプライン が Datadog に届いた後の工程であるのに対し、こちらは届く前の工程です。課金は Worker が取り込んだ非圧縮 GB 単位で、年契約 / 月契約 / オンデマンドの 3 つの契約形態ごとに単価が公開されています (2026 年 8 月時点・出典: Datadog Pricing)。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
- ソース: Datadog Agent、Syslog、Kafka、Fluentd、HTTP、クラウドのログ配信サービスなど (公式一覧に 24 種)
- Worker (自社環境): プロセッサー群で除外、サンプリング、伏せ字化、項目の削除、メトリクス化、付加情報の追加
- 宛先: Datadog Logs、Datadog Archives、Amazon S3、Google Cloud Storage、Azure Storage、Splunk HEC、Microsoft Sentinel、Elasticsearch など (公式一覧に 24 種)
クラウド側のログパイプラインと何が違うか
同じ「パイプライン」という名前でも、動く場所と処理の時点が違います。ログ管理のパイプラインは Datadog がログを受け取った後に走り、パース、属性の付与、インデックスへの振り分けを担います。Observability Pipelines の処理は自社環境の Worker の中で走り、Datadog に届くのは加工後のデータだけです。公式ドキュメントも、Worker のプロセッサーは「オンプレミスのロギング環境向け」で、クラウド側のログの構造化や付加情報の追加はログ管理の側で行うと書き分けています (2026 年 9 月時点・出典: Processors)。課金も別の行で、Worker の取り込み GB に対する単価と、Datadog 側の取り込み (Ingest) 単価は独立して掛かります。つまり Worker を通しても Datadog へ送った分の Ingest 課金は残り、減るのは Worker で落とした分だけです。
| 観点 | Observability Pipelines (Worker) | ログ管理のパイプライン |
|---|---|---|
| 動く場所 | 自社のサーバー、Kubernetes、ECS Fargate | Datadog 側 |
| 処理の時点 | Datadog に届く前 | Datadog が受け取った後 |
| 主な処理 | 除外、サンプリング、伏せ字化、項目削除、集約、メトリクス化、振り分け | パース、属性の付与、標準属性への正規化、インデックスへの振り分け |
| 宛先 | Datadog を含む複数の外部宛先 (1 パイプラインに 20 まで) | Datadog のインデックスとアーカイブ |
| 課金の単位 | Worker が取り込んだ非圧縮 GB (年契約 / 月契約 / オンデマンドの 3 単価・2026 年 8 月時点) | Ingest は取り込み GB、Index はイベント数と保持日数 |
公式テンプレートが示す用途は、減らす、隠す、配るの 3 系統
公式ドキュメントのテンプレート一覧は 2026 年 9 月時点でログ向けが 7 つ、メトリクス向けが 1 つで、用途は 3 系統に整理できます (出典: Observability Pipelines)。減らす系統は Log Volume Control と Generate Log-based Metrics、隠す系統は Sensitive Data Redaction、配る系統は Dual Ship Logs、Split Logs、Archive Logs です。Log Enrichment は付加情報を足す下支えで 3 系統をまたぎ、メトリクス側の Metric Tag Governance は不要なタグを落として高カーディナリティを防ぐ用途です。3 系統のうち Datadog 側の機能で代替しにくいのは隠す系統と配る系統で、減らす系統は除外フィルターでも一部を賄えます。この違いが後の 2 節の損得に直結します。
| テンプレート | 公式の説明 (要約) | 系統 |
|---|---|---|
| Log Volume Control | 価値の低いログを保存前に除外して索引量を減らす | 減らす |
| Generate Log-based Metrics | 大量のログをカウントや分布のメトリクスに変換する | 減らす |
| Sensitive Data Redaction | 個人情報と秘密情報を組み込みまたは独自ルールで検出して除去する | 隠す |
| Dual Ship Logs | 同じログの流れを複数の宛先へ送る | 配る |
| Split Logs | ログの種類ごとに別のツールへ振り分ける | 配る |
| Archive Logs | 生ログをオブジェクトストレージに長期保存し、後からリハイドレートする | 配る |
| Log Enrichment | 参照テーブルや固定の対応表から付加情報を足す | 下支え |
| Metric Tag Governance (メトリクス) | 必要なメトリクスだけを残し、不要なタグを落として高カーディナリティを防ぐ | 減らす |
Worker の置き場所と設定の配り方
Worker は自社環境に置くソフトウェアで、公式の導入手順は Linux (RHEL と CentOS は 8.0 以上)、Docker、Kubernetes (主要ディストリビューション)、ECS Fargate を対象にしています (2026 年 9 月時点・出典: Install the Worker)。パイプラインは Datadog 側の画面で組み、画面は作成、Worker の配備と管理、健全性モニターの有効化の 3 役を担います。Worker の起動時にはパイプライン ID と API キーを渡し、キーは Remote Configuration が有効である必要があります。設定ファイルを台数分配るのではなく、画面で編集した内容を Worker が受け取る形です。プロセッサーは上から順に評価され、1 キャンバスにプロセッサグループ 25、プロセッサー 150、宛先は 1 パイプラインに 20 までの上限があります。Worker は少なくとも月 1 回の更新が推奨されています。
- 1. 画面で Observability Pipelines を開き、用途に合うテンプレートを選ぶ
- 2. ログのソースを選ぶ
- 3. プロセッサーを設定する (テンプレートに応じた初期セットが入る)
- 4. 宛先を 1 つ以上追加する
- 5. Worker を自社環境に導入する (パイプライン ID と Remote Configuration 有効の API キー)
- 6. パイプラインの健全性を追うモニターを有効にする
ログ課金を減らせる場所の地図 - Ingest の前で落とせるのはここだけ
ログ課金を減らす手段は 4 層に分けると位置が見えます。アプリや Agent の設定でログレベルを絞るのが 1 層目、Worker で落とすのが 2 層目、Datadog に届いた後に 除外フィルター でインデックスから外すのが 3 層目、保持日数と アーカイブ の設計が 4 層目です。取り込み (Ingest) 課金は Datadog に届いた GB に掛かるため、3 層目では Index の課金だけが減り、Ingest は残ります。Ingest の手前で削れるのは 1 層目と 2 層目だけで、アプリ側の変更なしに削れるのは Worker だけです。公式のログ量削減ガイドは Worker の手段として、サンプリング、フィルター、属性の削除、集約、重複排除、クォータ、アーカイブへの直送の 7 つを挙げています (2026 年 9 月時点・出典: Strategies for Reducing Log Volume)。全体は ログ料金の 3 層、手順は コスト見直しのチェック へ。
| 層 | 手段 | 減る課金 | 追加で掛かるもの |
|---|---|---|---|
| 1. アプリと Agent の設定 | ログレベルと出力先の見直し | Ingest と Index | なし (アプリ側の変更が要る) |
| 2. Worker (Observability Pipelines) | フィルター、サンプリング、属性削除、集約、重複排除、クォータ、アーカイブ直送 | Ingest と Index | Worker の取り込み GB 課金と Worker の運用 |
| 3. Datadog 取り込み後 | 除外フィルター、インデックスの設計 | Index のみ | なし |
| 4. 保持とアーカイブ | 保持日数の短縮、アーカイブとリハイドレート | Index (保持日数分) | アーカイブ先のストレージ費用 |
Worker を立てる価値が出る条件、出ない条件
Worker の取り込み GB に対する単価と、Datadog 側の Ingest 単価は、どちらも GB あたりで公開され、料金ページでは近い水準に置かれています (いずれも年契約の値・2026 年 8 月時点・出典: Datadog Pricing)。この関係が意味するのは、全量を Worker に通して一部を落とすだけでは元が取れにくい、ということです。式にすると、Worker 側の増分は「全量 × Worker 単価」、Ingest 側の減少は「落とした量 × Ingest 単価」で、両単価が近い限り、落とす割合が相当高くなければ取り込み課金の差は埋まりません。効くのは次のどれかが立つときです。Index 側の削減を含めて計算する (Worker で落としたログは索引にも乗らず、索引の費用は取り込みより大きくなりやすい)、伏せ字化や複数宛先への配送のように Datadog 側で代替できない要件がある、宛先が Datadog 以外にもあり同じ加工を一度で済ませたい、の 3 つです。Datadog 単独で索引量を減らしたいだけなら、除外フィルターとログレベルの見直しで足ります。月 30 TB 超の規模向けに vCPU 単位の価格もありますが、単価は公開価格表に出ません。
注意点
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。ソース、プロセッサー、宛先、テンプレートの種類と上限値は変わり得るため、設計時は公式ドキュメントの一覧を優先してください。
- 本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
- Worker の取り込み GB に対する課金は、Datadog 側のログ取り込み (Ingest) 課金とは別に掛かります。Worker を通したログを Datadog Logs へ送る場合、送った分の Ingest 課金は残ります (2026 年 8 月時点の料金体系に基づく)。