How do you implement distributed tracing across GraphQL resolvers?

Distributed tracing in GraphQL tracks the execution time and dependencies of every resolver in a query, correlating them with traces across microservices. The key challenge is that a single GraphQL query may fan out to multiple subgraphs, databases, and external services. Apollo Server supports Apollo Tracing (via the tracing extension in the response, now deprecated) and natively integrates with OpenTelemetry — each resolver creates a span with timing data, parent/child relationships, and metadata (field name, return type, arguments). At the Apollo Federation gateway level, the Router creates a root span for the incoming operation and propagates the trace context (traceparent header) to all subgraph requests. Backends like Jaeger, Datadog APM, and Honeycomb visualize the full distributed trace as a waterfall, revealing which resolvers are slowest and whether they run in parallel or serially within the query plan.