-
Notifications
You must be signed in to change notification settings - Fork 175
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
Concerns about high cardinality in GraphQL span names #1361
Comments
@kaylareopelle since you folks have good ideas on how to move forward, are you opening a PR to change it? |
Hi @joaopgrassi! I can open a PR to change it! This is my first time interacting with the semantic conventions repo, so I wasn't exactly sure about the process. |
Perfect, thank you! I will assign this to you then. Feel free to reach out if you need help with anything. |
Hi @joaopgrassi! I've opened a PR for this change: #1389 |
Area(s)
area:graphql
Is your change request related to a problem? Please describe.
The Ruby SIG has some concerns about the cardinality of span names for the current GraphQL semantic convention.
@karmingc opened a PR on the opentelemetry-ruby-contrib repo to update the GraphQL span names.
This would update Ruby's existing name,
graphql.execute_query
, to the current semantic convention's format,<graphql.operation.type> <graphql.operation.name>
.During review, @robertlaurin raised a concern about unbounded cardinality for the span names if operation name and operation type are included:
The PR is currently blocked until we can come to a resolution about the appropriate span name.
Describe the solution you'd like
<graphql.operation.type>
seems sufficient, since the<graphql.operation.name>
is available in span attributes.Describe alternatives you've considered
The GraphQL semantic convention could also be updated to more closely match the DB span name, by adding a
SHOULD
instead of aMUST
for the name and/or add thelow_cardinality
caveat aboutdb.operation.name
.Additional context
This may be similar to #182, but since the problem focuses specifically on the span name, I thought it warranted a new issue.
The text was updated successfully, but these errors were encountered: