-
Notifications
You must be signed in to change notification settings - Fork 275
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
Keep router span name consistent and do not use operation name #5261
Comments
We have followed the otel spec here: https://opentelemetry.io/docs/specs/semconv/graphql/graphql-spans/
I think this would be a feature request to disable such behaviour. |
https://docs.datadoghq.com/tracing/glossary/#resources Datadog requires to use static span name with |
OK, sounds like we should add the config. I do think the behaviour mandated in the spec for changing the span names is really strange, and it's also noticeable that other parts of the spec don't seem to follow this pattern. Suggest we support the following config: telemetry:
instrumentation:
spans:
router:
otel.name: router #
We could shift the logic out of the telemetry plugin into a selector maybe? @bnjjj WDYT? |
I agree with your solution @BrynCooke, the main reason it doesn't work today is because it's kind of an ordering rule when at the end it takes the name directly set in the span_builder here, I already have to make that kind of fix for |
@bnjjj and @BrynCooke Are there implications or user-facing-observed-changes if we were to just change that ordering around? |
no |
Is your feature request related to a problem? Please describe.
The span name for the service entry point for Apollo Router OpenTelemtry tracing is
<service_name>:<operation_name>
. This causes many issues with my dashboard linking in DataDog as I now have a high cardinality of spans.Describe the solution you'd like
It would be nice if instead we used just a standard name like
<serice_name>:router
or if this was configurable so I could set the span name myself. I would also like the operation name to be a configurable span attribute as I have to go to the supergraph to see this today. This is before the GraphQL parsing so what ever logic is being used to get the operation span name today should just become the attribute valueDescribe alternatives you've considered
I could maybe use a custom collector and transform all the spans
The text was updated successfully, but these errors were encountered: