Edge Delta Deotel Processor
6 minute read
Overview
The Deotel (De-OpenTelemetry) processor extracts the core content from OpenTelemetry formatted telemetry data, removing all OTLP wrapper metadata. It takes a specified field (typically body
) from the OpenTelemetry structure and outputs only that field’s content, discarding resource attributes, trace context, and other metadata.
The Deotel processor is ideal for:
- Sending logs to legacy systems that don’t support OTLP format
- Forwarding data to custom applications in their original format
- Reducing data size by removing OpenTelemetry metadata
Do not use the Deotel processor when:
- Your destination supports OpenTelemetry/OTLP format
- You need trace context for distributed tracing
- You need resource metadata for infrastructure correlation
- Your downstream system benefits from OpenTelemetry semantic conventions
Data Loss
The Deotel processor permanently removes OpenTelemetry metadata including:
- Trace context (trace_id, span_id) for distributed tracing
- Resource attributes (service name, host information, Kubernetes metadata)
- Semantic conventions and standardized field names
- Timestamp information from the OTLP wrapper
If you need to preserve some OpenTelemetry metadata in the output, use OTTL Transform before Deotel to merge important fields into the body or whichever field you configure the deotel processor to preserve:
processors:
- type: ottl_transform
statements: |
set(body_map, ParseJSON(body))
set(body_map["service"], resource["service.name"])
set(body_map["pod"], resource["k8s.pod.name"])
set(body, String(body_map))
Configuration
You configure the Deotel processor by specifying which field to extract and preserve from the OpenTelemetry structure. The processor removes all other fields and outputs only the extracted content.
Example Input
Suppose the following OpenTelemetry formatted log is sent to the Deotel processor:
{
"_type": "log",
"timestamp": 1755065085076,
"body": "{\"timestamp\":\"2025-08-13T06:04:44+00:00\",\"level\":\"INFO\",\"message\":\"Test log 4\",\"service\":\"test-service\",\"trace_id\":\"trace-4\"}",
"resource": {
"container.id": "123456789",
"container.image.name": "docker.io/library/123456:latest",
"ed.domain": "k8s",
"ed.filepath": "/var/log/pods/busy_test-deotel_123456789/test-deotel/0.log",
"ed.source.name": "kubernetes_input_50df",
"ed.source.type": "kubernetes_input",
"host.ip": "172.19.0.2",
"host.name": "ed-api-testbench-control-plane",
"k8s.container.name": "test-deotel",
"k8s.namespace.name": "busy",
"k8s.node.name": "ed-api-testbench-control-plane",
"k8s.pod.name": "test-deotel",
"k8s.pod.uid": "123456789",
"service.name": "Unknown"
},
"attributes": {
"level": "INFO",
"message": "Test log 4",
"service": "test-service",
"timestamp": "2025-08-13T06:04:44+00:00",
"trace_id": "trace-4"
}
}

This configuration extracts only the body field:
- name: deotel_processor
type: sequence
processors:
- type: deotel
metadata: '{"id":"unique_id","type":"deotel","name":"Deotel"}'
data_types:
- log
field_path: body
Example Output
The processor outputs only the content of the body field:
{"timestamp":"2025-08-13T06:04:44+00:00","level":"INFO","message":"Test log 4","service":"test-service","trace_id":"trace-4"}
Note how the Deotel processor:
- Extracted only the
body
field content - Removed all resource attributes (container, Kubernetes, host information)
- Removed the attributes object
- Removed timestamp and _type fields
- Output the original log format without any OpenTelemetry wrapper
Options
condition
The condition
parameter contains a conditional phrase of an OTTL statement. It restricts operation of the processor to only data items where the condition is met. Those data items that do not match the condition are passed without processing. You configure it in the interface and an OTTL condition is generated. It is optional.
Important: All conditions must be written on a single line in YAML. Multi-line conditions are not supported.
Comparison Operators
Operator | Name | Description | Example |
---|---|---|---|
== |
Equal to | Returns true if both values are exactly the same |
attributes["status"] == "OK" |
!= |
Not equal to | Returns true if the values are not the same |
attributes["level"] != "debug" |
> |
Greater than | Returns true if the left value is greater than the right |
attributes["duration_ms"] > 1000 |
>= |
Greater than or equal | Returns true if the left value is greater than or equal to the right |
attributes["score"] >= 90 |
< |
Less than | Returns true if the left value is less than the right |
attributes["load"] < 0.75 |
<= |
Less than or equal | Returns true if the left value is less than or equal to the right |
attributes["retries"] <= 3 |
matches |
Regex match | Returns true if the string matches a regular expression (generates IsMatch function) |
IsMatch(attributes["name"], ".*\\.log$") |
Logical Operators
Important: Use lowercase and
, or
, not
- uppercase operators will cause errors!
Operator | Description | Example |
---|---|---|
and |
Both conditions must be true | attributes["level"] == "ERROR" and attributes["status"] >= 500 |
or |
At least one condition must be true | attributes["log_type"] == "TRAFFIC" or attributes["log_type"] == "THREAT" |
not |
Negates the condition | not regex_match(attributes["path"], "^/health") |
Functions
Function | Description | Example |
---|---|---|
regex_match |
Returns true if string matches the pattern |
regex_match(attributes["message"], "ERROR\|FATAL") |
IsMatch |
Alternative regex function (UI generates this from “matches” operator) | IsMatch(attributes["name"], ".*\\.log$") |
Field Existence Checks
Check | Description | Example |
---|---|---|
!= nil |
Field exists (not null) | attributes["user_id"] != nil |
== nil |
Field doesn’t exist | attributes["optional_field"] == nil |
!= "" |
Field is not empty string | attributes["message"] != "" |
Common Examples
- name: _multiprocessor
type: sequence
processors:
- type: <processor type>
# Simple equality check
condition: attributes["request"]["path"] == "/json/view"
- type: <processor type>
# Multiple values with OR
condition: attributes["log_type"] == "TRAFFIC" or attributes["log_type"] == "THREAT"
- type: <processor type>
# Excluding multiple values (NOT equal to multiple values)
condition: attributes["log_type"] != "TRAFFIC" and attributes["log_type"] != "THREAT"
- type: <processor type>
# Complex condition with AND/OR/NOT
condition: (attributes["level"] == "ERROR" or attributes["level"] == "FATAL") and attributes["env"] != "test"
- type: <processor type>
# Field existence and value check
condition: attributes["user_id"] != nil and attributes["user_id"] != ""
- type: <processor type>
# Regex matching using regex_match
condition: regex_match(attributes["path"], "^/api/") and not regex_match(attributes["path"], "^/api/health")
- type: <processor type>
# Regex matching using IsMatch
condition: IsMatch(attributes["message"], "ERROR|WARNING") and attributes["env"] == "production"
Common Mistakes to Avoid
# WRONG - Cannot use OR/AND with values directly
condition: attributes["log_type"] != "TRAFFIC" OR "THREAT"
# CORRECT - Must repeat the full comparison
condition: attributes["log_type"] != "TRAFFIC" and attributes["log_type"] != "THREAT"
# WRONG - Uppercase operators
condition: attributes["status"] == "error" AND attributes["level"] == "critical"
# CORRECT - Lowercase operators
condition: attributes["status"] == "error" and attributes["level"] == "critical"
# WRONG - Multi-line conditions
condition: |
attributes["level"] == "ERROR" and
attributes["status"] >= 500
# CORRECT - Single line (even if long)
condition: attributes["level"] == "ERROR" and attributes["status"] >= 500
field_path
The field to extract and preserve from the OpenTelemetry structure. Typically body
or an enriched attribute.
Final
Determines whether successfully processed data items should continue through the remaining processors in the same processor stack. If final
is set to true
, data items output by this processor are not passed to subsequent processors within the node—they are instead emitted to downstream nodes in the pipeline (e.g., a destination). Failed items are always passed to the next processor, regardless of this setting.
The UI provides a slider to configure this setting. The default is false. It is defined in YAML as follows:
- name: multiprocessor
type: sequence
processors:
- type: <processor type>
final: true
See Also
- For an overview and to understand processor sequence flow, see Processors Overview
- To learn how to configure a processor, see Configure a Processor.
- For optimization strategies, see Best Practices for Edge Delta Processors.
- If you’re new to pipelines, start with the Pipeline Quickstart Overview or learn how to Configure a Pipeline.
- Looking to understand how processors interact with sources and destinations? Visit the Pipeline Overview.