A common mistake is treating OpenTelemetry as if it only forwards telemetry unchanged. In practice, the value increases when the processor can parse OTel payloads, transform fields, and route data based on destination requirements. If teams skip that processing layer, they lose normalization, filtering, and the ability to adapt telemetry for different observability tools.
Why the “just forward it” mental model fails
OpenTelemetry is more useful than a transport shim when teams treat the collector or processor as the place where telemetry becomes usable. Raw signals often need field parsing, normalization, enrichment, sampling, redaction, and destination-specific routing before they are reliable across tools. If you skip that layer, you end up pushing tool-specific cleanup into every backend instead of standardising it once.
The practical mistake is assuming the source format is already fit for every consumer. In reality, observability backends differ in naming conventions, cardinality tolerance, retention costs, and accepted field shapes, so the processor is where a common telemetry contract is enforced. That is why the Ultimate Guide to NHIs — What are Non-Human Identities is relevant here as a governance analog, because the same operational discipline applies to any high-volume machine-generated stream: standardise, constrain, and control it before it spreads.
- Parsing turns semi-structured payloads into fields that downstream systems can search and correlate consistently.
- Normalization reduces schema drift when multiple services emit similar data in slightly different ways.
- Filtering and sampling cut noise before storage and indexing costs grow.
- Routing lets one telemetry stream feed logs, metrics, traces, and security tools without forcing every destination to accept the same shape.
What teams lose when processing is skipped
When OpenTelemetry is used only as a pass-through, teams usually lose three things at once: consistency, adaptability, and control. Consistency suffers because data stays in whatever shape each application emits. Adaptability suffers because you cannot easily tailor payloads for a specific backend or incident workflow. Control suffers because bad fields, noisy spans, or sensitive values reach the platform before anyone can intervene.
That makes the collector much closer to an integration layer than a dumb relay. It is the place where teams can apply policy once and then reuse that policy across destinations, which matters when observability platforms, SIEMs, and analytics tools all expect different structures. For organisations that want a broader model of how machine-generated identities and their operational handling should be governed, OWASP Non-Human Identity Top 10 and SPIFFE workload identity specification are useful references for the wider principle of managing machine-produced data and machine-originated trust with explicit structure rather than ad hoc forwarding.
- Backends become harder to compare because each one receives a slightly different variant of the same event.
- Security and privacy controls weaken if redaction or suppression happens only after data is already exported.
- Troubleshooting becomes slower because telemetry is inconsistent across teams and environments.
- Vendor migrations become more expensive because transformation logic is scattered across producers and consumers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8.2 — Audit Log Management | Telemetry processing affects log usefulness, normalization, and downstream consumption. |
| 13.1 — Network Monitoring and Defense | OpenTelemetry routing and filtering support usable monitoring across tools. | |
| 3.2 — Data Classification and Handling | Processors can redact or suppress sensitive telemetry before it reaches destinations. | |
| Recommendation — Standardise telemetry fields before export so audit data stays searchable and consistent. Route telemetry through a processing layer that filters noise and preserves monitoring value. Apply handling rules in the pipeline so sensitive fields are removed before export. | ||
| NIST CSF 2.0 | DE.AE — Anomalous Events Detected | Processed telemetry improves detection of meaningful anomalies across observability tools. |
| PR.DS — Data Security | Telemetry pipelines often need transformation and redaction to protect sensitive data. | |
| Recommendation — Normalize and filter telemetry so anomaly detection receives comparable signals. Transform telemetry before export to reduce exposure of sensitive fields. | ||
Practitioner Guidance
What to prioritise: Define the collector pipeline as a policy point, not just a delivery path. The highest-value work is usually schema shaping, destination-specific transforms, and early filtering, because those choices affect every backend and every team that consumes the telemetry.
What to verify: Confirm that the same signal can be rendered correctly in at least two destinations without changing application code. If a dashboard, alert rule, or security workflow only works because one backend happens to tolerate the raw format, the pipeline is still too thin.
Common mistake: Teams often optimise for “data got there” instead of “data was useful when it got there.” That leads to duplicated parsing logic, noisy storage, and brittle analytics rules that break as soon as a service team changes instrumentation.
Practitioner takeaway: The collector layer should reduce entropy, not just move it. If OpenTelemetry is not shaping telemetry for downstream use, you are outsourcing the hard work to every consumer and losing the main leverage the platform gives you.
Related resources from NHI Mgmt Group
- What do teams get wrong when they try to use a RAG framework as a full agent orchestration layer?
- What do teams get wrong when they use identity claims as access policy?
- What do teams get wrong when they use workforce IAM for customers?
- What do teams get wrong when they use the Cybersecurity Framework for incident response?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
