Refactor ServerSpanNaming (in preparation for http.route)
#4852
Conversation
mateuszrzeszutek
requested review from
anuraaga,
iNikem,
jkwatson,
laurit,
pavolloffay,
trask and
tylerbenson
as code owners
|
Have you considered that what we use as server span name is not always a route. For example wicket instrumentation sets server span name to an arbitrary value whose only purpose is to identify the visited page. |
Oh, didn't know that. Most of the web libraries that we instrument use route to update the name I think. |
A few: grails, jaxws, spring-ws, tapestry, vaadin, wicket. For non-rest frameworks we need to invent some kind of name that describes the operation. This name isn't necessarily even deduced from url. For example in case of jax-ws it is a soap xml document that is posted that determines what is invoked. |
Thanks, I'll take a look at these. Anyway, this PR is still valid even with these reservations -- in the worst case I'll just have to think of how to split the server name from the route so that the code still makes any sense 😅 |
| context = ServerSpanNaming.init(context, CONTAINER); | ||
| return new AppServerBridge.Builder().init(context); | ||
| }) | ||
| (context, request, attributes) -> new AppServerBridge.Builder().init(context)) |
There was a problem hiding this comment.
should ServerSpanNaming.get() context customizer be added here? I notice it's missing in some cases and included in others, but not clear to me why
There was a problem hiding this comment.
It actually is added, via the ServletInstrumenterBuilder class.
All server instrumentations should add ServerSpanNaming.get()
| context = ServerSpanNaming.init(context, CONTAINER); | ||
| return new AppServerBridge.Builder().init(context); | ||
| }) | ||
| (context, request, attributes) -> new AppServerBridge.Builder().init(context)) |
| contextToUpdate = | ||
| helper().updateContext(contextToUpdate, httpServletRequest, mappingResolver, servlet); |
There was a problem hiding this comment.
the previous behavior was nice of setting everything up correctly in startSpan (e.g. correct span name and correct ServerSpanNaming.Source)
though I guess it doesn't matter in practice most of the time since we instrument so many servlet containers that we probably don't startSpan that often here
There was a problem hiding this comment.
the previous behavior was nice of setting everything up correctly in
startSpan(e.g. correct span name and correctServerSpanNaming.Source)
Honestly I found setting the Source a bit confusing: what if your span name was HTTP GET with FILTER as a source? If you had another filter trying to update the name to /abc it wouldn't, because it was a shorter name - which I'm not so sure is correct; setting the source seems to be closely connected to the route, not necessarily the span name (even if they're the same in most cases). (Although I'm not sure how "real" this example is 😅 )
Also, the only 2 instrumentations I found that have access to the route in the beginning are armeria and servlets; and servlet span name will usually be updated by something like spring or jax-rs. Which implies that for most cases, the route should be extracted on end() (and span name updated somewhere in the meantime).
…elemetry#4852) * Refactor ServerSpanNaming (in preparation for http.route) * fix tests * Add ServerSpanNaming to all HTTP server instrumentations * fix tests
First part of #442
I've refactored
ServerSpanNaming(mostly in the servlet instrumentation) so that it's called every time we include the route in the span name. In next PRs I want to remove/deprecate theHttpServerAttributesExtractor#route()method and only useServerSpanNaming(which will be renamed toHttpServerRouteprobably) to set the route as span name & attribute.