What Could Go Wrong with a GraphQL Query and Can OpenTelemetry Help?
summary
Shows concrete instrumentation steps: NodeJS GraphQL is wired to the OpenTelemetry collector, traces export to Jaeger and metrics to Prometheus via the span‑metrics connector, and RED (rate, errors, duration) metrics appear in dashboards. Demonstrates finding an upstream 400 that propagates as a 500, and that GraphQL often returns HTTP 200 with errors captured only in the body — solved by adding a graphql.error.message span attribute. Detects an N+1 by observing 27 HTTP GET calls for one query and recommends DataLoader fixes.
AI-written summary · about
chapters (12)
- 0:00GraphQL challenges and OpenTelemetry
- 2:49What is GraphQL vs REST
- 5:22Setting up the travel application demo
- 7:07Instrumenting GraphQL with OpenTelemetry
- 8:54Monitoring GraphQL with Jaeger
- 9:39Troubleshooting upstream errors
- 11:05Resolver errors and HTTP 200 issues
- 12:30Manual instrumentation for errors
- 13:13Performance challenges in GraphQL APIs
- 14:56Detecting N+1 queries
- 16:41OpenTelemetry limitations
- 17:24Future improvements
related talks
32mWhat Could Go Wrong with a GraphQL Query & Can OpenTelemetry Help?
52mGraphQL Observability with Elastic and OpenTelemetry
08mGraphQL Observability
32m200 Is Not OK: Strategies for Tracing Partial Responses w/ GraphQL
26mBeyond HTTP 200: Observability With GraphQL
25mUnlocking Insights: Navigating the World of GraphQL Observability
21m200 NOT OK: High-Resolution Observability
37mBeyond Getting Started: Using OpenTelemetry to Its Full Potential