Skip to main content

Contains

Flow Control

Synopsis

Checks if a specified field value exists within a list of values, enabling conditional processing based on value matching. This is useful for filtering, routing, or validating data based on predefined or dynamic lists.

Schema

- contains:
field: <ident>
case_sensitive: <boolean>
description: <text>
disabled: <boolean>
if: <script>
ignore_failure: <boolean>
ignore_missing: <boolean>
list: <string[]>
list_field: <ident>
on_failure: <processor[]>
on_success: <processor[]>
partial: <boolean>
tag: <string>

Configuration

The following fields are used to define the processor:

FieldRequiredDefaultDescription
fieldYField containing the value to check
case_sensitiveNfalseWhen true, comparisons are case-sensitive
descriptionNExplanatory note
disabledNfalseWhen true, processor is skipped
ifNCondition to run
ignore_failureNfalseSee Handling Failures
ignore_missingNfalseIf true and field does not exist, exit quietly
listNStatic list of values to check against
list_fieldNField containing a dynamic []string list to check against
on_failureNSee Handling Failures
on_successNSee Handling Success
partialNfalseWhen true, uses substring matching instead of exact equality
tagNIdentifier

Details

The processor checks whether the string value of field appears in a list of candidate values. The list is provided via list (static values defined inline) or list_field (a []string field in the log entry). If both are set, list_field takes precedence. At least one must be specified; otherwise the processor fails with "no member specified".

By default, comparison is exact equality and case-insensitive. Set case_sensitive: true for exact-case matching.

When partial is true, the check changes from exact equality to bidirectional substring matching: the processor succeeds if the field value contains any list member as a substring, or if any list member contains the field value as a substring.

List values support template syntax ({{{field_name}}}), allowing dynamic values constructed from other fields in the log entry.

note

For pattern-based matching (substring or regex) against a single value rather than a list, see Matches.

Examples

Static List

Check if a value exists in a static list...

{
"status": "active"
}
- contains:
field: status
list: ["active", "pending", "completed"]

returns success because "active" is in the list

Dynamic List

Check against a list stored in another field...

{
"user_type": "admin",
"allowed_types": ["user", "moderator", "admin"]
}
- contains:
field: user_type
list_field: allowed_types

returns success because "admin" is in allowed_types

Missing Fields

When the field is missing and ignore_missing is true...

{
"other_field": "value"
}
- contains:
field: status
list: ["active", "pending"]
ignore_missing: true

processor exits quietly without modification

Partial Match

Checking if a field value contains any list member as a substring...

{
"event_type": "user.login.success"
}
- contains:
field: event_type
list: ["login", "logout"]
partial: true

returns success because "user.login.success" contains "login"

Case Sensitive

Requiring exact case when checking against a list...

{
"severity": "WARNING"
}
- contains:
field: severity
list: ["warning", "error", "critical"]
case_sensitive: true

returns no match because "WARNING" does not equal "warning" in case-sensitive mode

Templates

List values can use template syntax...

{
"org_id": "123",
"role": "role_123_admin"
}
- contains:
field: role
list: ["role_{{{org_id}}}_admin", "role_{{{org_id}}}_user"]

templates are evaluated before checking