Loading

Attributes processor

Serverless Observability Stack EDOT Collector

The attributes processor modifies telemetry attributes as they pass through the Elastic Distribution of OpenTelemetry Collector pipeline. It can add, update, rename, hash, or delete attributes on spans, metrics, and logs before they reach downstream processors or exporters.

This processor is part of the core Elastic Distribution of OpenTelemetry Collector distribution. It is useful when you need to normalize attribute names, remove sensitive fields, or enrich telemetry with additional context.

For full contrib details, refer to the OpenTelemetry attributesprocessor documentation.

The attributes processor applies a list of actions to matching telemetry. Each action defines:

  • Action type (such as insert, update, delete, hash, or rename)
  • Target attribute key
  • Optional value (for inserts/updates)
  • Optional include/exclude match criteria

Actions run in order. Matching rules give fine-grained control over which spans, metrics, or logs the processor modifies.

The attributes processor is commonly used in Elastic Observability pipelines to:

  • Remove or transform sensitive attributes. For example, deleting user email fields or hashing IP addresses before they are exported.

  • Normalize attribute naming across services. For example, converting custom key names (such as "userId") to standard semantic conventions ("user.id").

  • Add static attributes, such as environment or cluster identifiers when they cannot be set at the source.

  • Clean up noisy or irrelevant attributes. For example, removing temporary or dynamically generated labels that would otherwise create high-cardinality fields in Elasticsearch.

  • Override or enrich resource attributes for standardizing deployment names, namespaces, or service metadata.

The following are the most important settings when configuring the attributes processor:

Option Description
actions A list of attribute modifications to apply. Each action uses the upstream-supported action types: insert, update, upsert, delete, hash, extract, convert, rename, truncate.
include / exclude Rules for matching telemetry based on service name, span name, resource attributes, log severity, or metric name.
match_type How attribute comparison is evaluated (strict, regexp, expr).

For the complete list of configuration options and action-specific settings, refer to the contrib attributesprocessor documentation.

The following example deletes a sensitive attribute, renames an attribute, inserts a cluster ID, and hashes an IP address before export:

processors:
  attributes:
    actions:
      - key: user.email
        action: delete

      - key: userId
        action: rename
        new_key: user.id

      - key: cluster.id
        action: insert
        value: my-observability-cluster

      - key: client.ip
        action: hash
		

To enable the processor in a Elastic Distribution of OpenTelemetry Collector pipeline:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes]
      exporters: [elastic]
		

Remove sensitive data from log attributes before export to comply with privacy regulations or security policies:

processors:
  attributes:
    actions:
      # Delete sensitive fields - illustrative example (not real values)
      - key: user.password
        action: delete
      - key: credit_card.number
        action: delete
      - key: ssn
        action: delete

      # Hash IP addresses for privacy
      - key: client.ip
        action: hash
      - key: server.ip
        action: hash

      # Remove authorization headers from HTTP spans
      - key: http.request.header.authorization
        action: delete
      - key: http.request.header.cookie
        action: delete
		

Standardize attribute naming across different services that use inconsistent conventions:

processors:
  attributes:
    actions:
      # Normalize user ID attributes
      - key: userId
        action: rename
        new_key: user.id
      - key: user_id
        action: rename
        new_key: user.id
      - key: UserID
        action: rename
        new_key: user.id

      # Normalize environment attributes
      - key: env
        action: rename
        new_key: deployment.environment
      - key: environment
        action: rename
        new_key: deployment.environment

      # Convert custom service names to semantic conventions
      - key: app.name
        action: rename
        new_key: service.name
		

Enrich telemetry with environment-specific attributes based on service or resource attributes:

processors:
  attributes:
    # Add cluster ID to all telemetry from production namespace
    include:
      match_type: strict
      resource_attributes:
        - key: k8s.namespace.name
          value: production
    actions:
      - key: cluster.id
        action: insert
        value: prod-cluster-01
      - key: environment
        action: insert
        value: production
      - key: region
        action: insert
        value: us-east-1
		

You can limit attribute modifications to only specific spans, logs, or metrics using include and exclude blocks:

processors:
  attributes:
    include:
      match_type: strict
      services: ["checkout-service"]
    actions:
      - key: http.request.header.authorization
        action: delete
		

This example removes an authorization header only from telemetry produced by the checkout-service.

Note

Deleting keys like http.request.header.authorization only works if the key exists as a flattened attribute. Some SDKs store headers inside structured maps, which are not supported by the attributes processor.

When using the attributes processor, keep these recommendations and constraints in mind:

  • Plan action order carefully. Actions run sequentially, so a delete followed by an update on the same key will behave differently than the reverse order. Consider the sequence of operations when designing your attribute transformations.

  • Use include and exclude filters to target specific telemetry. Instead of applying actions to all telemetry, limit modifications to specific services, spans, or metrics. This reduces processing overhead and prevents unintended side effects.

  • Be cautious with dynamic attribute insertion. Inserting dynamically changing attributes can significantly increase cardinality in Elasticsearch, leading to performance issues and increased storage costs. Use static values or carefully controlled dynamic values to avoid high-cardinality issues.

  • Consider downstream processor dependencies when renaming attributes. If later processors in your pipeline rely on specific attribute keys (for example, service.name), renaming those attributes can cause failures or unexpected behavior. Review your pipeline configuration to understand attribute dependencies.

  • Understand that hashing is irreversible. Once hashed, attribute values cannot be retrieved or correlated using their original value. Use hashing for sensitive data that doesn't need to be queried or correlated later.