High HTTP span name cardinality with opentelemetry extension

[hacst]

Describe the bug

When using the new opentelemetry extension and observing HTTP client and server spans their names contain the full path of the URI. This means if for example an ID is part of a URI it ends up being part of the name of the span. The OTEL specification states that such high cardinality names are unsuitable for spans: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md#name HTTP. More specifically for it states "Instrumentation MUST NOT default to using URI path as span name".

Unfortunately the current implementation does not comply with that:

quarkus/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/tracing/client/ClientTracingFilter.java

Line 41 in 3d8c3d3

SpanBuilder builder = tracer.spanBuilder(requestContext.getUri().getPath().substring(1))

quarkus/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/tracing/vertx/VertxTracerFilter.java

Line 51 in 3d8c3d3

SpanBuilder builder = tracer.spanBuilder(routingContext.request().uri().substring(1))

The effect of the current implementation in backends like jaeger is that the spans cannot be grouped and the ability to view spans for a operation becomes unusable.

Fixing this for the server is probably similar to the solution for #15044 so maybe the work done based on that can be re-used.

Expected behavior

Span names matching the HTTP conventions described in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md#name .

Actual behavior

The full path becomes part of the name producing high cardinality span names.

To Reproduce

Add the extension to any project creating or receiving requests with a variable parameter in the URL and observe the names of HTTP spans created.

Quarkus version or git rev

1.13.3.Final

[quarkus-bot]

/cc @kenfinnigan

[kenfinnigan]

We aware of the problem, and we're in the process of determining the appropriate path handling for metrics and traces that can utilize the same name

[hacst]

Great. Thanks a lot for your work on this extension.