Start with an export-purpose boundary
Telemetry can unexpectedly include sensitive or identifying material. Teams are responsible for reviewing instrumentation output and applying the protection, consent, handling, storage, and compliance measures required in their setting.
Use the diagnostic question as the admission rule: a field should be exported only when it helps answer a defined operational question. This is a proposed policy method, not a claim that every service needs the same fields.
Field-handling policy
The following proposed policy separates fields that may be useful at export from fields that should be excluded or altered. Field names and values are illustrative; adapt them to the service’s threat model and troubleshooting needs.
| Disposition | Example field or value | Proposed export treatment | Diagnostic consequence |
|---|---|---|---|
| Allowed | Service name, deployment label, operation name, response class | Permit only after confirming the field answers a stated diagnostic question. | Unverified design objective: enable service-level grouping without exporting identity-bearing request content; validate against actual field values. |
| Omitted | Authorization header, session cookie, request body, password, access token | Do not capture or forward these values. | If omission works as intended, the removed secret or payload cannot be inspected through that telemetry output. |
| Omitted | Full name, payment data, health detail, detailed behavior history | Exclude unless a documented observability need and suitable safeguards justify collection. | Expected trade-off to validate: less person-level detail for investigations. |
| Conditionally redacted | Email address | Where routing analysis is enough, retain only the domain portion rather than the complete address. | Unverified outcome: domain-level grouping remains useful while mailbox-level correlation is reduced; test with the actual analysis workflow. |
| Conditionally redacted | Client IPv4 address | Where subnet-level analysis is sufficient, suppress the last octet. | Unverified outcome: subnet grouping remains useful while host-level attribution from this field is reduced; test in the deployment. |
| Conditionally redacted | Internal user identifier | Prefer omission; if hashing is proposed, assess whether a predictable input set makes recovery practical. | No correlation benefit is assumed. Test any such requirement separately, and assess recovery risk for predictable inputs. |
Personal identifiers, credentials, session material, financial information, health information, and behavioral data can all require sensitive-data treatment, but context determines the actual risk. Periodically reassess whether each admitted attribute still serves its operational purpose; aggregation or anonymization may be a better fit for some questions.
Choose the earliest practical control point
The strongest design is to prevent unneeded sensitive values from being recorded at all. When collection cannot be avoided or is outside the application team’s control, apply an explicit processing boundary before export and treat that boundary as a second line of defense rather than the only safeguard.
At that processing boundary, documented choices include changing or deleting attributes, rejecting complete spans or metrics, redacting against an allowed-attribute list, and applying regular-expression transformations. Specify which boundary handles each signal type, including logs, metrics, traces, nested attributes, and fields produced by third-party instrumentation.
Do not equate a digest with anonymous data. A predictable or small set of possible source values can make a hashed value susceptible to recovery. Precision reduction is another option: the guidance gives examples such as removing the mailbox-specific portion of an email while retaining its domain, reducing date detail, or suppressing the final IPv4 octet.
Illustrative redaction cases
Use cases below are test specifications, not executed test results. Each test should be run at the actual collection or processing boundary selected by the deployment.
| Case | Illustrative input | Intended exported output | Residual privacy or diagnostic trade-off |
|---|---|---|---|
| Secret header | authorization: Bearer example-secret | Field absent | Intended trade-off: this output cannot expose the removed secret; plan non-secret status and error signals for authentication diagnosis. |
| Email address | customer.email: [email protected] | customer.email_domain: sample.example | Outcome to verify: domain grouping remains useful after the mailbox-specific portion is removed. |
| Client network address | client.address: 203.0.113.42 | client.address: 203.0.113.0 | Outcome to verify: subnet analysis remains useful after host precision is reduced. |
| User identifier | user.id: account-417 | Field absent | Intended result to test: correlation based on user.id is unavailable when that field is absent; do not assume other correlation paths are absent. |
| Request payload | http.request.body: symptom details | Field absent | Intended trade-off: this output omits payload detail; validate whether remaining signals are sufficient for debugging. |
For each case, assert both the expected output and the absence of the original value in every destination path. Include malformed input, alternate nesting, derived fields, processor failure, and bypass-path scenarios in the review plan. The source material supplied here does not provide test outcomes for these cases.
Operational and compatibility limits
Treat prevention and post-processing as separate controls. Official guidance favors avoiding collection of sensitive values and also offers processing options when collection is needed or not fully controlled. In this proposed architecture, place that processing boundary before export; this does not establish that earlier handling was safe.
Protect the Collector environment and its configuration as part of the design. The broader security guidance calls out sensitive telemetry protection, tampering, regulatory concerns, and denial-of-service considerations for Collector deployment and configuration.
This is architecture guidance only. It does not claim that a particular processor configuration, syntax, or release works across every Collector deployment. Confirm the target release, processor schema, signal coverage, and failure behavior before adopting an illustrative rule.
Decision record for troubleshooting trade-offs
For every allowed or transformed field, record the operational question, owner, insertion boundary, export destinations, retained precision, and review date. Also record what an on-call engineer can no longer determine after omission or transformation. That record makes a privacy decision reviewable instead of hiding it in a processor configuration.
A viable alternative is a narrowly scoped diagnostic capture with short retention and separate access controls when an incident genuinely requires more detail. Such an exception should still define its collection boundary, approval conditions, expiration, and deletion path; it is not evidence that ordinary telemetry should carry the same data.