-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove HTTP method from span name #733
Comments
A screenshot might help, if you are able to share. My initial reaction is that I would think I think we might not be mapping labels correctly. Here are the "special" labels in cloud trace: https://cloud.google.com/trace/docs/trace-labels. That list includes |
The list view looks something like this The fact that I realized I accidentally opened the issue in the Go repo while looking at a JS app, though the span name itself is the same in both. But JS does seem to map more Notably, my span does have |
I reached out to the appropriate team. I'll let you know if I get any updates. |
Response: The URL field in that table is actually mis-labeled. It refers to the name of the root span for that trace. The "URL" was originally designed to work well with Google App Engine, in which the name of the root span is the URL being invoked. I also realized while looking into it that the table is a table of traces, not a table of spans, so there could be cases where a trace has many spans with an http.url attribute. Still... It would be nice if it wasn't misleading |
Thanks for confirming - if the intent was to display a URL, then perhaps the logic could be updated to refer to an attribute when available. In any case it seems to clearly not be well aligned with OTel semantic conventions right now since there is always stuttering between the http method attribute and span name.
Indeed this causes some issues. We have one frontend using go with gin and I'll check how it looks, but our main frontend is actually NestJS. I have this gross hack to make that list view even somewhat useful, otherwise it was all just One thing I noticed since I experimented with cloud propagator with an http load balancer, the list reflects the root span if present, or otherwise it seems to be an arbitrary span from the trace if missing (load balancer doesn't export so root span is always missing when adding that propagator, I thought this could still be ok but not with the randomness introduced to the list view).
|
OTel semantic conventions dictate the format
{method} {route}
for server span nameshttps://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md#name
In the Trace UI, I see the HTTP method displayed under
Method
, as well as{method} {route}
underURL
. I suspect this is because cloud trace expects the span name to be only the URL, not method and URL. Does it make sense to check if there is anhttp.method
attribute present and trim off{method}
prefix from the name where it is? If there is no route available, it will just be{method}
, so to avoid an empty span name it should only happen when there is{method} stuff
The text was updated successfully, but these errors were encountered: