-
Notifications
You must be signed in to change notification settings - Fork 172
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
fix: update GraphQL span name to follow semantic conventions #966
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -98,11 +98,15 @@ def analyze_query(query:, &block) | |
|
||
def execute_query(query:, &block) | ||
attributes = {} | ||
attributes['graphql.operation.name'] = query.selected_operation_name if query.selected_operation_name | ||
attributes['graphql.operation.type'] = query.selected_operation.operation_type | ||
operation_type = query.selected_operation.operation_type | ||
operation_name = query.selected_operation_name | ||
|
||
attributes['graphql.operation.name'] = operation_name if operation_name | ||
attributes['graphql.operation.type'] = operation_type | ||
attributes['graphql.document'] = query.query_string | ||
|
||
tracer.in_span('graphql.execute_query', attributes: attributes, &block) | ||
span_name = operation_name ? "#{operation_type} #{operation_name}" : operation_type | ||
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. This doesn't make too much sense at the spec level. OpenTelemetry consistently discourages high cardinality span names, and this by definition is unbounded cardinality. Edit to add context. GraphQL operation name is just a free form label supplied by the client caller. There's absolutely no constraints, if we don't put the raw path in an http server span name, I'm not at all convinced we should all operation name here. Fwiw 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. @robertlaurin Did you open an issue in the semantic-conventions repo about this? 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. It does not seem like that came up in the PR reviews: open-telemetry/opentelemetry-specification#2456 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. @robertlaurin - Could you open an issue in the semantic-conventions repo about this? 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. @karmingc, I apologize for how long the cycles on this PR have been. I brought this concern to the Semantic Conventions repo. Issue: open-telemetry/semantic-conventions#1361 If you have any feedback on the proposed span name, let's discuss it in the PR. (cc @robertlaurin @arielvalentin) |
||
tracer.in_span(span_name, attributes: attributes, &block) | ||
end | ||
|
||
def execute_query_lazy(query:, multiplex:, &block) | ||
|
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.
There's a MUST-level part of the spec requiring
operation.type
to be one ofquery
,mutation
orsubscription
. We weren't checking it previously. I'm not certain we need to validate it now.Will the gem only send those operation types? What are your thoughts @karmingc?