Opentelemetry Ottl

OTTL

OpenTelemetry Transformation Language (OTTL) transforms, filters, and routes telemetry inside an OTel Collector pipeline without modifying application code. Load this skill when writing or debugging OTTL statements in the transform processor, filter processor, or routing connector.

When to Use This Skill

Reference material for each topic lives under references/ and is listed in the References footer at the bottom of this file. When the question involves a specific processor, context, or function you have not recently reviewed — or when the user pastes a Collector error — consult the matching reference file before answering. One or two targeted reads beat guessing from memory.

Key Concepts

Contexts and path expressions

context: determines what attributes means. In context: resource, attributes["k"] is a resource attribute. In context: log or context: span, attributes["k"] is the record-level attribute — use resource.attributes["k"] to reach the resource. Wrong context = silent nil, no error. → references/contexts.md

Metric-level edits (name, description, unit) belong in context: metric; per-series label/attribute edits belong in context: datapoint. Mixing the two in one block means one of them silently no-ops. → references/contexts.md

Log event timestamps can be changed in context: log by setting time with Time(...) or time_unix_nano with an integer nanosecond value. Span status checks belong in context: span; prefer STATUS_CODE_ERROR, STATUS_CODE_OK, and STATUS_CODE_UNSET over raw numeric comparisons. → references/transformations.md

Error modes

Set error_mode explicitly on every transform and filter processor — the default (propagate) halts the whole pipeline on the first runtime error (missing optional field, wrong type, indexing a nil), silently dropping every subsequent record. The fix for a pipeline that "goes silent after one failure" is almost always the missing error_mode key:

processors:
  transform:
    error_mode: ignore          # log, skip the statement, continue the pipeline
    log_statements:
      - context: log
        statements:
          - set(attributes["env"], resource.attributes["deployment.environment"])

Error patterns

Map the Collector message to a root cause before proposing a fix:

Canonical pipeline shape

Full annotated example of a transform + filter pipeline (log/trace/metric statements, error_mode, conditions: [IsMap(body)], filter-before-transform ordering) lives in references/processors.md.

Common Workflows

1. Debug an OTTL statement

1. Confirm the problem is actually OTTL — not component choice, pipeline wiring, or infrastructure.
2. Identify the signal (logs / traces / metrics) and the specific context.
3. Match the exact error text against the Error patterns table above.
4. Check for missing nil or type guards (IsMap, IsString, != nil).
5. Check for the wrong context prefix (attributes vs resource.attributes).
6. Check conditions: semantics or tail sampling policy ordering.
7. Only then propose the corrected statement and minimal YAML.

2. Promote a JSON log body to attributes

When the body arrives as a raw JSON string (IsMap(body) is false), guard with IsString(body) and parse with ParseJSON. Prefer IsString(body) over not IsMap(body) — it is the affirmative check and avoids matching empty/nil bodies.

- context: log
  conditions:
    - IsString(body)          # body is a JSON string (affirmative guard)
  statements:
    # Promote every top-level JSON field into attributes
    - merge_maps(attributes, ParseJSON(body), "insert")

    # Or lift specific fields only:
    - set(attributes["user_id"],    ParseJSON(body)["user_id"])    where ParseJSON(body)["user_id"]    != nil
    - set(attributes["request_id"], ParseJSON(body)["request_id"]) where ParseJSON(body)["request_id"] != nil

ParseJSON is a Converter — it returns a value but has no side effect of its own, so it must be wrapped in an Editor (set, merge_maps). A standalone ParseJSON(body) line loads without errors and does nothing. → references/transformations.md

3. Reduce metric cardinality

- context: datapoint
  statements:
    - keep_keys(attributes, ["service.name", "http.route", "http.response.status_code"])
    - delete_matching_keys(attributes, "^k8s\\.pod\\.uid$")

Prefer keep_keys (allowlist) over many delete_key calls (blocklist). → references/cardinality.md

4. Feed an exporter that reads resource attributes

Exporters that pick a destination from attributes — most notably the Coralogix exporter's application_name_attributes and subsystem_name_attributes — read from resource attributes, not log-record or span attributes. If the source value lives on the record, copy it up to the resource from context: log (or context: span) with set(resource.attributes[...], attributes[...]). Don't rename the field in the application and don't change the exporter config.

Full pattern (both attribute pairs, error_mode, and pipeline ordering) is in → references/contexts.md.

5. Extract histogram aggregations and drop the source metric

To keep _sum and _count for average latency calculations while dropping raw bucket data:

processors:
  transform:
    error_mode: ignore
    metric_statements:
      - context: metric
        conditions:
          - type == METRIC_DATA_TYPE_HISTOGRAM
        statements:
          - extract_sum_metric(true)    # creates <name>_sum as a new Sum metric; true = monotonic
          - extract_count_metric(true)  # creates <name>_count as a new Counter metric
  filter:
    error_mode: ignore
    metrics:
      metric:
        - 'type == METRIC_DATA_TYPE_HISTOGRAM and name == "http.server.request.duration"'

extract_sum_metric(monotonic) and extract_count_metric(monotonic) are OTTL Editor functions that run in context: metric and append new standalone metrics to the pipeline output — the original histogram is still present until the filter processor drops it. The transform processor must come before filter in the pipeline so the new metrics exist before the histogram is removed. Pass true for cumulative/monotonic counters, false for delta.

6. Redact PII across attributes

- context: log
  statements:
    - set(attributes["user.id"], SHA256(attributes["user.id"])) where attributes["user.id"] != nil
    - replace_all_patterns(attributes, "value", "(?i)bearer\\s+[a-z0-9._-]+", "bearer ***")

SHA256 preserves correlation without exposing the raw identifier. replace_all_patterns redacts across every attribute value without listing each key. → references/redaction.md

Best Practices

Pipeline and ordering

1. Filter before transform. Don't spend CPU transforming records that will be dropped.
2. Set error_mode: ignore explicitly. The default propagate causes data loss on any runtime error.
3. Use conditions: to scope a block. Statements run when any listed condition matches (OR semantics) — cheaper than a where clause on every statement. For strict AND, combine with a and b or use per-statement where.

Defensive OTTL

1. Guard before indexing. IsMap(body) before map access, IsString(body) before string operations, where attributes["x"] != nil before reading optional fields. An unguarded indexing into the wrong type raises INVALID_ARGUMENT and (with the default error_mode) halts the pipeline.
2. Convert numeric-looking strings before comparing. If an attribute can be "5" or 5, branch with IsString / IsInt and use Int(...) or Double(...) before > / < comparisons.
3. conditions: is OR, not AND. For strict AND, combine into one boolean (a and b) or add where on each statement.

Authoring style

1. Identify signal and context first. Keep traces, metrics, and logs separate; use the context that matches the referenced fields.
2. Prefer several short statements over one dense expression. Show exact path prefixes when clarity matters.
3. Prefer keep_keys over many delete_key calls. An allowlist is shorter and self-documenting.

Limitations

OTTL is not the fix for: receiver connectivity, exporter connectivity, DNS or Kubernetes service discovery, load balancing, gateway reachability, pipeline wiring mistakes, or telemetry that never reaches the processor. Say so before going further.

Scope fences:

• OTTL can only use fields exposed in the active signal and context model.
• The Collector sees telemetry payloads, not raw incoming requests — upstream HTTP headers are usually not available after receiver ingest.
• If a field is not in the active context, OTTL cannot infer or reconstruct it.

The OTTL function list evolves each Collector release. This skill covers patterns and common misuses — for current function signatures, consult the upstream docs in the References footer below.

References

• references/contexts.md — OTTL contexts, path expressions, and the most common context mistakes
• references/processors.md — transform, filter, and routing connector configuration
• references/filtering.md — Dropping logs, metrics, and spans with the filter processor
• references/transformations.md — Span naming, semconv migration, body operations, ParseJSON, fallback chains
• references/cardinality.md — Reducing metric and trace cardinality with keep_keys, delete_matching_keys, replace_pattern
• references/redaction.md — PII masking, SHA256 pseudonymization, token/card/auth header redaction

Upstream:

• OTTL language spec
• ottlfuncs reference
• transform processor
• filter processor