Security and platform teams should treat OpenTelemetry support as a transport and normalization layer, not a replacement for log management. The practical goal is to receive OTel messages, parse them into usable fields, then reformat, filter, and route them to the right destinations such as SIEM, metrics, or tracing backends. That preserves observability interoperability while keeping operational control over the data path.
How to fit OpenTelemetry into the log pipeline without giving up control
OpenTelemetry works best when you introduce it as a normalization and transport layer, while keeping your existing log routing logic intact. That means teams still decide where data goes, what gets filtered, and which systems own search, alerting, retention, and analytics. The integration point is the ingest path, not the control plane.
The key design choice is to separate collection from disposition. Receive OTel-formatted events, convert them into the field structure your pipeline can process, then apply the routing rules you already trust for SIEM, observability backends, or long-term storage. That keeps interoperability high without forcing a single downstream destination.
For most teams, the operational question is not whether OTel can carry logs, but whether it can do so without flattening the data model or breaking existing filters. Good implementations preserve source context, timestamp fidelity, severity, and correlation fields, then map or enrich only where the destination requires it.
One practical pattern is to keep OTel at the edge of ingestion and let the log platform remain authoritative for policy, enrichment, and fan-out. If you are already using a collector or pipeline processor, treat OTel support as one input format among several, not as a reason to redesign every downstream destination at once.
What preservation of routing flexibility really means in practice
Routing flexibility is preserved when the team can still branch logs based on content, source, sensitivity, tenancy, or operational purpose after the OTel payload is received. That requires parseable fields, stable metadata, and a pipeline that can re-emit to more than one target without losing the original event semantics.
The most common failure mode is treating OTel normalization as the final shape of the data. Once that happens, downstream consumers may lose the exact fields they depended on for alerting, compliance review, or incident investigation. If a destination needs a different schema, transform for that destination, not for the whole estate.
Another important boundary is vendor or platform lock-in. OTel should reduce friction between telemetry producers and consumers, but it should not force a single storage, query, or SIEM strategy. When teams preserve an intermediate routing layer, they can redirect data as requirements change, which is especially useful during tool migration or control testing. Guidance from SLSA is relevant here because it reinforces the value of verifiable transport and provenance in pipeline design, even when the immediate topic is log routing rather than build integrity.
In practice, this also means deciding which transformations are reversible. Field mapping that can be audited and replayed is safer than destructive reshaping, because incident responders may later need the original structure for reconstruction or legal hold.
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 | CIS Control 8 — Audit Log Management | OTel log ingest affects how logs are collected, normalized, retained, and routed. |
| CIS Control 13 — Network Monitoring and Defense | Routing OTel telemetry to SIEM and observability tools supports monitoring and detection coverage. | |
| Recommendation — Preserve required log fields and retention paths before transforming OTel events. Route normalized telemetry to the monitoring stack that can detect and alert on it. | ||
| NIST CSF 2.0 | PR.PT — Protective Technology | Using OTel as a transport and normalization layer is a protective technology design choice for telemetry handling. |
| DE.AE — Anomalies and Events Are Detected | Keeping routing flexibility helps preserve the event context needed for detection use cases. | |
| Recommendation — Implement telemetry processing so data can be transformed without losing control over delivery paths. Ensure the pipeline retains fields required for anomaly detection and alert correlation. | ||
Practitioner Guidance
What to verify: Confirm that the collector or processor can parse OTel messages, preserve source metadata, and hand off to at least two downstream routes without forcing a single schema on every consumer. If the pipeline cannot branch cleanly, you have integration, not interoperability.
Implementation sequence: Start with one OTel ingest path, map it into your current canonical log schema, then test a second route for security analytics or observability before migrating any production producer. Keep the original payload available long enough to validate field parity and alert fidelity.
Common mistake: Teams often equate “OTel enabled” with “pipeline complete.” The real test is whether operations can still re-route, enrich, and retain data on their own terms when a destination changes, a control needs tuning, or an investigation needs the unmodified event context.
Practitioner takeaway: Preserve the log pipeline as the decision layer, and use OpenTelemetry as the compatibility layer underneath it.
Related resources from NHI Mgmt Group
- How should security teams evaluate whether a log management platform can replace syslog-ng without disrupting existing deployments?
- How should security teams design telemetry pipelines for Kubernetes without creating brittle log routing dependencies?
- How should security teams scale telemetry pipelines without losing correlation quality?
- How should security and platform teams reduce telemetry costs without losing operational visibility?
