-
Notifications
You must be signed in to change notification settings - Fork 811
fix(instrumentation-asgi): remove high cardinal path from span name #2650
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
base: main
Are you sure you want to change the base?
Changes from all commits
076144c
251b3c1
5de29db
2da1dac
3ed3922
1c1b748
3f5758e
99923c2
498527f
95b0c48
f98022e
e2ff03e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good to see you @srikanthccv 👋 Is the span name being modified here supposed to follow the OTel HTTP server semconv or is it a more internal span? This change would be a breakage for anyone relying on this particular name, but if it's not the main
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Correct, specifically this part of the spec: If there is no (low-cardinality) {target} available, HTTP span names SHOULD be {method}. The
Agreed, but at the same time, it doesn't follow the semantic convention and spec guidelines for span names. I would say it's a necessary breaking change. Even from the end-user perspective, I believe this is a useful change; otherwise, IDs (from messaging-adjacent apps, in my experience) become part of the name, leading to no meaningful aggregation for server spans. In many deployments, the spanmetrics connector is used to derive metrics from these spans, which creates a problem.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Ya I agree, maybe we can just gate this behind the new semconv stability opt in like we do here? Lines 741 to 743 in bd3c1f2
How hard would that be to do?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let me take a look at it.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went through the code. It should be possible to keep the old and new name following the opt in mode. Let me know if we should make it opt-in.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi! 👋 There is a similar PR open for the aiohttp server instrumentation that will also introduce a breaking change to span name in order to follow semconv and reduce cardinality: #3896 (comment) . @aabmass should that PR also include an opt-in? cc @krnr
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO it would be better since the purpose of the opt-in was to prevent breaking people Any objections to that though? Does it work for you @srikanthccv ?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me 👍 |

Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
plus remove the protocol type from the span name if http?