Community Driven Breakout Session: eBPF and Auto-Instrumentation
summary
Extended Berkeley Packet Filter hooks into the Linux kernel to run tiny C programs, store results in ebpf maps, and emit fleet‑wide signals without changing app code, but it lacks application context so correlating traces and spans is hard. Production users mention Pixie Labs and Parca running with eBPF, AWS experiments send profiling via OTLP to CloudWatch, and Netflix built flame graphs from kernel stack samples years ago. Auto‑instrumentation promises quick baseline visibility but faces kernel version, symbol, and sampling tradeoffs.
AI-written summary · about
chapters (6)
- 0:00Start
- 3:46Tldr of Ebpf
- 4:09Extended Berkeley Packet Filter
- 7:27What Does Ebpf Stand for Extended Berkeley Packet Filter
- 25:13Continuous Profiling
- 27:50Brownfield Monitoring
related talks
40mPanel Discussion: eBPF: A New Era in Cloud Infrastructure Tools
31meBPF for Observability: The Good, the Bad, and the Ugly
32mExploring the Power of eBPF for System Observability- 40mPanel Discussion: eBPF: A New Era in Cloud Infrastructure Tools
16mWhy Everyone Should Care About eBPF
36meBPF for Runtime Security
32meBPF: BPF kernel infrastructure
31mBridging Dev and Ops with eBPF: Extending Observability Upwards and Downwards