200 NOT OK: High-Resolution Observability
summary
HTTP status codes fail for GraphQL because of partial success, so use OpenTelemetry plus an Apollo server plugin that parses responses, increments a counter metric and attaches a tier dimension derived from an impact directive; lock directives behind an operation registry to prevent abuse. Define tiers (tier 1 = money movement) on fields, compute the highest-failed tier per operation, and send that as a metric label. The built solution moves from low to high-resolution observability and produces actionable, urgency-aware alerts.
AI-written summary · about
chapters (11)
- 0:00Introduction and setup
- 1:27What is observability
- 4:57HTTP status codes and GraphQL
- 9:10Problem with 200 OK in GraphQL
- 11:56OpenTelemetry for error tracking
- 13:19Low resolution observability
- 15:04Introducing impact levels
- 17:36Medium resolution observability
- 18:38High resolution observability
- 19:42GraphQL vs REST observability
- 20:49Q&A and closing
related talks
32m200 Is Not OK: Strategies for Tracing Partial Responses w/ GraphQL
26mBeyond HTTP 200: Observability With GraphQL
18mWhat Could Go Wrong with a GraphQL Query and Can OpenTelemetry Help?
25mUnlocking Insights: Navigating the World of GraphQL Observability
32mWhat Could Go Wrong with a GraphQL Query & Can OpenTelemetry Help?
52mGraphQL Observability with Elastic and OpenTelemetry
23mGraphQL Observability
38mThe Murphy's Laws of Observability