Redacting Sensitive Attributes Before They Leave Your OpenTelemetry Collector

Sensitive data in telemetry is harder to remove after it ships

Your application instruments HTTP requests and automatically captures headers, query parameters, and user identifiers as span attributes. That is useful for debugging, but it also means email addresses, phone numbers, or payment card fragments can flow straight into your observability backend. Once the data lands in the backend, removing it is difficult and often irreversible. The practical takeaway is that you can redact those attributes inside the OpenTelemetry Collector before export, without changing application code.

The OpenTelemetry Collector is a standalone component that receives telemetry from instrumented services, processes it, and sends it to one or more backends. A span is a named unit of work in a trace, and attributes are key-value pairs attached to spans, logs, or metrics. The Collector pipeline is the ordered path from receiver through processors to exporter. The attributes processor can delete, insert, or hash those key-value pairs as data moves through that pipeline.

Configuration example: deny known sensitive keys

This configuration drops email, phone, and card-number attributes from spans and logs before they reach the exporter. It also hashes user_id so the value can still be used for grouping without exposing the raw identifier. The deny behavior comes from listing keys under the delete action.

receivers:
  otlp:
    protocols:
      grpc:

processors:
  attributes/redact_pii:
    actions:
      - action: delete
        key: email
      - action: delete
        key: phone
      - action: delete
        key: card_number
      - action: hash
        key: user_id
        salt: CHANGE_ME_TO_A_STRONG_RANDOM_VALUE

exporters:
  otlp:
    endpoint: localhost:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/redact_pii]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [attributes/redact_pii]
      exporters: [otlp]

Save this file as collector-config.yaml on the host running the Collector. The delete actions remove the listed attributes entirely. The hash action replaces the value of user_id with a SHA256 digest, which is a one-way hash function, using the provided salt. A salt is a random string added to the input before hashing. Hashing preserves cardinality—you can still group traces by the same user—but it is not encryption. Low-entropy values such as phone numbers can be reversed with enough effort, so prefer deletion for high-risk fields.

Validate and verify before restarting

Run the Collector configuration validator from the host where the Collector runs:

otelcol config validate --config=/etc/otelcol/collector-config.yaml

Where to run: the Collector host or a machine with the otelcol binary installed. Permissions: read access to the config file. Expected check: the command exits with no validation errors. Risk: none; validation does not change state.

Check the Collector version because processor behavior and field names can differ between contrib releases, which are community-maintained builds of Collector components:

otelcol --version

Compare the output against the release notes for the attributes processor in your installed version. Then restart the Collector and send a test trace that includes email, phone, and user_id attributes. Before enabling the processor, the exported span contains those keys. After enabling it, the email, phone, and card_number keys are absent while the trace ID and span structure remain intact. Use the same trace ID for the before-and-after comparison so you can confirm redaction did not break trace context. The Collector debug exporter can help you inspect output locally before pointing the pipeline at your production backend.

Trade-offs and limitations

• Deletion is irreversible. If you delete an attribute and later realize you needed it for debugging, the original value is gone unless you retain an unprocessed copy elsewhere.
• The processor only sees data passing through the Collector. Instrumented services that export directly to a backend bypass it entirely.
• Hashing is not encryption. Do not rely on it to satisfy encryption requirements for sensitive data.
• Configuration keys and supported actions vary by Collector version. Verify against your deployed release rather than assuming behavior from documentation for a different version.

Practical closing step

Start with a deny list on non-production traffic. Verify with the same trace ID before and after, then promote to production only after confirming no required attributes are missing. If a dashboard breaks because a needed attribute disappeared, restore the previous Collector config and restart. Treat the Collector as one layer in your PII strategy, not a substitute for avoiding sensitive data in instrumentation at the source.