You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Offering **169+** processors, **DataStream** has the most comprehensive support in the industry for _low-code_/_no-code_ management, enabling tasks like parsing, filtering, enrichment, schema transformation, normalization, routing, and more. Engineers with **Elastic** experience can leverage this robust and flexible pipeline engine while benefiting from extended multi-platform capabilities.
138
+
Offering **174+** processors, **DataStream** has the most comprehensive support in the industry for _low-code_/_no-code_ management, enabling tasks like parsing, filtering, enrichment, schema transformation, normalization, routing, and more. Engineers with **Elastic** experience can leverage this robust and flexible pipeline engine while benefiting from extended multi-platform capabilities.
Halts the remaining processors in the current pipeline chain and forwards the log entry to its target without further processing, similar to a `break` statement in programming languages.
15
+
16
+
## Schema
17
+
18
+
```yaml
19
+
- break:
20
+
description: <text>
21
+
if: <script>
22
+
ignore_failure: <boolean>
23
+
on_failure: <processor[]>
24
+
on_success: <processor[]>
25
+
tag: <string>
26
+
```
27
+
28
+
## Configuration
29
+
30
+
The following fields are used to define the processor:
31
+
32
+
|Field|Required|Default|Description|
33
+
|---|---|---|---|
34
+
|`description`|N||Explanatory note|
35
+
|`if`|N||Condition to run|
36
+
|`ignore_failure`|N|`false`|Continue processing if operation fails|
The `break` processor stops execution of all remaining processors in the current pipeline chain. The log entry is not dropped — it is forwarded to its configured target as-is, with all field values set up to the point of the break.
44
+
45
+
This processor has no required fields. When used without an `if` condition, it unconditionally halts further processing. The most common usage is with an `if` expression to conditionally exit the pipeline when specific criteria are met.
46
+
47
+
The `break` processor is classified as a finalizer: once triggered, the pipeline engine stops processing the current processor list and returns the log entry for delivery.
48
+
49
+
## Examples
50
+
51
+
### Unconditional Break
52
+
53
+
<ExampleGrid>
54
+
<CommentCol>
55
+
Halting all further processing unconditionally...
56
+
</CommentCol>
57
+
<CodeCol>
58
+
```json
59
+
{
60
+
"source": {"ip": "192.168.1.1"},
61
+
"event": {"action": "login"}
62
+
}
63
+
```
64
+
```yaml
65
+
- set:
66
+
field: processed
67
+
value: true
68
+
- break:
69
+
description: "Stop processing here"
70
+
- set:
71
+
field: should_not_appear
72
+
value: true
73
+
```
74
+
</CodeCol>
75
+
<CommentCol>
76
+
Processing stops at break; log entry is forwarded with only the fields set before break...
77
+
</CommentCol>
78
+
<CodeCol>
79
+
```json
80
+
{
81
+
"source": {"ip": "192.168.1.1"},
82
+
"event": {"action": "login"},
83
+
"processed": true
84
+
}
85
+
```
86
+
</CodeCol>
87
+
</ExampleGrid>
88
+
89
+
### Conditional Break
90
+
91
+
<ExampleGrid>
92
+
<CommentCol>
93
+
Stopping processing when packet count matches condition...
94
+
</CommentCol>
95
+
<CodeCol>
96
+
```json
97
+
{
98
+
"source": {"packets": 10},
99
+
"network": {"protocol": "tcp"}
100
+
}
101
+
```
102
+
```yaml
103
+
- set:
104
+
field: initial_check
105
+
value: true
106
+
- break:
107
+
if: "ctx.source.packets == 10"
108
+
description: "Exit early for 10-packet events"
109
+
- geo_ip:
110
+
field: source.ip
111
+
target: source.geo
112
+
- threat_intel:
113
+
field: source.ip
114
+
```
115
+
</CodeCol>
116
+
<CommentCol>
117
+
Pipeline halts when condition is met; expensive enrichment processors are skipped...
118
+
</CommentCol>
119
+
<CodeCol>
120
+
```json
121
+
{
122
+
"source": {"packets": 10},
123
+
"network": {"protocol": "tcp"},
124
+
"initial_check": true
125
+
}
126
+
```
127
+
</CodeCol>
128
+
</ExampleGrid>
129
+
130
+
### Break with `on_success` Notification
131
+
132
+
<ExampleGrid>
133
+
<CommentCol>
134
+
Marking the log entry before breaking out of the pipeline...
135
+
</CommentCol>
136
+
<CodeCol>
137
+
```json
138
+
{
139
+
"event": {"type": "heartbeat"},
140
+
"host": {"name": "monitor-01"}
141
+
}
142
+
```
143
+
```yaml
144
+
- break:
145
+
if: "ctx.event.type == 'heartbeat'"
146
+
description: "Skip enrichment for heartbeat events"
147
+
on_success:
148
+
- set:
149
+
field: pipeline.skipped
150
+
value: true
151
+
- enrich:
152
+
field: host.name
153
+
target: host.details
154
+
```
155
+
</CodeCol>
156
+
<CommentCol>
157
+
Heartbeat events exit early with the skip marker set; non-heartbeat events proceed to enrichment...
|`partial`|N|`false`|When `true`, uses substring matching instead of exact equality|
53
+
|`tag`|N||Identifier|
48
54
49
-
# Details
55
+
## Details
50
56
51
-
The list can be provided directly or referenced from another field.
57
+
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".
52
58
53
-
:::warning
54
-
Either `list` or `list_field` must be specified, but not both, and the field being checked must contain a string value. The processor will fail if neither `list` nor `list_field` is provided, or if the specified field contains a non-string value.
59
+
By default, comparison is **exact equality** and **case-insensitive**. Set `case_sensitive: true` for exact-case matching.
60
+
61
+
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.
62
+
63
+
List values support template syntax (`{{{field_name}}}`), allowing dynamic values constructed from other fields in the log entry.
64
+
65
+
:::note
66
+
For pattern-based matching (substring or regex) against a single value rather than a list, see <Topic id="processors-matches">Matches</Topic>.
55
67
:::
56
68
57
69
## Examples
@@ -127,6 +139,54 @@ Either `list` or `list_field` must be specified, but not both, and the field bei
127
139
</CommentCol>
128
140
</ExampleGrid>
129
141
142
+
### Partial Match
143
+
144
+
<ExampleGrid>
145
+
<CommentCol>
146
+
Checking if a field value contains any list member as a substring...
147
+
</CommentCol>
148
+
<CodeCol>
149
+
```json
150
+
{
151
+
"event_type": "user.login.success"
152
+
}
153
+
```
154
+
```yaml
155
+
- contains:
156
+
field: event_type
157
+
list: ["login", "logout"]
158
+
partial: true
159
+
```
160
+
</CodeCol>
161
+
<CommentCol>
162
+
returns success because `"user.login.success"` contains `"login"`
163
+
</CommentCol>
164
+
</ExampleGrid>
165
+
166
+
### Case Sensitive
167
+
168
+
<ExampleGrid>
169
+
<CommentCol>
170
+
Requiring exact case when checking against a list...
171
+
</CommentCol>
172
+
<CodeCol>
173
+
```json
174
+
{
175
+
"severity": "WARNING"
176
+
}
177
+
```
178
+
```yaml
179
+
- contains:
180
+
field: severity
181
+
list: ["warning", "error", "critical"]
182
+
case_sensitive: true
183
+
```
184
+
</CodeCol>
185
+
<CommentCol>
186
+
returns no match because `"WARNING"` does not equal `"warning"` in case-sensitive mode
0 commit comments