[Alwaysgaurav1]

Issue number: closes #7003

Summary

Changes

• Implemented OpenTelemetrySegment and OpenTelemetryProvider in aws_lambda_powertools.tracing.opentelemetry.
• Exported OpenTelemetryProvider and OpenTelemetrySegment from aws_lambda_powertools.tracing.
• Added unit tests covering segment attribute set, exception recording, subsegment context managers, and Tracer decorator integration in tests/unit/test_opentelemetry.py.

User experience

Users can now pass an OpenTelemetryProvider to Tracer to send trace data to OpenTelemetry backends:

from aws_lambda_powertools import Tracer
from aws_lambda_powertools.tracing import OpenTelemetryProvider

provider = OpenTelemetryProvider()
tracer = Tracer(service="my-service", provider=provider)

@tracer.capture_method
def handler(event, context):
    return "ok"

[boring-cyborg]

Thanks a lot for your first contribution! Please check out our contributing guidelines and don't hesitate to ask whatever you need.
In the meantime, check out the #python channel on our Powertools for AWS Lambda Discord: Invite link

[powertools-for-aws-oss-automation]

No acknowledgement section found. Please make sure you used the template to open a PR and didn't remove the acknowledgment section. Check the template at .github/PULL_REQUEST_TEMPLATE.md#acknowledgment

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[iblancasa]

The provider abstraction is a useful direction, but I think this needs more work before it is ready to merge.

Issue #7003 and the linked RFC describe a first-class OpenTelemetry experience that can work alongside Lambda autoinstrumentation. This PR currently provides basic child-span creation, but it does not yet define the expected behavior for dependencies, asynchronous functions, error status, metadata handling, or automatic instrumentation.

Could you please address the inline runtime issues and add tests using a real OpenTelemetry SDK/in-memory exporter rather than only mocks? In particular, we should verify async decorators, parent-child context, error status, metadata serialization and size limits and the behavior of patch/patch_all.

It would also help to document how customers select this provider and whether this is intended as a complete OpenTelemetry tracing solution or only a lower-level provider building block.

I know it has been a while since you created the PR and maybe you are not interested anymore in the feature, your priorities changed or something else. If you don't have bandwidth for working on this PR, let me know and I can take it.

[iblancasa]

in_subsegment_async is decorated with @contextmanager, which creates a synchronous context manager. Powertools uses this method with async with, so every async @capture_method call will fail at runtime

[iblancasa]

When OpenTelemetry is not installed, this silently creates a no-op provider. Users can deploy successfully but receive no traces.
I guess something should be, at least, printed

[iblancasa]

Converting metadata with str(value) loses structured data and produces Python representations rather than stable telemetry values.
It can also create very large span attributes. Please use bounded JSON serialization or record metadata as a bounded span event. The same issue exists in put_metadata

[iblancasa]

Tracer enables automatic patching by default, but patch and patch_all silently do nothing for this provider. This means customers may assume HTTP, AWS SDK, and database calls are instrumented when they are not

[iblancasa]

Recording an exception does not set the OpenTelemetry span status to ERROR. Failed handlers and methods may therefore appear successful in tracing backends

[leandrodamascena]

Hi @Alwaysgaurav1, thanks for putting this together, and sorry it sat here for two months without a proper answer.

We're still debating how OpenTelemetry should fit into Tracer: whether it's a provider like this PR does, or something broader that also covers Logger and Metrics, and how it interacts with the GenAI semantic conventions and ADOT. That discussion is still open in #7003, so I'm going to close this PR for now rather than keep it hanging while the design isn't settled.

To be clear, this isn't a judgement on the code. When we land on a direction and implement it, I'll make sure you get credit for this work, and you're more than welcome to join the discussion in #7003 in the meantime. Thank you!

[Alwaysgaurav1]

Hi @leandrodamascena,

Thank you for the update and for the thoughtful explanation! I completely understand holding off until the broader architectural direction (unifying Tracer, Logger, Metrics, and ADOT integration) is established.

While reviewing the code and feedback, I also noted a few key areas that we'll want in the final implementation:

• Ensuring in_subsegment_async uses @asynccontextmanager for proper async method lifecycle support.
• Setting the span status to StatusCode.ERROR when recording exceptions so error states reflect accurately in telemetry backends.
• Structured/bounded JSON serialization for put_metadata instead of raw str().
• Clear warnings or validation when OpenTelemetry dependencies or auto-patching aren't configured.

I'm happy to follow the discussion on #7003 and contribute once the design direction is finalized. Thanks again!