The SDK core handles authentication, HTTP requests, and response parsing for all IBM Cloud Java SDKs, making it a natural place to add distributed tracing instrumentation.
Adding OpenTelemetry support (via the opentelemetry-api dependency) would let consumers:
- Automatically create spans for every SDK API call, including HTTP method, path, status code, and duration
- Propagate trace context from the calling application into IBM Cloud service calls
- Correlate SDK client behavior with application-level traces in tools like Jaeger, Datadog, or New Relic
This could be implemented as an opt-in feature — if OpenTelemetry is on the classpath, the BaseService class creates a span around each sendRequest call and populates http.* semantic convention attributes. No breaking changes to the existing API.
Several major cloud SDKs (AWS SDK v2, Azure SDK, Google Cloud Java) already support this pattern. The IBM Cloud SDK Generator ecosystem would benefit from consistent observability without each generated SDK having to reimplement tracing.
The SDK core handles authentication, HTTP requests, and response parsing for all IBM Cloud Java SDKs, making it a natural place to add distributed tracing instrumentation.
Adding OpenTelemetry support (via the
opentelemetry-apidependency) would let consumers:This could be implemented as an opt-in feature — if OpenTelemetry is on the classpath, the
BaseServiceclass creates a span around eachsendRequestcall and populateshttp.*semantic convention attributes. No breaking changes to the existing API.Several major cloud SDKs (AWS SDK v2, Azure SDK, Google Cloud Java) already support this pattern. The IBM Cloud SDK Generator ecosystem would benefit from consistent observability without each generated SDK having to reimplement tracing.