Skip to main content
In this lesson we continue the OpenTelemetry Transformation Language (OTTL) demo by focusing on the transform processor. Instead of filtering, we’ll apply transformations to telemetry signals — primarily traces — to set or modify attributes on resources, spans, and span events. Start by replacing or commenting out any previous filter processor configuration and enable the transform processor in your Collector configuration. A minimal OpenTelemetry Collector snippet to enable the processor looks like this:
Example debug output from the agent (trimmed for clarity):
Local test runs (example; reduced duplicates):

​
Transform processor basics

The transform processor executes OTTL statements to modify signals. It supports an error_mode option that controls behavior when a statement errors.
Setting error_mode: ignore prevents a single statement failure from stopping processing of the signal. This is useful for experimentation or when applying many optional transformations.
Transform rules are scoped by signal type. Use the appropriate statements block per signal:
  • Traces: trace_statements
  • Metrics: metric_statements
  • Logs: log_statements
This guide focuses on traces. A minimal traces configuration:
A typical service pipeline wiring the transform processor looks like this:

​
Contexts available in OTTL

OTTL exposes contexts that map to parts of a telemetry signal. Use the appropriate context for what you want to modify. Each context has different available fields you can read and modify. For traces, choose resource, span, or spanevent as needed.

​
Example: Set a resource attribute

Add a platform resource attribute to all traces using the resource context.
With the Collector wired to the debug exporter, you should see platform: Str(kubernetes) in resource attributes for incoming traces (trimmed):
In production, avoid applying broad resource or span changes to all signals. Scope transformations to only the resources or spans that need modification to reduce risk of unintended side effects.

​
Example: Add an attribute to a span

To set an attribute on spans, use the span context:
Debug output showing the new span attribute:

​
Span events: add attributes to events

Ensure your instrumentation emits span events. Example Python snippet that sets span attributes and adds an event:
OTTL rule to set an attribute on all span events:
Debug output showing an event with the new event attribute:

​
Conditional statements: restrict statements to specific spans

Avoid modifying every span by using where clauses to apply statements conditionally. Example: add an attribute only to spans with name == "process payment".
You can also check attribute existence before applying a change (useful for optional attributes):
Match on a specific attribute value:

​
Use the conditions block to avoid repeating where

When multiple statements share the same condition, group them under conditions for readability and maintainability.
All statements under a context with conditions are executed only when the condition(s) evaluate to true.

​
Best practices and summary

  • Use the transform processor to modify resource, span, and span event data where necessary.
  • Choose the appropriate context (resource, span, spanevent) for targeted changes.
  • Prefer scoped transformations using where or conditions rather than global modifications.
  • Use error_mode to control how statement errors are handled while testing or in production.
  • Test with a debug exporter to verify expected output before deploying changes.
This lesson covered basic set operations and scoping with contexts and conditions. OTTL supports more advanced expressions and transformations for complex use cases.

Watch Video