Repository navigation
Feature request: OpenTelemetry Support聽#7003
Description
Use case
We're actively considering bringing OpenTelemetry support to Powertools for AWS Lambda 馃帀
If this is something that you'd like to see us working on, please take some time to read this RFC aws-powertools/powertools-lambda#90 and share your feedback. If you prefer, you can also email us at aws-powertools-maintainers@amazon.com using your work email ;)
This RFC focuses on Tracer and all examples are in Python, but we really want to hear your opinion and make this the best possible OTEL experience on AWS Lambda!
Solution/User Experience
See aws-powertools/powertools-lambda#90
Alternative solutions
Acknowledgment
- This feature request meets Powertools for AWS Lambda (Python) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET
Activity
mrcghil commentedon Aug 20, 2025
I think this is a great idea. To be completely honest, I am not a big fan of lambda layers (maybe I am using them wrong?) so I would rather have something that can be installed in the same way of all the other extra dependencies for this repo.
Dilski commentedon Sep 14, 2025
Hello, as you may be aware the AWS X-ray SDK now has a deprecation plan (it enters a maintenance mode in February, is EOL the February after), See Aws docs
I always hoped that the powertools would make the move from x-ray SDK to Otel as easy as possible, and I do believe that the RFC/proposal sets out a way in which it would be!
Now that we have to move to Otel, I need to consider a migration plan and what to recommend for new services going forward. As a Big Powertools Fan, that hinges on what powertools is going to do.
In light of the recent news, is the powertools team able to commit to something around OTel? I appreciate this has been in discussion for a couple of years now, so is there anything we as community and customers can do to help move this along?
Thanks鈾ワ笍
leandrodamascena commentedon Sep 14, 2025
Yes, we wrote this RFC to raise awareness of this topic and gather community feedback to help us define the shape/future of this implementation. I'd really appreciate it if you could contribute to the RFC - of course, if you have any feedback and time allows.
I really love reading when our work makes a difference in other people's lives and people are happy with the project we are building.
I imagine you're asking about dates/deadlines here, and we haven't committed to any specific dates yet, as there are many open questions in the RFC that we hope to have the proper answer soon. But this doesn't mean we're not working on them and trying to speed things up, but again, we need to have answers to some questions, and we don't have them yet.
We're also working closely with the Lambda/Observability Service team to find the best experience for customers using Lambda instrumentation with OpenTelemetry.
I'd love to connect with you in a meeting - you can bring your team if you'd like - to better understand your Powertools for AWS use case and also discuss OTEL. Customer influence/demand is extremely important so that we can use it in some requirements/decisions that we need to have internally.
If you'd like, you can email aws-powertools-maintainers@amazon.com and I'll send you some dates to meet. I'll be on PTO from the 16th to the 24th, but I can respond to your email within those dates.
Thank you very much, I really appreciate your words and I will be very happy to help with whatever I can. 鉂わ笍 鉂わ笍
oyiz-michael commentedon May 14, 2026
I recently built an AI observability agent on EKS that ingests signals from Prometheus (metrics), Loki (logs), and Tempo (traces) and feeds them into an LLM to automatically surface anomalies and recommendations. All three backends are OTEL-native.
The challenge I hit is that Lambda functions in the same system are still emitting traces via the X-Ray SDK, which means our trace data is fragmented, OTEL traces from containers and X-Ray traces from Lambda can't be correlated in a unified backend like Tempo or Grafana Cloud.
Full OTEL support in Powertools would allow us to route Lambda traces and correlate them with other workload traces in a single pipeline. For AI-driven observability use cases, having unified, structured OTEL spans from every layer (Lambda + containers) dramatically improves the signal quality fed into the LLM.
Happy to share more about this use case if it helps shape the RFC.
oyiz-michael commentedon May 14, 2026
One thing worth calling out: the configuration of exporters/endpoints matters a lot in Lambda cold-start sensitive workloads. In our EKS-based agent i batch and export OTEL data asynchronously, but in Lambda synchronous invocations, a blocking OTLP export on every invocation could add latency. We should clearly address whether the exporter is async/non-blocking and how flush is handled at function end.
Also worth considering: for customers running Lambda behind an API Gateway in a VPC, the OTLP exporter needs to reach the collector without a public endpoint support for configuring the OTLP endpoint via env var (standard OTEL_EXPORTER_OTLP_ENDPOINT) would make this plug-and-play with any collector setup.
Alwaysgaurav1 commentedon Oct 21, 2026
Hi everyone,
Following up on the discussion and my initial exploration in #8366 around an
OpenTelemetryProviderfor Tracer:A few practical considerations from working with the provider pattern that might help shape the RFC/design:
OpenTelemetryProviderfits cleanly into the existingTracercontract, a standalone provider doesn't address telemetry correlation across Logger, Metrics, and Tracer (or upcoming GenAI semantic conventions). Deciding early whether OTel will be an underlying provider for existing utilities or a cohesive, first-class Powertools OTel module will help guide implementation.@asynccontextmanagerhandling for coroutines and concurrent tasks (asyncio.gather), ensuring context propagation doesn't detach across tasks.record_exception()only adds an event; we must explicitly set the span status toStatusCode.ERRORso failed Lambda invocations are properly flagged in backends (X-Ray, Honeycomb, Tempo, CloudWatch Application Signals).Tracerdefaults to auto-patching, we should clarify how Powertools coordinates with the ADOT Lambda Layer vs. manual SDK exporters, particularly around cold-start latency and flushing spans synchronously before the execution environment freezes.Looking forward to helping shape the implementation once the team aligns on the architectural direction!
iblancasa commentedon Oct 21, 2026
I reviewed #8366 before it was closed, so I have been following this one. The four points above are the same ones I left in that review and I agree they are table stakes for any OpenTelemetry provider. They are also independent of the bigger question of whether OTel should live under the current
Traceror become its own module....I want to be upfront about why I care. I work on the Lambda layer at Coralogix. We have customers who use Powertools and OpenTelemetry together today, without ADOT. Some run our layer, some wire up the OTel SDK themselves. What they all hit is the same thing: the layer or their bootstrap code configures OpenTelemetry before the handler loads, but then their code calls
Tracer()andTracer()goes straight to the X-Ray provider.Tracer(provider=...)is there, but it means touching the source of every function, which a layer cannot do for them. So they end up with X-Ray subsegments on one side and OTel spans on the other. And the two never meet.I do not think this needs the whole RFC to be settled first. What is missing is one small hook on the existing process-wide config, so something that runs before the handler can say which provider bare
Tracer()should use:An explicit
Tracer(provider=...)still wins and calling it twice raises. Powertools picks up no OpenTelemetry dependency and no vendor names. Each layer or each customer ships their ownBaseProvideradapter and owns the quality of it. When theTracerOpenTelemetryfrom the RFC arrives, nothing here gets in its way, and themode="auto"path gets a natural place to register itself.I already have this written and a unit test against the provider stub you use in the tests. Also I tested on my environment and works perfectly. If it sounds reasonable I can open a PR. If you would rather pick the provider through an environment variable than a classmethod, say so and I will do it that way