OpenTelemetry Transformation Language (OTTL) is a rule language for changing telemetry data as it moves through collection pipelines. It lets teams filter, enrich, rename, or drop metrics, logs, and traces using structured conditions and transformations. In practice, OTTL helps standardize observability data before it reaches storage, analysis, or security tools.
How OTTL fits into telemetry pipelines
OTTL sits inside the collection and processing layer of observability systems. It is used after telemetry is ingested but before data is stored, forwarded, or analyzed, so the rule language becomes part of the pipeline’s control plane for shaping data at speed.
That placement matters because transformation rules can standardize fields across different producers, normalize formats, and remove noise before downstream tools see the data. It also means the language has operational influence over what evidence survives for troubleshooting, analytics, and security review.
What OTTL rules actually do
OTTL is designed for structured manipulation of metrics, logs, and traces. Typical actions include filtering records, enriching events with additional context, renaming fields for consistency, and dropping data that is redundant, irrelevant, or too expensive to retain.
The practical value is that one language can express many common telemetry decisions without hard-coding each pipeline branch. That makes transformations more portable across collectors and helps teams treat telemetry shaping as a governed rule set rather than as one-off parsing logic.
Why telemetry transformation is security-relevant
Telemetry is not just operational data, it is often the evidence base for incident triage, detection engineering, and post-incident reconstruction. If transformation rules are too aggressive, they can strip the context needed to spot misuse, trace an attack path, or correlate events across systems. If they are too loose, they can pass sensitive fields or high-volume noise into downstream platforms and reduce signal quality.
OTTL therefore becomes a trust boundary for observability data. Rules should preserve the fields that support attribution, sequence, and investigation, while removing only what is genuinely unnecessary for the intended use case. In security-heavy environments, that includes being careful with logs that may contain tokens, identifiers, session context, or user-input content.
Where OTTL is useful in modern observability design
OTTL is most valuable when different applications emit inconsistent telemetry and the organisation needs one place to align data before it reaches storage or analytics. It helps teams enforce a common schema, route data based on content, and reduce downstream duplication without changing every emitter.
It also supports layered observability architectures, where collection is separated from analysis. That separation makes it easier to adapt pipelines as tools change, because the transformation logic stays close to the telemetry flow rather than being scattered across multiple consumers.
Risk and Threat Considerations
Transformations can become a hidden source of blind spots when a rule drops the wrong field, rewrites values incorrectly, or filters out low-volume events that later prove important. The risk is highest when OTTL is used to simplify noisy telemetry without clear ownership for what must be preserved.
Failure mechanism: An attacker or an accidental misconfiguration can exploit overbroad filtering, field removal, or enrichment errors to reduce visibility, break correlations, or conceal malicious activity in the observability pipeline.
Impact: Detection gaps, incomplete investigations, and weaker post-incident reconstruction can follow, especially when telemetry is the main source of truth for application behaviour and security events.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | OTTL affects what telemetry remains available for review and analysis. |
| AU-12 — Audit Record Generation | OTTL sits in the telemetry path that shapes generated records before storage or analysis. | |
| SI-4 — System Monitoring | OTTL directly influences the monitoring data used to detect malicious or anomalous activity. | |
| Recommendation — Preserve the event fields needed for audit review and alert correlation before dropping or rewriting telemetry. Validate that collection rules do not suppress or distort the records your monitoring program depends on. Route transformed telemetry so monitoring content still supports detection and investigation. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | OTTL can filter, normalize, or drop telemetry that later becomes audit evidence. |
| Recommendation — Protect log quality by reviewing transformation rules that reduce or alter audit-relevant telemetry. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitored networks and systems | OTTL determines the quality and completeness of data used for continuous monitoring. |
| Recommendation — Ensure monitoring pipelines retain the telemetry needed for continuous detection and response. | ||
Practitioner Guidance
Why practitioners should care: OTTL should be managed like production logic, not ad hoc parsing. A transformation rule can change what the organisation can detect, prove, or retain, so ownership and review discipline matter.
What to watch for: Changes that rename core identifiers, drop uncommon event types, or enrich data from uncertain sources deserve extra scrutiny. Those are the places where a small rule can have a large operational effect.
Practitioner takeaway: Treat telemetry transformation as part of your observability governance, with explicit review for data loss, security visibility, and downstream compatibility before rules are promoted.
Related resources from NHI Mgmt Group
- Guide: AI Agent Observability, Audit and Incident Response Guide
- How does EXtensible Stylesheet Language Transformation work?
- Why does EXtensible Stylesheet Language Transformation matter for security teams?
- EXtensible Stylesheet Language Transformation
- Why should identity teams be cautious about natural-language queries over access data?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org