HTTP Client Span Names

[jamal]

Hi all! I wanted to try to start a quick conversation around the HTTP client span names provided by most instrumentations today. I know that we need to strike a balance between something that is specific enough, but provides low cardinality, and is not taxing performance. But, most instrumentations today seem to just be providing HTTP {method} as the span name.

I was wondering if it would make sense to include some additional information, such as the peer name, by default. I feel that this would at least allow for separation by external service which would provide far more valuable information. I noticed that in the base HttpClientTracer we are already using the URI from the implementation to set net.peer.name. Would there be any reason to not use this to generate a more unique span name, such as HTTP {method} {hostname}?

Thanks!

[trask]

hey @jamal, would you mind opening an issue for this in the specification repo? we would probably want to see the spec guidance for http client span names clarified to include this as a recommendation before making the change in this repo.

[genesiss]

Hi, here is a link to the specification: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#span

There is an example table which says that GET is too broad of a name. Here is an example from Elastic APM, which shows why is this a problem when interpreting results: https://i.stack.imgur.com/ibxuN.png

[genesiss]

Hi, I see.. the link I posted above (same specification) somehow contradicts that.

Here is an example what I see in Azure Insights if I use Open telemetry instrumentation and Azure Opentelemetry exporter:

And here it is what I see when using Azure agent for instrumentation and export:

The second one is clearly more readable and informative than first one.

[laurit]

@genesiss These really don't contradict each other. As you have pointed out HTTP GET is a pretty bad name as it doesn't give any information about what the actual operation is. The problem here is that in general case we don't really know which part of the request is the operation name or which part has high cardinality in which case the spec requires us to use a guaranteed low cardinality name such as HTTP GET. To improve the situation we need to instrument higher level frameworks where it is possible to deduce a better operation name. For example with JAX-RS we can use @Path annotations and get nice operation names like /get/{id}.

[trask]

The second one is clearly more readable and informative than first one.

This is due to different exporter mappings, not the underlying instrumentation.

[knutwannheden]

I also just stumbled across this. I did a quick search for a corresponding issue, but couldn't find anything except #6299, which is related.

Looking at

opentelemetry-java-instrumentation/instrumentation-api-semconv/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/http/HttpSpanNameExtractor.java

Lines 48 to 53 in 892fb8a

	private String extractRoute(REQUEST request) {
	if (getter instanceof HttpServerAttributesGetter) {
	return ((HttpServerAttributesGetter<REQUEST, ?>) getter).route(request);
	}
	return null;
	}

it doesn't seem like any work has been done yet. Should I report an issue for this?

In contrast, gRPC appears to have dedicated client and server span name extractors as of #5244.

[trask]

(x-posted to #6526)