opentelemetry VertxTracingAdapter creates duplicate and high cardinality spans for requests

[hacst]

Describe the bug

Kind of a follow-up for #16952 . When using the opentelemetry extension and observing HTTP spans created for a rest-client request Quarkus creates two client spans. One based on rest-client knowledge in ClientTracingFilter with a proper templated name and another span basically duplicating the information at the vertx level in VertxTracingAdapter. The duplicate span also is not aware of the template so it uses the full name instead (#16952 explains why that is problematic).

Interestingly enough it looks like the Kafka extension encountered a similar problem and special handling was introduced:

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

Lines 187 to 197 in 9f43498

	if (policy.equals(TracingPolicy.IGNORE)) {
	/*
	* SmallRye Reactive Messaging with Kafka is responsible for creating spans for outgoing messages.
	* In this SPI call there is no way to know whether it has happened.
	* The current approach to prevent duplicate spans is for the Kafka client in SmallRye Reactive Messaging
	* to set TracingPolicy.IGNORE
	* Disabling tracing in Quarkus will not be done with TracingPolicy.IGNORE,
	* allowing it to be used for this purpose.
	*/
	return null;
	}

I cannot find where the Kafka extension actually uses this though.

Expected behavior

Ideally only one client span is created for each outgoing request. The span has the template known from the rest-client as its name.

Actual behavior

Two spans are created. One of which has a high cardinality name equal to the requested URL.

To Reproduce

A test sending a rest client request will reproduce the behavior.

Quarkus version or git rev

2.0.0.Final

[quarkus-bot]

/cc @Ladicek, @kenfinnigan

[hacst]

Another thing I noticed is that the http.url attribute ClientTracingFilter sets contains the userinfo portion of the URL to which https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md#common-attributes states "http.url MUST NOT contain credentials passed via URL in form of https://username:[email protected]/.". Not 100% they also mean clients there but I think it is both. I can open another issue for this if required.

PS: Very sorry for reporting this so late. I'm very aware that I should've tested beforehand but I only now found some time.

[kenfinnigan]

@hacst please provide a reproducer as I've used tracing with REST Client and not seen duplicate spans.

[hacst]

Turns out the problem was on my end. Now everything works as intended. (the url.http containing credentials is still true though)