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
Copy file name to clipboardExpand all lines: pipeline/processors/content-modifier.md
+50-40Lines changed: 50 additions & 40 deletions
Original file line number
Diff line number
Diff line change
@@ -1,66 +1,76 @@
1
-
# Content Modifier
1
+
# Content modifier
2
2
3
-
The **content_modifier**processor allows you to manipulate the messages, metadata/attributes and content of Logs and Traces.
3
+
The _content modifier_processor lets you manipulate the content, metadata, and attributes of logs and traces.
4
4
5
-
Similar to the functionality exposed by filters, this processor presents a unified mechanism to perform such operations for data manipulation. The most significant difference is that processors perform better than filters, and when chaining them, there are no encoding/decoding performance penalties.
5
+
Similar to how filters work, this processor uses a unified mechanism to perform operations for data manipulation. The most significant difference is that processors perform better than filters, and when chaining them, there are no encoding/decoding performance penalties.
6
6
7
7
{% hint style="info" %}
8
8
9
-
**Note:** Both processors and this specific component can be enabled only by using
10
-
the YAML configuration format. Classic mode configuration format doesn't support processors.
9
+
Only [YAML configuration files](../administration/configuring-fluent-bit/yaml/README.md) support processors.
11
10
12
11
{% endhint %}
13
12
14
13
## Contexts
15
14
16
-
The processor, works on top of what we call a __context__, meaning _the place_ where the content modification will happen. We provide different contexts to manipulate the desired information, the following contexts are available:
15
+
The content modifier relies on _context_, meaning the place where the content modification will happen. Fluent Bit provides different contexts to manipulate the desired information.
17
16
18
-
| Context Name | Signal | Description |
19
-
| -- | -- | -- |
20
-
|`attributes`| Logs | Modify the attributes or metadata of a Log record. |
21
-
|`body`| Logs | Modify the content of a Log record. |
22
-
|`span_name`| Traces | Modify the name of a Span. |
23
-
|`span_kind`| Traces | Modify the kind of a Span. |
24
-
|`span_status`| Traces | Modify the status of a Span. |
25
-
|`span_attributes`| Traces | Modify the attributes of a Span. |
17
+
The following contexts are available:
26
18
19
+
| Name | Telemetry type | Description |
20
+
| ---- | -------------- | ----------- |
21
+
|`attributes`| Logs | Modifies the attributes or metadata of a log record. |
22
+
|`body`| Logs | Modifies the content of a log record. |
23
+
|`span_name`| Traces | Modifies the name of a span. |
24
+
|`span_kind`| Traces | Modifies the kind of a span. |
25
+
|`span_status`| Traces | Modifies the status of a span. |
26
+
|`span_attributes`| Traces | Modifies the attributes of a span. |
27
27
28
-
### OpenTelemetry Contexts
29
28
30
-
In addition, we provide special contexts to operate on data that follows an __OpenTelemetry Log Schema__, all of them operates on shared data across a group of records:
29
+
### OpenTelemetry contexts
31
30
32
-
| Context Name | Signal | Description |
33
-
| -- | -- | -- |
34
-
|`otel_resource_attributes`| Logs | Modify the attributes of the Log Resource. |
35
-
|`otel_scope_name`| Logs | Modify the name of a Log Scope. |
36
-
|`otel_scope_version`| Logs | Modify version of a Log Scope. |
37
-
|`otel_scope_attributes`| Logs | Modify the attributes of a Log Scope. |
31
+
Additionally, Fluent Bit provides specific contexts for modifying data that follows the OpenTelemetry log schema. All of these contexts operate on shared data across a group of records.
38
32
39
-
> TIP: if your data is not following the OpenTelemetry Log Schema and your backend or destination for your logs expects to be in an OpenTelemetry schema, take a look at the processor called OpenTelemetry Envelope that you can use in conjunbction with this processor to transform your data to be compatible with OpenTelemetry Log schema.
33
+
The following contexts are available:
40
34
41
-
## Configuration Parameters
35
+
| Name | Telemetry type | Description |
36
+
| ---- | -------------- | ----------- |
37
+
|`otel_resource_attributes`| Logs | Modifies the attributes of the log resource. |
38
+
|`otel_scope_name`| Logs | Modifies the name of a log scope. |
39
+
|`otel_scope_version`| Logs | Modifies version of a log scope. |
40
+
|`otel_scope_attributes`| Logs | Modifies the attributes of a log scope. |
41
+
42
+
43
+
{% hint style="info" %}
44
+
45
+
If your data doesn't follow the OpenTelemetry log schema, but your log destination expects to be in that format, you can use the [OpenTelemetry envelope](../pipeline/processors/opentelemetry-envelope) processor to transform your data. You can then pass that transformed data through the content modifier filter and use OpenTelemetry contexts accordingly.
46
+
47
+
{% endhint %}
48
+
49
+
## Configuration parameters
50
+
51
+
The following configuration parameters are available:
42
52
43
53
| Key | Description |
44
-
|:---------- |:--- |
45
-
| context |Specify the context where the modifications will happen (more details above).The following contexts are available: `attributes`, `body`, `span_name`, `span_kind`, `span_status`, `span_attributes`, `otel_resource_attributes`, `otel_scope_name`, `otel_scope_version`, `otel_scope_attributes`. |
46
-
| key |Specify the name of the key that will be used to apply the modification. |
47
-
|value | Based on the action type, `value`might required and represent different things. Check the detailed information for the specific actions. |
48
-
| pattern | Defines a regular expression pattern. This property is only used by the `extract` action. |
49
-
| converted_type |Define the data type to perform the conversion, the available options are: `string`, `boolean`, `int` and `double`. |
54
+
| -----------|----------- |
55
+
|`context`|Specifies the [context](#contexts) where the modifications will happen. |
56
+
|`key`|Specifies the name of the key that will be used to apply the modification. |
57
+
|`value`| The role of this parameter changes based on the [action](#actions) type. |
58
+
|`pattern`| Defines a regular expression pattern. This property is only used by the `extract`[action](#actions). |
59
+
|`converted_type`|Defines the data type to perform the conversion. Possible values: `string`, `boolean`, `int` and `double`. |
50
60
51
61
### Actions
52
62
53
-
The actions specify the type of operation to run on top of a specific key or content from a Log or a Trace. The following actions are available:
63
+
The actions specify the type of operation to run on top of a specific key or content from a log or a trace. The following actions are available:
|`insert`|Insert a new key with a value into the target context. The `key` and `value` parameters are required. |
58
-
|`upsert`| Given a specific key with a value, the `upsert` operation will try to update the value of the key. If the key does not exist, the key will be created. The `key` and `value` parameters are required. |
59
-
|`delete`|Delete a key from the target context. The `key` parameter is required. |
60
-
|`rename`|Change the name of a key. The `value` set in the configuration will represent the new name. The `key` and `value` parameters are required. |
61
-
|`hash`|Replace the key value with a hash generated by the SHA-256 algorithm, the binary value generated is finally set as an hex string representation. The `key` parameter is required. |
62
-
|`extract`|Allows to extact the value of a single key as a list of key/value pairs. This action needs the configuration of a regular expression in the `pattern` property. The `key` and `pattern` parameters are required. For more details check the examples below. |
63
-
|`convert`|Convert the data type of a key value. The `key` and `converted_type` parameters are required. |
67
+
|`insert`|Inserts a new key with a value into the target context. The `key` and `value` parameters are required. |
68
+
|`upsert`| Given a specific key with a value, the `upsert` operation will try to update the value of the key. If the key does not exist, a new key will be created. The `key` and `value` parameters are required. |
69
+
|`delete`|Deletes a key from the target context. The `key` parameter is required. |
70
+
|`rename`|Changes the name of a key. The `value` set in the configuration will represent the new name. The `key` and `value` parameters are required. |
71
+
|`hash`|Replaces the key value with a hash generated by the SHA-256 algorithm, the binary value generated is finally set as a hex string representation. The `key` parameter is required. |
72
+
|`extract`|Extracts the value of a single key as a list of key/value pairs. This action needs the configuration of a regular expression in the `pattern` property. The `key` and `pattern` parameters are required. |
73
+
|`convert`|Converts the data type of a key value. The `key` and `converted_type` parameters are required. |
0 commit comments