リマッププロセッサーは、個々のログデータ内のフィールドを追加 (add)、削除 (drop)、またはリネーム (rename) できます。このプロセッサーを使用して、ログに追加のコンテキストを付与したり、ログ容量を削減するために価値の低いフィールドを削除したり、重要な属性全体で命名を標準化したりします。はじめるには、ドロップダウンメニューから add field、drop field、または rename field を選択してください。

フィールドを追加

add field を使用して、ログに新しいキーと値のペアを追加します。

add field プロセッサーの設定方法

1. filter query を定義します。指定されたフィルタークエリに一致するログだけが処理されます。クエリに一致する・しないに関係なく、すべてのログはパイプラインの次のステップに送られます。
2. 追加したいフィールド名と値を入力します。ネストされたフィールドを指定する場合は、パス表記の <OUTER_FIELD>.<INNER_FIELD> 形式を使用してください。すべての値は文字列として格納されます。 注: 追加しようとしているフィールドがすでに存在する場合、Worker はエラーをスローし、既存のフィールドは変更されません。

フィールドを削除

drop field を使用して、指定したフィルタに一致したログデータからフィールドを削除します。オブジェクトを削除することも可能なため、ネストされたキーを削除する場合にもこのプロセッサーを使用できます。

drop field プロセッサーの設定方法

1. filter query を定義します。指定されたフィルタークエリに一致するログだけが処理されます。クエリに一致する・しないに関係なく、すべてのログはパイプラインの次のステップに送られます。
2. 削除したいフィールドのキーを入力します。ネストされたフィールドを指定する場合は、パス表記の <OUTER_FIELD>.<INNER_FIELD> 形式を使用してください。 注: 指定したキーが存在しない場合、そのログには変更が加えられません。

フィールドをリネーム

rename field を使用して、ログ内のフィールド名を変更します。

rename field プロセッサーの設定方法

1. filter query を定義します。指定されたフィルタークエリに一致するログだけが処理されます。クエリに一致する・しないに関係なく、すべてのログはパイプラインの次のステップに送られます。
2. Source field にリネームしたいフィールドの名前を入力します。ネストされたフィールドを指定する場合は、パス表記の <OUTER_FIELD>.<INNER_FIELD> 形式を使用してください。リネーム後は元のフィールドが削除されますが、後述の Preserve source tag チェックボックスを有効にすると元のフィールドを保持できます。
   注: 指定したソースキーが存在しない場合、デフォルトで null 値がターゲットに適用されます。
3. Target field にソースフィールドをリネーム後の名前として入力します。ネストされたフィールドを指定する場合は、パス表記の <OUTER_FIELD>.<INNER_FIELD> 形式を使用してください。
   注: 指定したターゲットフィールドがすでに存在する場合、Worker はエラーをスローし、既存のターゲットフィールドを上書きしません。
4. 必要に応じて、Preserve source tag チェックボックスをオンにすると、元のソースフィールドを保持して、ソースキーの情報を指定したターゲットキーに重複させることができます。このボックスをオフにした場合は、リネーム後にソースキーが削除されます。

パス表記例

以下のようなメッセージ構造があった場合、double_inner_value という値を持つキーを指すには、outer_key.inner_key.double_inner_key のように記述します:

{
    "outer_key": {
        "inner_key": "inner_value",
        "a": {
            "double_inner_key": "double_inner_value",
            "b": "b value"
        },
        "c": "c value"
    },
    "d": "d value"
}

Filter query syntax

Each processor has a corresponding filter query in their fields. Processors only process logs that match their filter query. And for all processors except the filter processor, logs that do not match the query are sent to the next step of the pipeline. For the filter processor, logs that do not match the query are dropped.

For any attribute, tag, or key:value pair that is not a reserved attribute, your query must start with @. Conversely, to filter reserved attributes, you do not need to append @ in front of your filter query.

For example, to filter out and drop status:info logs, your filter can be set as NOT (status:info). To filter out and drop system-status:info, your filter must be set as NOT (@system-status:info).

Filter query examples:

• NOT (status:debug): This filters for only logs that do not have the status DEBUG.
• status:ok service:flask-web-app: This filters for all logs with the status OK from your flask-web-app service.
  • This query can also be written as: status:ok AND service:flask-web-app.
• host:COMP-A9JNGYK OR host:COMP-J58KAS: This filter query only matches logs from the labeled hosts.
• @user.status:inactive: This filters for logs with the status inactive nested under the user attribute.

Queries run in the Observability Pipelines Worker are case sensitive. Learn more about writing filter queries in Datadog’s Log Search Syntax.