Correlating Application and Database Performance Using OpenTelemetry
summary
OpenTelemetry’s sqlcommenter injects traceparent and driver metadata into SQL comments so client spans can be matched to server logs; SolarWinds wires OTel SDKs and parses sampled server query logs to map span IDs to query fingerprints and origin services. Major obstacles are prepared statement semantics and prepared statement cache behavior that strip or freeze comments (skipping injection breaks ORMs like Hibernate; emulation adds high overhead), and inconsistent implementations across JDBC, Python, Django/Flask, Java, Ruby and PHP. The prototype correlation UI works end-to-end but requires tradeoffs for performance and standardization.
AI-written summary · about
chapters (9)
- 0:00OpenTelemetry and SQL commenter
- 3:13SQL commenter explained
- 8:28Correlating traces and queries
- 9:54Prepared statements challenges
- 13:25Client-side caching impact
- 15:31Live demo walkthrough
- 16:36Future of trace propagation
- 18:22SQL commenter inconsistencies
- 21:54Summary
related talks
50mDemystifying Database Performance Issues with SQL Commenter
18mThe Future of Database Observability is Open: SQL Commenter Merges W...
22mEnhancing Database Observability With OpenTelemetry
28mCorrelating Signals in Opentelemetry: Benefits, Stories, and the Road Ahead
32mOpenTelemetry, databases, and machine learning
57mYour Distributed System is Talking to You: OpenTelemetry
52mGraphQL Observability with Elastic and OpenTelemetry
26mDemystifying Database Performance Issues with sqlcommenter