Unlocking Observability: Lambda Functions in OTTL
In the world of observability, the ability to manipulate and transform telemetry data is crucial. Lambda-powered functions in OpenTelemetry Transformation Language (OTTL) allow you to apply inline logic directly to your data, making complex transformations both reusable and concise. This capability addresses the common pain point of needing to filter, map, or reduce data without writing extensive boilerplate code.
Lambda expressions are small anonymous functions defined inline, taking parameters and a body that can be any valid OTTL expression. For example, you can use the Filter function to keep only attributes whose keys start with a specified prefix, or employ MapKeys to normalize attribute key names to a specific format. With functions like Any and All, you can check conditions across collections, while Find helps you locate specific elements quickly. These functions are experimental and available in OpenTelemetry Collector Contrib v0.157.0, activated through the feature gate ottl.functions.enableLambda.
In production, these lambda functions can significantly simplify your data processing workflows. However, remember that all eight functions are still experimental, which means you should proceed with caution. Test thoroughly before deploying in critical environments. The flexibility of inline conditionals with the When function can also help you reduce the number of set statements, making your transformations cleaner and more efficient.
Key takeaways
- →Utilize lambda expressions for concise data transformations in OTTL.
- →Apply the Filter function to retain only relevant attributes based on key prefixes.
- →Normalize attribute keys using MapKeys for consistent data formatting.
- →Leverage inline conditionals with the When function to streamline your logic.
- →Be aware that all functions are experimental and require thorough testing.
Why it matters
Using lambda functions in OTTL can drastically reduce the complexity of your telemetry data transformations, leading to cleaner code and more efficient data handling in observability pipelines.
Code examples
# Keep only attributes whose key starts with "http."
set(span.attributes, Filter(span.attributes, (k, _) => HasPrefix(k, "http.")))# Normalize all attribute key names to snake_case
set(span.attributes, MapKeys(span.attributes, (k, _) => ToSnakeCase(k)))# Total bytes across a list of response sizes
set(span.attributes["total_bytes"],
Reduce(span.attributes["response.sizes"], 0, (acc, _, v) => acc + v))When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsOpenAI & Anthropic-compatible inference API — no GPU provisioning needed. 55+ models, pay-per-token with no minimums. VPC + zero data retention by default.
Try Serverless Inference →Unlocking Performance: Pyroscope 2.0 for Continuous Profiling at Scale
Pyroscope 2.0 revolutionizes continuous profiling, providing insights into why your code is slow or costly. With data co-location and stateless queriers, it optimizes performance and storage efficiency. Dive in to see how it can transform your observability strategy.
OpenTelemetry Graduation: What Comes Next for Your Observability Strategy
OpenTelemetry has officially graduated, marking a significant milestone in observability. With stable APIs and robust governance, it's time to rethink how you implement tracing, metrics, and logs in your systems. This article dives into what this means for production adoption and community health.
OTel-Arrow Phase 2: Building Efficient Telemetry Pipelines
In the world of observability, efficient telemetry pipelines are crucial for performance. The OpenTelemetry Arrow Protocol (OTAP) leverages a NUMA-friendly architecture to streamline data transport and processing. This article dives into how OTAP transforms telemetry handling.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.