Why Does Continuous Profiling Matter to Developers?
summary
Demo runs an eBPF daemonset that profiles whole Kubernetes nodes and sends data to Elastic via OpenTelemetry; flame graphs reveal a Java service consuming ~50% of cluster CPU and a single endpoint spending ~90% of its CPU in JSON deserialization while GC work appears in separate stacks. Collector support and the OpenTelemetry profiling signal exist but remain experimental, and trace↔profile correlation is working in prototype form for per-endpoint hotspots.
AI-written summary · about
chapters (9)
- 0:00Continuous profiling intro
- 1:03Distributed apps observability
- 3:33Proxies and observability
- 8:26Observability pillars
- 12:55What profiling offers
- 15:27eBPF profiling in production
- 18:19Demo eBPF profiler
- 18:40Flame graphs explained
- 22:31Future of profiling
related talks
40mContinuous Profiling, the missing piece in your observability puzzle!
56mContinuous Profiling the missing piece in your observability puzzle
25mPerfect Match: Correlating Continuous Profiling with Distributed Tracing for Stronger Observability
24mCommunity Driven Breakout Session: Continuous Profiling
52mThe missing piece in your observability puzzle!
01h 13mContinuous Profiling: The Missing Piece in Your Observability Puzzle
23mThe State of OpenTelemetry Profiling- Damien Matthieu, Elastic & Felix Geisendoerfer, Datadog
36mContinuous Profiling in the Cloud-Native era