-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make otel spans for RR clients more spec compliant #26694
Conversation
/cc @radcortez |
This comment has been minimized.
This comment has been minimized.
2f50b08
to
bcdfc3f
Compare
This comment has been minimized.
This comment has been minimized.
The test failures seems related to the change |
Yep. This is me juggling the separate changes and forgetting to rebuild and test both modules. |
This new output format is uses the route template which is only available after the other PR. |
At the very least, using this name format, the the handler order is tested. If the route template becomes unavailable again due to a code change it should show up in the OpenTelemetry tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests also needs to be fixed.
...main/java/io/quarkus/opentelemetry/runtime/tracing/restclient/OpenTelemetryClientFilter.java
Show resolved
Hide resolved
...main/java/io/quarkus/opentelemetry/runtime/tracing/restclient/OpenTelemetryClientFilter.java
Outdated
Show resolved
Hide resolved
bcdfc3f
to
fe31790
Compare
The tests are fixed now that the other PR is merged. |
This comment has been minimized.
This comment has been minimized.
fe31790
to
5d2dddb
Compare
...main/java/io/quarkus/opentelemetry/runtime/tracing/restclient/OpenTelemetryClientFilter.java
Outdated
Show resolved
Hide resolved
5d2dddb
to
56c4353
Compare
@radcortez As discussed this removes the custom extractor and replaces it with the default |
Thank you for the PR @kdubb! |
69b90c7
to
1049658
Compare
The OpenTelementry [Spec](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.10.0/specification/trace/semantic_conventions/http.md#name) is pretty clear about not using the URI as the default span name due to its high cardinality. > Instrumentation MUST NOT default to using URI path as span name… This PR creates span names that always include `HTTP` and then if available the method (e.g. `GET`) or `request`.
1049658
to
3ce1ac2
Compare
@radcortez Kevin would like me to backport this one. I'm not sure if we want to change this behavior in a micro. But maybe it makes sense given the previous behavior was not the one we wanted? |
I think it is ok to backport. |
Logic behind Rest Client span names has changed in quarkusio/quarkus#26694, this reflect changes and fixes related test failures in daily CI.
Logic behind Rest Client span names has changed in quarkusio/quarkus#26694, this reflect changes and fixes related test failures in daily CI.
The OpenTelementry Spec is pretty clear about not using the URI as the default span name due to its high cardinality.
Previously that's exactly what the span name extractor was doing.
Understanding that there are a number of issues and PRs related to reducing the cardinality of the client span names. After working in a live environment with telemetry enabled I've made some changes to make the span names compliant and easier to disambiguate in UIs like Jaeger.
HTTP
followed by the method, when available.Examples:
Always prepending the
HTTP <method>
disambiguates the client and server spans (which might share the same exact route template) in the UI. In the example below you can see how the edge service uses a client to call the data service. The client and server have the exact same route template but with the prefixing it easily distinguishable.This example might seem a little redundant since it's in the hierarchical format but we find it much easier to read. Also, in other flat formats the client and server are quite clear without drilling down.