パイプライン

パイプライン

概要

Datadog は、JSON 形式のログを自動的にパースします。ログが JSON 形式でない場合は、生ログを処理パイプラインを経由して送信することで、ログの価値を高めることができます。

パイプラインを使用すると、いくつかのプロセッサーを通して順次ログをつなぐことにより、ログがパースされ補完されます。これにより、半構造化されたテキストから意味のある情報や属性を抽出し、ファセットとして再利用することができます。

パイプラインを経由するログは、すべてのパイプラインフィルターに対してテストされます。いずれか 1 つにマッチしたログは、すべてのプロセッサーが順次適用されてから、次のパイプラインに移動します。

ある処理パイプラインの以下のようなログを例にします。

これは、次のログに変換できます。

このパイプラインの例

パイプラインはさまざまな形式のログを受け取り、それらを Datadog の共通形式に翻訳します。

たとえば、最初にアプリケーションログプレフィックスを抽出するパイプラインを定義したら、チームごとにログメッセージの他の部分を処理する独自のパイプラインを自由に定義できます。

パイプラインフィルター

フィルターを使用すると、パイプラインを適用するログの種類を制限できます。

フィルターの構文は検索バーと同じです。

: パイプラインフィルターはパイプラインのプロセッサーの前に適用されます。パイプライン自体で抽出される属性で絞り込みを行うことはできません。

次のログストリームは、どのログにパイプラインが適用されるかを示します。

ネストされたパイプライン

ネストされたパイプラインとは、パイプラインの内部のパイプラインのことです。ネストされたパイプラインを使用すると、処理を 2 段階に分けることができます。たとえば、チームなどの高レベルのフィルタリングを使用してから、インテグレーション、サービス、タグ、属性などに基づく第 2 レベルのフィルタリングを使用します。

パイプラインは、ネストされたパイプラインとプロセッサーを持つことができます。一方、ネストされたパイプラインは、プロセッサーしか持つことができません。

あるパイプラインを別のパイプラインにドラッグアンドドロップして、ネストされたパイプラインに変換することができます。

特殊なパイプライン

JSON ログの前処理

JSON ログの前処理は、ログがパイプライン処理に入る前に発生します。前処理では、予約済み属性に基づく一連の操作(timestampstatushostservicemessage など)を実行します。JSON ログに異なる属性名がある場合は、前処理を使用してログ属性名を予約済み属性リストの属性名にマップします。

前処理を実行する場合:

たとえば、次のログを生成するサービスについて考えてみます。

{
  "myhost": "host123",
  "myapp": "test-web-2",
  "logger_severity": "Error",
  "log": "cannot establish connection with /api/v1/test",
  "status_code": 500
}

JSON ログ前処理は、デフォルトで標準ログフォワーダーに機能するよう構成されています。このコンフィギュレーションは、カスタムまたは特定のログ転送方法に合わせて編集することが可能です。

JSON ログの前処理を開き、デフォルトのマッピングを変更します。

これにより、次のログが生成されます。

注: JSON ログの前処理は、ログ属性の 1 つをログの host として定義する唯一の方法です。

ソース属性

JSON 形式のログファイルに ddsource 属性が含まれる場合、Datadog はその値をログのソースと解釈します。Datadog が使用しているソース名を使用する場合は、インテグレーションパイプラインライブラリを参照してください。

: コンテナ化環境から取得したログの場合、環境変数を使用してデフォルトのソース値とサービス値をオーバーライドする必要があります。

ホスト属性

Datadog Agent または RFC5424 形式を使用すると、自動的にログにホスト値が設定されます。ただし、JSON 形式のログファイルに以下の属性が含まれる場合、Datadog はその値をログのホストと解釈します。

  • host
  • hostname
  • syslog.hostname

日付属性

デフォルトでは、Datadog は、ログを受信したときにタイムスタンプを生成し、それを date 属性に付加します。ただし、JSON 形式のログファイルに以下の属性のいずれかが含まれる場合、その値をログの正式な日付と解釈します。

  • @timestamp
  • timestamp
  • _timestamp
  • Timestamp
  • eventTime
  • date
  • published_date
  • syslog.timestamp

ログ日付リマッパープロセッサーを設定し、別の属性を指定してログの日付のソースとして使用します。

: ログエントリの正式な日付が 18 時間以上前だった場合、Datadog はそのエントリを拒否します。

認識される日付の形式は、ISO8601UNIX (ミリ秒エポック形式)、および RFC3164 です。

メッセージ属性

デフォルトで、Datadog ではメッセージの値をログエントリの本文として収集します。この値がハイライトされてログストリームに表示され、全文検索用にインデックス化されます。

ログメッセージリマッパープロセッサーを設定し、別の属性を指定してログのメッセージのソースとして使用します。

ステータス属性

各ログエントリにはステータスレベルを指定でき、Datadog 内のファセット検索で使用できます。ただし、JSON 形式のログファイルに以下の属性のいずれかが含まれる場合、Datadog はその値をログの正式なステータスと解釈します。

  • status
  • severity
  • level
  • syslog.severity

status 属性の既存のステータスを再マップするには、ログステータスリマッパーを使用します。

サービス属性

Datadog Agent または RFC5424 形式を使用すると、自動的にログにサービス値が設定されます。ただし、JSON 形式のログファイルに以下の属性が含まれる場合、Datadog はその値をログのサービスと解釈します。

  • service
  • syslog.appname

ログサービスリマッパープロセッサーを設定し、別の属性を指定してログのサービスのソースとして使用します。

トレース ID 属性

デフォルトで、Datadog トレーサーは、自動的にログにトレースとスパンの ID を挿入します。ただし、JSON 形式のログに以下の属性が含まれる場合、Datadog はその値をログの trace_id と解釈します。

  • dd.trace_id
  • contextMap.dd.trace_id

トレース ID リマッパープロセッサーを設定し、別の属性を指定してログのトレース ID のソースとして使用します。

インテグレーションパイプライン

サポートされているインテグレーションのリストは、こちらでご確認ください。

ログを収集するようセットアップされている一部のソースには、インテグレーション処理パイプラインを使用できます。インテグレーションログにインテグレーションパイプラインが自動的にインストールされ、ログをパースして対応するファセットをログエクスプローラーに追加します。

これらのパイプラインは読み取り専用であり、各ソースに適した方法でログをパースします。インテグレーションパイプラインを編集するには、それを複製した上で編集します。

以下の ELB ログの例を参照してください。

インテグレーションパイプラインライブラリ

Datadog で利用可能なインテグレーションパイプラインの一覧については、インテグレーションパイプラインライブラリをご覧ください。パイプラインライブラリにて、Datadog がデフォルトで各ログフォーマットを処理する方法をご確認いただけます。

インテグレーションパイプラインライブラリ

インテグレーションパイプラインを使用する場合、Datadog は対応するログの source を構成し、インテグレーションをインストールすることを推奨しています。Datadog がこのソースから初回のログを受信すると、インストールが自動でトリガーされ、インテグレーションパイプラインが処理対象のパイプラインリストに追加されます。ログソースの構成については、対応するインテグレーションのドキュメントを参照してください。

コピーボタンをクリックしてインテグレーションパイプラインをコピーすることもできます。

ライブラリからパイプラインを複製

その他の参考資料