Currently http client instrumentation generates just one http client span to cover the initial request and any subsequent redirects:
|
span -> assertClientSpan(span, uri, method, responseCode).hasNoParent(), |
|
span -> assertServerSpan(span).hasParent(trace.getSpan(0)), |
|
span -> assertServerSpan(span).hasParent(trace.getSpan(0))); |
|
span -> assertClientSpan(span, uri, method, responseCode).hasNoParent(), |
|
span -> assertServerSpan(span).hasParent(trace.getSpan(0)), |
|
span -> assertServerSpan(span).hasParent(trace.getSpan(0)), |
|
span -> assertServerSpan(span).hasParent(trace.getSpan(0))); |
The http semantic conventions now state:
A CLIENT span SHOULD be created for each one of these physical requests.
No span is created corresponding to the "logical" (encompassing) request.
We should see if there are various instrumentation points that would allow us to capture each physical requests, and at least document which instrumentations do not follow this convention for redirects.
Currently http client instrumentation generates just one http client span to cover the initial request and any subsequent redirects:
opentelemetry-java-instrumentation/testing-common/src/main/java/io/opentelemetry/instrumentation/testing/junit/http/AbstractHttpClientTest.java
Lines 341 to 343 in fbc100a
opentelemetry-java-instrumentation/testing-common/src/main/java/io/opentelemetry/instrumentation/testing/junit/http/AbstractHttpClientTest.java
Lines 364 to 367 in fbc100a
The http semantic conventions now state:
We should see if there are various instrumentation points that would allow us to capture each physical requests, and at least document which instrumentations do not follow this convention for redirects.