Wrong span names for server HTTP spans

[iNikem]

Can be considered as part of #233.

Several auto-instrumentations which create "server http" spans currently use simply "HTTP $method" as span name. This seem to violate the spec. E.g. Servlet2Advice and Servlet3Advice

[iNikem]

In contrast with situations, when there is some middleware that would produce nice span names (such as Spring MVC'c MethodHandlers), the instrumentations of plain servlets or Netty pipelines have only requested URL as a potential source of span names. Should we try to somehow normalise URL to remove potential high cardinality parts of it? E.g. SignalFx uses the following regex for this:

  // Matches any path segments with numbers in them. (exception for versioning: "/v1/")
  public static final Pattern PATH_MIXED_ALPHANUMERICS =
      Pattern.compile("(?<=/)(?![vV]\\d{1,2}/)(?:[^\\/\\d\\?]*[\\d]+[^\\/\\?]*)");

In case of servlets, we can potentially use class name + method name as well.

[trask]

I don't think(?) "HTTP $method" violates the spec for server spans:

If the route cannot be determined, the name attribute MUST be set as defined in the general semantic conventions for HTTP.

And in that general section:

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

I agree that "HTTP $method" is not a terribly helpful grouping for users though ☹️.

Maybe this is a discussion for oteps/specification?

[iNikem]

I think that specification is good enough on this topic. It is our current implementation that is lacking. We have to make more efforts in producing useful span names. Maybe giving a configuration option to choose if application owner wants to use url-based span names?

[iNikem]

Ok, one specific proposal: to change span names for servlet-based http spans to ServletClassName.methodName. Yes/No?

The same can be done for GrizzlyHttpHandlerInstrumentation as well. Yes/No?

[trask]

There's some related discussion on preferring route over class.method: open-telemetry/opentelemetry-specification#548

But that discussion doesn't address what to do if there's no route, in which case class.method seems like a better alternative to "HTTP $method".

So "yes" from me to your Yes/No questions above.