Improving OpenTelemetry Support for GraphQL – Call for Contributors

[PascalSenn]

The current OpenTelemetry specification for GraphQL is quite minimal spans.yml, and there has been little progress in expanding it. Several issues and PRs related to GraphQL tracing remain open but have become stale:

• Issue: Allowance for using Stored Operation IDs for Semantic conventions for GraphQL Server open-telemetry/semantic-conventions#1011
• Issue: Improve GraphQL semantic conventions open-telemetry/semantic-conventions#182
• PR: Extends GraphQL Spans open-telemetry/semantic-conventions#562

Proposal
To improve observability for GraphQL, we can collaborate on defining a more comprehensive OpenTelemetry specification and submit a final proposal to the OpenTelemetry semantic conventions repository. This would ensure that GraphQL tracing aligns with best practices and provides better insights for developers.

Call to Action
If you're interested in contributing to this effort - please comment on this discussion. The goal is to gather a working group, align on improvements, and submit a well-structured proposal to OpenTelemetry.

Let's push this forward together! 🚀

[benjie]

✋

[EmrysMyrddin]

I'm very interested to contribute in this effort ! We are currently in the process of improving OTEL support in GraphQL Yoga and Hive Gateway :-)

[magicmark]

👍

[BrynCooke]

I am interested to contribute. We've had some experience with the Apollo Router adding OTEL support, and getting the right balance that doesn't create large APM bills for users is tricky.

[timbotnik]

Also interested in this! I'd be representing Apollo Studio and would like to help ensure we align on the OTel tooling for GraphQL.

[bnjjj]

Also interested ! I worked closely with @BrynCooke on OTEL support in Apollo Router

[danstarns]

@PascalSenn

Relating to our work on GraphQL Debugger here:

• Standardize OTEL GraphQL Attributes rocket-connect/graphql-debugger#9

We needed more attributes added to each span to reconcile back to a versioned schema. In particular, something specific was the schemaHash that helped us do this.

See our full typeset here: https://github.com/rocket-connect/graphql-debugger/blob/b5639a3039ccb55933dc5d4362a797628a09901e/packages/types/src/opentelemetry/attribute-names.ts#L1

How we append the attributes at runtime: https://github.com/rocket-connect/graphql-debugger/blob/b5639a3039ccb55933dc5d4362a797628a09901e/packages/opentelemetry/src/info-to-attributes.ts#L6

[BrynCooke]

On a related note I'd very much like to see us have a hash for the graphql.document rather than the document itself.

graphql.document, which is currently a recommended attribute - can be gigantic, and some of our users quickly ran into situations where this was not only costing them a lot in terms of APM costs, but on profiling it was noticed that shipping this attribute across the wire was a significant drain on resources.

It's be great if this was changed to opt-in and then we introduce graphql.document.hash or something similar.

[PascalSenn]

@danstarns @BrynCooke @bnjjj @timbotnik @magicmark @EmrysMyrddin @benjie

Would the following date & time work for you the first open telemetry graphql work gorup?
🎉 https://www.timeanddate.com/worldclock/converter.html?iso=20250424T170000&p1=136&p2=268&p3=179&p4=224

[benjie]

I've cancelled the GraphQL-over-HTTP WG to make space GraphQL-over-HTTP WG moved to 11am Pacific going forward.

[benjie]

I've set up the WG repo and you can add yourself to the agenda here: https://github.com/graphql/otel-wg/blob/main/agendas/2025/04-Apr/24-otel-wg-april-2025.md

[eli0shin]

I would love to join if you are still open to new members.