Open scaugrated opened 1 year ago
This is closely related to https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/8453 If the AWS SDK instrumentation did not attempt to implement the HTTP semconv itself, and simply left it to the underlying HTTP instrumentation, this most likely wouldn't be a problem.
Is your feature request related to a problem? Please describe.
We were attempting to implement logic based on the
http.status_code
attribute found in spans and observed it was not being populated for spans coming out of the AWS SDK when the AWS APIs were returning non-200 status codes.Here are the details of the investigation for this issue by @thpierce :
http.status_code
attribute is being populated in the following call chain:afterExecution
calls onHttpResponseAvailable, which calls HttpCommonAttributesExtractor.onEndonEnd
will call AwsSdkHttpAttributesGetter.getStatusCode only if the response is not nullgetStatusCode
returns the status code from the response and passes it back to uponEnd
, which will set the http.status_code attribute value accordingly.TracingExecutionInterceptor.afterExecution
is not called at all, instead TracingExecutionInterceptor.onExecutionFailure is called, which does not call intoHttpCommonAttributesExtractor.onEnd
at all.onExecutionFailure
calledonEnd
, the response would benull
andgetStatusCode
would not be called.http.status_code
is not set. This is clearly by design asAwsSdkHttpAttributesGetter
implements the generic HttpCommonAttributesGetter, which has the following JavaDoc forgetStatusCode
: "This is called from Instrumenter.end(Context, Object, Object, Throwable) only when response is non-null.".HttpCommonAttributesGetter
like AkkaHttpClientAttributesGetter, we can see thatgetStatusCode
would fail with a NPE if we called it with a null response, so this contract is assumed by other implementations.Describe the solution you'd like
Fundamentally, the problem is that the common HTTP instrumentation code assumes that status codes can only be delivered via response objects, but the AWS SDK delivers status codes via exceptions.
We look forward to have a comprehensive solution to solve this problem.
In the short term, we have come up with a solution relying on the fact that the exception thrown by the AWS SDK is stored within the produced spans and is accessible in the AwsSpanMetricsProcessor, where we generate Fault/Error metrics.
Describe alternatives you've considered
No response
Additional context
No response