Add server span name feature to metadata #15221
Conversation
|
|
||
| * `HTTP_ROUTE`: Instrumentation that enriches HTTP spans with route information | ||
| * `HTTP_ROUTE`: Instrumentation that enriches HTTP spans with route information (e.g., `/users/{id}`). Sets both the span name and the `http.route` attribute. | ||
| * `SERVER_SPAN_NAME`: Instrumentation that enriches the HTTP server span name with controller, view, or operation information. This feature applies to instrumentations that update the server span name based on framework-specific information (like JSF view IDs or JAX-WS operation names) without setting the `http.route` attribute. The key distinction from `HTTP_ROUTE` is that `SERVER_SPAN_NAME` only updates the span name, while `HTTP_ROUTE` updates both the span name and the `http.route` attribute. |
There was a problem hiding this comment.
I think the main question here is whether we should always set the route, even when the set route does not match the requested url. If that is ok we could change these instrumentations to set the route. If it is not ok we'll probably have to change some other instrumentations to update only the span name. Hoping to get some guidance from @trask on this.
There was a problem hiding this comment.
If that is ok we could change these instrumentations to set the route.
Yeah, I like that our route matches the url wherever possible (i.e. instead of using the controller class / method name as the route).
But I think when this isn't possible, we should still capture http.route even if it doesn't match the url.
There was a problem hiding this comment.
But I think when this isn't possible, we should still capture
http.routeeven if it doesn't match the url.
Does the spec allow it? https://opentelemetry.io/docs/specs/semconv/registry/attributes/http/#http-route says
MUST NOT be populated when this is not supported by the HTTP server framework
And also mentions static and dynamic path segments which leaves an impression that it is intended for rest style paths. I believe that we have instrumentations where we set route to something that should identify the viewed page or invoked action but isn't necessarily what is in the request path. If this liberal usage of route is fine then we might not need SERVER_SPAN_NAME at all and could just update route to whatever we see fit and get the span name changed through that. If it is not fine then we might need to change a couple of instrumentations.
There was a problem hiding this comment.
I'm pretty sure Controller#action is fine if that's the best we can do (doesn't strictly have to be a rest style path). cc @lmolkova to keep me honest.
Views are more controversial in cases where the request isn't specifically for a view but rather a request that gets processed and afterwards delegated to some view for rendering.
3 participants
Related to #14096
Discussed here
Adds a new feature descriptor
SERVER_SPAN_NAMEto distinguish instrumentations that populate the span name, but don't also update thehttp.routeattribute.