A bounded decision model
The supplied material consists of related official OpenTelemetry guidance: one excerpt addresses Collector security broadly, while the other focuses on sensitive telemetry handling. This article stays within those excerpts and deliberately excludes Collector release-specific configuration syntax.
Start with an application-owned decision: identify the observability purpose, decide whether a field is necessary for it, and choose the smallest useful representation. The guidance advises minimizing collection, reconsidering whether personal data is needed, and periodically reassessing attributes.
Purpose approval, approved-field lists, grouping choices, retention, access, and escalation are proposed application policy in this framework. They are not prescribed by the cited guidance. Nothing in the table turns a processor outcome into a finding of compliance or anonymity.
Four-case sanitization decision table
| Case | Observability purpose | Sensitivity evidence | Treatment granularity | Documented Collector processor option | Residual exposure | Inference to reject | Policy owner | Bounded application-owned action |
|---|---|---|---|---|---|---|---|---|
| unnecessary named sensitive attribute | No approved purpose is recorded for the named field. | Local review marks the field as sensitive. | Remove that field, then review what remains. | Attribute processor — remove or change the named field. | Review the remaining attributes separately. | “Removing one field proves compliance.” | Telemetry data owner | Record the deletion rule and revisit it during attribute review. |
| useful telemetry with an approved attribute set and untrusted extras | Retain only fields required by the approved use. | The local allowlist identifies accepted fields; other fields are untrusted. | Keep the allowlist and remove everything outside it. | Redaction processor — delete attributes absent from an allowed list. | Allowed fields still require periodic local review. | “An allowlist alone defines every privacy obligation.” | Purpose approver and telemetry data owner | Maintain the allowlist, its purpose rationale, and an escalation path for new fields. |
| span or metric whose sensitive content makes the whole signal disallowed | No permitted use remains for this signal in its received form. | Local policy classifies the signal, not merely one field, as disallowed. | Discard the signal rather than attempting selective cleanup. | Filter processor — exclude a complete span or metric. | The required diagnostic signal is lost; reconsider instrumentation separately. | “Field-level cleanup always cures a prohibited signal.” | Security or privacy decision owner | Stop that export and document the signal-level decision and escalation route. |
| small predictable user identifier proposed for hashing | A proposed correlation use has not justified retaining the identifier. | The hypothetical identifier domain is small and foreseeable. | Do not represent the digest as anonymous; delete it or use an approved coarser grouping. | Attribute processor — remove the identifier; transformation is also a documented processing category. | A hash of a predictable value may be practically reversible. | “A hash automatically anonymizes a user.” | Privacy decision owner with the telemetry data owner | Record the risk, stop any disallowed export, then choose deletion or a locally approved grouped representation. |
The documented options differ in scope: attribute handling can alter selected fields, redaction can remove non-allowed attributes, and filtering can exclude whole telemetry items. Choosing among them remains a local decision about purpose and acceptability.
Hypothetical failure walkthrough
Suppose a team’s application exports hashes derived from numeric user identifiers, and the team labels those exported values “anonymous.” This is a hypothetical scenario, not a reported incident or a tested result.
Withdraw the anonymity conclusion. The sensitive-data guidance cautions that a hash can be practically reversed when its possible inputs are limited and predictable, with numeric identifiers given as an example. Record that risk, halt the export if local policy disallows it, and select either deletion or a coarser locally approved representation.
Coarser grouping is a distinct alternative to hashing: the guidance gives examples such as retaining a broader date portion, an email domain, or less-specific IP information. Whether any grouping is acceptable remains an application decision based on the stated purpose and residual-risk review.
Operational boundaries and review
Instrumentation can expose information that needs review, and the implementer carries responsibility for protecting sensitive telemetry, obtaining needed consent, and applying appropriate data handling. Treat sanitization as one control within that responsibility rather than as a complete governance program.
Collector security also involves both the deployment environment and Collector configuration. A review process can therefore pair the table’s local decisions with checks for the declared purpose, field inventory, approved representation, retention rule, access rule, and escalation owner.
Limitations: these excerpts document processor categories and sensitive-data practices, but they do not establish the correctness of any local allowlist, retention interval, authorization model, or anonymity conclusion. Revisit the decision when the source material changes or when an incompatible release affects the deployment.