Unlocking the Power of OpenTelemetry: Enhancing Design, Development...
summary
Experiment shows attaching an OpenTelemetry agent to Java services and running a collector container with a request generator and CloudWatch/X‑Ray backend exposes per-component behavior during DB failover and load tests; traces reveal requests that hang instead of erroring (missing timeouts) and metrics show DB reboot spikes at specific timestamps. They test eBPF and Kubernetes operator approaches, recommend sampling to avoid collection cost — a 50 req/s always-on test can cost about $60,000/month.
AI-written summary · about
chapters (13)
- 0:00OpenTelemetry benefits
- 4:11How OpenTelemetry works
- 7:46Auto-instrumentation features
- 10:16OpenTelemetry in failure testing
- 13:34Database failure setup
- 15:03Metrics anomaly analysis
- 19:03Trace analysis
- 22:19Load testing bottlenecks
- 23:45Cache server performance
- 26:38Key testing metrics
- 27:00Cost management with OpenTelemetry
- 28:09Metric limitations
- 30:00Key takeaways
related talks
49mAdding OpenTelemetry to Production Apps Lessons Learned
50mBootiful OpenTelemetry
47mHow I Solved Production Issues with OpenTelemetry (And How You Can Too)
31mTroubleshooting and Monitoring Production Applications using OpenTelemetry
30mPanel: Telemetry That Matters
22mOpen Telemetry for API Monitoring
38mThe State of OpenTelemetry
23mOpenTelemetry Auto Instrumentation for Effortless Observability