ログパイプライン
Datadog が受け取ったログをプロセッサへ順番に通し、本文から属性を取り出して検索や集計に使える形へ整える工程。届いたログはすべてのパイプラインのフィルタと照合され、一致したものの処理が適用される。
概要
ログパイプラインは、Datadog が受け取ったログをプロセッサへ順番に通し、決まった形を持たない本文から属性を取り出して検索や集計に使えるようにする工程です。JSON 形式のログには前処理の段があり、独自の属性名を日時・状態・ホスト・サービス・本文の予約属性へ対応づけます。フィルタはそのパイプラインのプロセッサより前に判定されるため、パイプライン内で抽出した属性を条件に使うことはできません。設定はすべて画面上で完結し、アプリケーション側の変更は不要です。
ログを受け取ったあとに構造を与える工程
ログパイプライン (Log Pipeline) は、Datadog が受け取ったログをプロセッサへ順番に通し、解析と情報の追加を行う工程です。決まった形を持たない本文から値を取り出して属性にし、その属性を検索や集計で使えるようにします。ログインデックス に入る前の整形作業だと考えるとよいでしょう。届いたログは、すべてのパイプラインのフィルタと順に照合されます。条件に一致したパイプラインのプロセッサが適用され、そのまま次のパイプラインへ進みます。JSON 形式のログは追加の設定なしに解析されるため、送る側で JSON を出しておくと後の作業が減ります。設定はすべて Datadog の画面上で完結します。アプリケーション側のログ出力の設定を書き換えたり、サーバーへ何かを配布し直す必要はありません。なお、この仕組みが対象とするのはクラウド上のログで、自社設備の中で処理を終わらせたい場合は Observability Pipelines という別の仕組みを使います。
前処理はパイプラインより前に走る
JSON 形式のログには、パイプラインより前に走る前処理の段があります。ここでは独自の属性名を、Datadog が特別に扱う予約属性 (日時・状態・ホスト・サービス・本文) へ対応づけます。既定の設定は一般的な転送手段に合わせてあるので、多くの場合は触らずに動きます。
| 予約属性 | 既定で読まれるキー | 気をつける点 |
|---|---|---|
| 日時 | @timestamp・timestamp・eventTime・published_date など | 正式な日時が 18 時間より古いログは受け付けられない。形式は ISO8601・UNIX (ミリ秒)・RFC3164 |
| 状態 | status・severity・level・syslog.severity | 検索の絞り込みに使える値になる |
| ホスト | host・hostname・syslog.hostname | Kubernetes ではこのキーが Agent の持つホスト名を上書きし、期待していたホスト側の タグ が付かなくなる |
| サービス | service・syslog.appname・dd.service | Datadog Agent 経由なら自動で入る |
| 本文 | message・msg・log | 全文検索の対象となる本文として扱われる |
ホストの指定だけは、この前処理でしか行えません。あとから属性を書き換えるプロセッサを並べても、ログをホスト単位で束ねる扱いにはならないため、ホスト名の取り違えはここで直します。上の表以外のキーを使いたい場合は、対応する付け替えのプロセッサで指定します。
フィルタは自分のプロセッサより先に判定される
パイプラインを作るときは、まず対象を選ぶフィルタを書きます。ここで注意したいのは、フィルタの判定がそのパイプラインのプロセッサより前に行われることです。パイプラインの中で取り出した属性を条件に使うことはできないので、その属性で分けたい場合は入れ子のパイプラインへ回します。名前のほかに説明とタグを付けられます。ここでのタグはログには影響せず、パイプラインの一覧を絞り込むための目印です。数が増えたときに、どの担当が何のために置いたのかを追えるようにしておくと保守が楽になります。よく使われるログの送信元には、Datadog が用意した統合パイプラインがあります。対応する送信元を設定して最初のログが届くと自動で追加され、その形式に合った解析が最初から入った状態になります。読み取り専用なので手を入れたいときは複製してから編集します。削除はできず、無効化のみが可能です。既定でどう処理されるのかは統合パイプラインの一覧で確認できます。
同じ属性を複数のプロセッサが書いたとき
条件に一致するパイプラインが複数あり、同じ属性へ値を入れようとすることがあります。どちらが残るのかはプロセッサの種類で決まり、挙動は三通りです。
| 挙動 | 結果 | 主なプロセッサ |
|---|---|---|
| 後の書き込みが残る | 順序が後のプロセッサの値で上書きされる | Grok 解析・分類・計算・文字列の組み立て・照合表・URL 解析・利用環境の解析・位置情報の解析 |
| 設定次第 | 上書きするかどうかを選べる。既定では対象がすでに埋まっていれば上書きしない | 属性の付け替え・配列の写し取り |
| 先の書き込みが残る | 先に一致したものだけが効く。パイプラインをまたぐ場合も最初に出会ったものが効く | 状態・サービス・本文・トレース・スパン の付け替え (日時の付け替えだけは例外で、最後が効く) |
この違いを知らないまま並べ替えると、直したはずの属性が元に戻ったように見えます。触るプロセッサがどの挙動なのかを先に確かめるのが早道です。数の目安もあります。Datadog は一つのパイプラインに置くプロセッサを 20 個まで、Grok 解析の規則を 10 個までとすることを推奨しており (2026 年 8 月時点)、極端に負荷の高い規則やパイプラインは Datadog 側で止められる場合があります。長く積み上げるより入れ子で分けるほうが安全です。
変えるときは先に効き目を見る
パイプラインやプロセッサを作り直すときは、適用する前に効き目を確かめられます。流れているログをそのまま使い、変更前と変更後を並べて比べる画面が用意されています。比べる相手は、いま動いている版と自分の変更を比べる方法と、パイプラインに入る前のログと全体を通した後のログを比べる方法の二つから選べます。一覧は影響の有無でも絞り込めます。すべてのログ、変更で中身が変わったログ、変わらなかったログの三つです。件数が多いときは、変わったものだけを見れば意図しない副作用に気付けます。運用の面では、最後に誰がいつ変えたのかが各パイプラインに表示され、それを条件に一覧を絞り込めます。編集の権限は二段階で、パイプライン全体を触れる役と、プロセッサと入れ子のパイプラインだけを触れる役に分けられます。後者はフィルタの条件と並び順を変えられないため、担当を分けたい組織に向きます。各パイプラインには取り込んだ量と件数の見積もりも表示され、詳しい内訳は既定の利用量ダッシュボードから確認できます。詳細は Datadog の Log Pipelines を参照してください。