Keep
Synopsis
Keeps only specified fields and removes all others.
Schema
- keep:
field: <string|string[]>
description: <text>
if: <script>
ignore_failure: <boolean>
on_failure: <processor[]>
on_success: <processor[]>
tag: <string>
Configuration
The following fields are used to define the processor:
| Field | Required | Default | Description |
|---|---|---|---|
field | Y | - | Field name(s) to keep. Can be a single string or an array of strings |
description | N | - | Explanatory note |
if | N | - | Condition to run |
ignore_failure | N | false | Continue processing if field operations fail |
on_failure | N | - | Error handling processors |
on_success | N | - | Success handling processors |
tag | N | - | Identifier |
Details
Removes all fields from the log entry except those explicitly specified. This processor performs the inverse operation of remove, allowing you to specify which fields to retain while discarding all others.
The keep processor operates at the top level of the log entry. When specifying nested fields like user.id, the processor will keep the entire parent object (user) and not just the specific nested field.
The processor is useful for creating a minimal document with only essential fields, reducing the size of log entries, or ensuring consistent field presence for downstream systems.
Using the keep processor is a destructive operation that removes all non-specified fields. This can lead to loss of potentially useful data. Consider creating a copy of important data before applying keep operations or ensure that your field list is comprehensive.
Examples
Single Field
Keeping only essential identifier field... | |
removes all fields except id: | |
Multiple Fields
Preserving selected fields from a nested structure... | |
creates a minimal document with specific fields: | |
Templates
Dynamically selecting fields to keep... | |
keeps event-specific fields based on event type: | |
Conditional
Applying different keep rules based on conditions... | |
keeps different sets of fields based on log level |