add xray/opentelemetry support

[ojii]

would be nice. not entirely sure what is needed for this though

[kasteph]

Will pick this up 🫡

[dimaqq]

Some wise words from a dude who implemented open telemetry support:

• closed source
• open source in feat: ops[tracing] (with a first-party charm lib) canonical/operator#1612

Some concepts and observations:

• telemetry is owned by an application, not a library; only the application can provide the semantic context (are we writing to a log table or creating an admin user?)
• telemetry is a systems-level concept, the job of the app is to provide just enough to connect the parts, and the job of the library is to make that easy
• library can be spinkled with pixie dust (instrumented in a few key points), or can be subject to auto-instrumentation (in your case httpx/aiohttp)
• depending on opentelemetry-api is OK even if it feels a bit heavy
• depending on the SDK is always heavy (ideally application-level concern, rather than an extra in the library), pick and choose carefully
• OTEL project has bugs, misfeatures and broken types... and it's heavy, not-so-pythonic and it's a moving target, sometimes it's easier to (re)implement a module or two in pure Python

[kasteph]

Thanks, this is helpful context. I agree that telemetry policy and semantic context belong to the application, not the library. My intent here is to keep telemetry library-scoped and optional. #208 provides instrumentation hooks so applications can observe client operations without having to wrap every call themselves.

I also agree that telemetry is ultimately a systems-level concern, and that the library should make integration easy rather than own the application’s observability setup. That’s why I chose explicit hooks in a few key places instead of relying entirely on auto-instrumentation: I want aiodynamo operations themselves to be visible, not just the underlying HTTP calls.

I’ve also kept the otel dependency optional, and I’m mindful of it being an application-level concern. If you think the abstraction still exposes too much otel-specific surface area, I’m happy to trim it further. I’d be glad to align on the smallest API shape that still makes this ergonomic for users.