What does this PR do?

This pull request introduces a new configuration option that allows users to flexibly filter the spans traced in a GraphQL environment using dd-trace-go and gqlgen.

Motivation

Due to its nature of fetching graphed data, GraphQL tends to generate a large number of spans. This issue is particularly prominent in environments that combine dd-trace-go with gqlgen.

While existing options like withoutTraceIntrospectionQuery and withoutTraceTrivialResolvedFields can suppress span generation under certain conditions, they lack flexibility. They are insufficient for handling cases where the span count inevitably increases due to schema design, such as with Relay's GraphQL Pagination. Currently, there is no mechanism to dynamically control span generation based on criteria like a field's path.

If left unaddressed, this issue can lead to serious consequences:

• Performance Degradation: In environments like a Lambda extension running the Datadog Agent, the large volume of span data can lead to memory pressure and increased latency. Additionally, the high volume of spans being sent also significantly impacts performance.
• Poor APM Experience: When viewing traces in the Datadog APM, an excessive number of spans can cause the UI to become extremely slow, significantly degrading the debugging and analysis experience.

To resolve these problems, I have added a new configuration option that allows users to suppress span generation based on custom rules. This enables flexible control, such as disabling spans for resolvers with a specific field path, tailored to the project's requirements. Corresponding tests to validate this new configuration option have also been created.

Thank you.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• New code is free of linting errors. You can check this by running golangci-lint run locally.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.

Unsure? Have a question? Request a review!