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 →Mastering Instrumentation Quality for Full-Stack Observability
To achieve true observability, you need to measure and improve your instrumentation quality. Each service gets a quality score based on automated checks, giving you a clear view of where improvements are needed. Dive in to learn how to leverage this for better insights.
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.
Scaling Alloy: Mastering Your Central Telemetry Gateway
Scaling Alloy as a telemetry gateway is crucial for managing application observability effectively. With Horizontal Pod Autoscaling set to target 70% CPU and 90% memory, you can ensure your system remains responsive under load. Dive into the specifics of configuration and real-world production lessons.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.