server.port is required on HTTP client spans#16388
server.port is required on HTTP client spans#16388trask merged 27 commits intoopen-telemetry:mainfrom
server.port is required on HTTP client spans#16388Conversation
| if (serverAddressAndPort.getAddress() != null) { | ||
| attributes.put(SERVER_ADDRESS, serverAddressAndPort.getAddress()); | ||
| Integer port = serverAddressAndPort.getPort(); | ||
| if (port == null || port <= 0) { |
There was a problem hiding this comment.
pedantic, but....
| if (port == null || port <= 0) { | |
| if (port == null || port <= 0 || port > 65535) { |
breedx-splk
left a comment
There was a problem hiding this comment.
I know it's Draft but I'll leave a review anyway. This seems good to me, the port is often helpful. I think saying it's "required" might be overstating it (spec says SHOULD?)
this is for HTTP server spans for HTTP client spans it's marked as required |
|
|
||
| String fullUrl = stripSensitiveData(getter.getUrlFull(request)); | ||
|
|
||
| if (SemconvStability.v3Preview()) { |
There was a problem hiding this comment.
just curious why should we make this change only in the next major version, is there something that prevents us from doing it right now?
There was a problem hiding this comment.
yeah, it's confusing, due to this:
for some clarification what this means, see open-telemetry/semantic-conventions#722
There was a problem hiding this comment.
it got annoying, let's call it a bug fix 😅
it will only "break apart" existing timeseries if the app was connecting to both 80 and 443 on the same target server.address, which is pretty uncommon in practice
The declarative config approach via GlobalOpenTelemetry fails because: 1. ExtendedOpenTelemetry may not be on classpath (old API tests) 2. GlobalOpenTelemetry returns noop during static init Restore direct system property and env var reading.
0414767 to
c48bc26
Compare
Fix connectionErrorNonRoutableAddress test failures by adding default port resolution via HttpConstants.defaultPortForScheme() to getters that were missed in the initial pass: - async-http-client 1.8 and 1.9 - armeria 1.3 - reactor-netty 1.0
| public Integer getServerPort(HttpMethod request) { | ||
| HostConfiguration hostConfiguration = request.getHostConfiguration(); | ||
| return hostConfiguration != null ? hostConfiguration.getPort() : null; | ||
| if (hostConfiguration == null || hostConfiguration.getProtocol() == null) { |
There was a problem hiding this comment.
why is the hostConfiguration.getProtocol() value relevant here?
| } | ||
| return null; | ||
| } | ||
|
|
There was a problem hiding this comment.
wondering whether something like
@Nullable
public static Integer portOrDefaultFromScheme(@Nullable Integer port, Supplier<String> scheme) {
if (port != null && port > 0) {
return port;
}
return defaultPortForScheme(scheme.get());
}would help
There was a problem hiding this comment.
added, looks nice, does introduce a capturing lambda, but really should get jitted away
There was a problem hiding this comment.
The lambda is only useful when getting the scheme does something complicated that is worth skipping when the port is already known. I'd guess that in most (if not all) cases we could pass the scheme directly. If you don't like the capturing lambda you could add an overload with plain string.
… async-http-client-2.0, and aws-sdk-1.11
…rg.asynchttpclient.uri.Uri instead of java.net.URI)
…r simplify refactor
…java/io/opentelemetry/javaagent/instrumentation/apachehttpasyncclient/ApacheHttpAsyncClientHttpAttributesGetter.java
b99206d to
f775c81
Compare
f775c81 to
299f166
Compare
| } | ||
|
|
||
| @Nullable | ||
| public static Integer portOrDefaultFromScheme(int port, Supplier<String> scheme) { |
There was a problem hiding this comment.
not sure having this overload is worth it. Or could make the other one call this one.
*Issue description:* *Description of changes:* ADOT Java is upgrading its OpenTelemetry Java Instrumentation dependency to 2.26.1, which includes a change that adds the `server.port` attribute to all HTTP client spans ([upstream PR](open-telemetry/opentelemetry-java-instrumentation#16388)). the ADOT logic appends server.port to RemoteService if it exists, so this PR updates the java E2E tests to match the expected behavior. *Rollback procedure:* <Can we safely revert this commit if needed? If not, detail what must be done to safely revert and why it is needed.> *Ensure you've run the following tests on your changes and include the link below:* To do so, create a `test.yml` file with `name: Test` and workflow description to test your changes, then remove the file for your PR. Link your test run in your PR description. This process is a short term solution while we work on creating a staging environment for testing. NOTE: TESTS RUNNING ON A SINGLE EKS CLUSTER CANNOT BE RUN IN PARALLEL. See the [needs](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds) keyword to run tests in succession. - Run Java EKS on `e2e-playground` in us-east-1 and eu-central-2 - Run Python EKS on `e2e-playground` in us-east-1 and eu-central-2 - Run metric limiter on EKS cluster `e2e-playground` in us-east-1 and eu-central-2 - Run EC2 tests in all regions - Run K8s on a separate K8s cluster (check IAD test account for master node endpoints; these will change as we create and destroy clusters for OS patching) By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. --------- Co-authored-by: ADOT Patch workflow <[email protected]>
We missed this when moving to stable HTTP semantic conventions.