Expand span name guidelines for HTTP client spans

[stevejgordon]

Area(s)

area:http

Is your change request related to a problem? Please describe.

The guidance today for HTTP client span naming is:

HTTP span names SHOULD be {method} {target} if there is a (low-cardinality) target available. If there is no (low-cardinality) {target} available, HTTP span names SHOULD be {method}.

...

The {target} SHOULD be one of the following:

http.route for HTTP Server spans
url.template for HTTP Client spans if enabled and available (Experimental)
Other value MAY be provided through custom hooks at span start time or later.

This generally means that today, the instrumentation libraries use only the HTTP method for HTTP client span names. This leads to lots of spans named GET, POST, PUT, etc. These names offer little distinguishing value. Where this is particularly apparent is when the span.name is used to label spans in a trace waterfall, for example. Users can see that there were outgoing requests of particular verbs, but they need to drill into each one to see the details. Another common scenario for vendors is to group spans by name to make navigating easier. Again, having only the HTTP method in the name makes this too broad to be helpful.

Describe the solution you'd like

I want to open a discussion around the potential to update the guidance to recommend including at least the host in the span name and perhaps the port.

In most applications, the number of external hosts they communicate with over HTTP is expected to be reasonably constrained and unlikely to become particularly high-cardinality. The benefit for users is that out-of-the-box, the span names are more meaningful for grouping spans sent to a particular destination host. The span names are then also more helpful in the typical scenario of viewing spans on a trace waterfall.

Describe alternatives you've considered

No response

Additional context

NOTE: Raised initially in this Slack thread.

[trask]

This makes sense to me.

As @lmolkova mentioned in Slack:

we're using host:port as a fallback on DB and messaging span names

We'd just have to make this behavior opt-in for HTTP client spans due to backcompat, at least until (if) a major version bump of HTTP semconv occurs.