Provide option to use simplified query/mutation resource names for GraphQL spans

[goodspark]

Summary of problem

The current ddtrace GraphQL integration sets the full query as the resource name. This is fragile for monitoring and metrics purposes because a simple field change will result in a completely new name. In addition, it's kind of unsightly to see a resource name that's so long.

As an example, take a look at ddtrace-graphql. Normally, I'd just use that, but it's out of date and incompatible with the latest versions of ddtrace as well as graphql.

Which version of dd-trace-py are you using?

2.5.0

Which version of pip are you using?

24.2

Which libraries and their versions are you using?

graphene==3.3
graphql-core==3.2.4

How can we reproduce your problem?

Use the GraphQL integration and make a query while tracing is on.

What is the result that you get?

A span with the entire query as the resource name.

What is the result that you expected?

An option in the integration that allows me to instruct ddtrace to only use the query name (if available) as the resource name.

[marcotc]

Hey @goodspark, thank you so much for bringing this issue up and proactively opening a PR to make the changes you'd like to see implemented.

Your solution is certainly one way to clean up GraphQL observability and it comes at a time where we are actively working on improving GraphQL support for the Datadog APM product as a whole.

As you know, there are challenges around grouping "equivalent" queries (do two queries with the same name behave the same? Do all the fields have to be the exact same for them to be grouped together? If not, could we be grouping heterogeneous queries together by mistake, creating noisy resource groups that are not equivalent?). There are also challenges with single requests containing multiple queries/mutations.

Would you be open to having a chat with us to help us shape our GraphQL observability as a whole, in a way that addresses your/your company's use cases? We are more than happy to make sure your existing queries and future query evolution can be seamlessly visualized and monitored, and it would be invaluable for us to understand exactly when you consider two queries as the same and how you'd like to see them grouped when they evolve.

I've reached out to the email in your GitHub profile to continue our conversation if you'd like.
But if you are more comfortable sharing in detail your existing (and past) queries, your schema, and some resolver code here on GitHub that's also fine with us.