otelmux: Add config option for a custom span name formatter

[hairyhenderson]

Currently, spans created in the otelmux instrumentation module are named after the route template (or the route regexp if no template is available). For example, given a route of /users/{id}, spans will be named /users/{id}.

This is fine in general, but it's impossible to differentiate between handlers for different methods. For example, if there are GET /users/{id} and DELETE /users/{id} handlers, the only way to differentiate spans is to visually inspect the http.method attribute.

In the otelhttp module, a WithSpanNameFormatter option function is available, which allows users to generate custom names on a per-request basis.

I propose adding a similar WithSpanNameFormatter option function to the otelmux module, with the difference that where otelhttp's function provides the handler's operation name, the otelmux version would provide the route name (to avoid needing to re-compute it on every request).

I have a PR already in progress that I will link to this issue.

[dmathieu]

The specification recommends using VERB ROUTE as the default span name for HTTP instrumentations.

So, while a WithSpanNameFormatter option sounds good, I think the default should be changed as well.

[hairyhenderson]

I'm open to changing the default (in fact, that would be ideal in my particular usage), but I can't find any reference to that form in the spec at the link you provided. I do however see:

Given an inbound request for a route (e.g. "/users/:userID?") the name attribute of the span SHOULD be set to this route. If the route does not include the application root, it SHOULD be prepended to the span name.

(from the HTTP Server semantic conventions section)

[dmathieu]

It's more a hint than anything explicit. But being consistent with net/http would be better IMHO.

Therefore, HTTP client spans SHOULD be using conservative, low cardinality names formed from the available parameters of an HTTP request, such as "HTTP {METHOD_NAME}".

[hairyhenderson]

I guess we're reading that sentence in the spec differently... That one in particular is about client spans (not server spans, which is what this issue is about), and it's explicitly talking about a low-cardinality name like "HTTP {METHOD}" (not "HTTP {METHOD} {PATH}" which would be higher-cardinality...

IMO the spec isn't clear enough, and should needs to be updated.

However, my goal here is not change the default, but instead to simply provide some more configurability. If the default can change later in a separate issue/PR/spec change, that's totally fine, but I'd much rather move this specific piece forward first.