Application telemetry should not become a shadow customer database

A trace intended to explain a slow checkout can quietly become a second customer record. Request bodies, query parameters, exception messages and custom attributes may carry information that the observability team never intended to collect.

Once those values reach collectors, exporters and dashboards, they have their own access and retention paths. The original application’s privacy controls may not apply there. Telemetry therefore deserves a data inventory of its own.

Follow one request through observability

Choose a hypothetical customer support request containing synthetic markers for a name, contact detail and complaint text. Follow it through the application, instrumentation, collector, export queue and analysis interface.

Record which markers appear at each stage. Include an error response, a timeout and a retry. Diagnostic paths often capture more detail precisely when ordinary processing fails.

The aim is not to prove that every telemetry field is harmful. It is to find which content is collected, why it is needed and who can retrieve it.

OpenTelemetry’s guidance on sensitive data recommends avoiding unnecessary collection and describes controls for removing, filtering or transforming data. Start with collection choices where feasible, because a downstream filter cannot undo earlier exposure.

Give useful fields a narrow definition

Operational teams often need a route name, outcome, duration, service version and correlation reference. They may not need a raw URL containing customer input, a complete database query or the full text of a message.

Define permitted fields and values for each event type. A route template can be more appropriate than a path containing an account identifier. A structured failure code can be more useful than an exception string assembled from the original payload.

Correlation references still need care. A stable identifier can allow records about one person to be linked across systems. Limit its scope and access to the operational purpose it serves.

Avoid treating hashing as an automatic privacy solution. OpenTelemetry’s guidance notes that predictable values can remain susceptible to guessing through candidate values. A transformed field needs a reason to exist as well as a technical transformation.

Review every telemetry surface

Attribute controls are useful, but sensitive content may also appear in log bodies, event names or nested structures. Inspect what the selected processor actually handles.

The OpenTelemetry Collector redaction processor documents attribute filtering and value-redaction mechanisms. As checked on 22 October 2026, that README labels logs and metrics alpha and traces beta. Review those maturity levels, supported signals and configuration for the deployed version. Do not assume that enabling one processor removes every sensitive value from every telemetry format.

Ordering matters too. A value may be exported or copied before a later transformation runs. A debugging exporter may receive an earlier representation than the production destination.

Review sampling separately. Sampling can reduce volume, but a sampled record may still contain unnecessary personal data. It is not a substitute for defining permitted content.

Make exceptions visible and temporary

An incident investigation may require additional detail. Give that decision a named owner, limited scope and review time. Prefer targeted diagnostics over enabling full payload capture across the service.

For the support example, the team might temporarily collect an additional non-content status field for one failing integration. If access to a restricted payload is necessary, use the approved case-review path rather than expanding general telemetry by default.

Record when temporary instrumentation must be removed. Include it in the next deployment review so an emergency change does not become permanent collection.

OWASP’s logging guidance addresses sensitive log content, access controls and operational protection. Apply those controls to the analysis platform, its exports and administrative access as well as to the application.

A practical minimisation review

Before accepting the telemetry design, ask the people who use the dashboards to explain how each potentially identifying field supports a diagnosis. Remove or narrow fields that have no clear operational use.

Then verify:

• Allowed fields are enforced at appropriate collection points.
• Error and retry paths follow the same content policy.
• Collector processors cover the actual signals and structures emitted.
• Export destinations and temporary queues have known access and retention.
• Synthetic marker tests reach the final dashboards and downloadable exports.
• Temporary diagnostic changes have an owner and an end condition.

The most useful outcome is a smaller, better-defined set of operational facts. Teams can still diagnose latency and failures while avoiding a parallel store of customer conversations that no one deliberately chose to create.