OpenTelemetry or eBPF? That is the Question
summary
eBPF provides broad, automatic instrumentation-less observability across the OS and runtimes while OpenTelemetry supplies SDKs, a collector and a standard for detailed, application-level data and true distributed traces; eBPF tools like Pixie, Hubble, pyroscope and parka deliver service maps, throughput/latency metrics and continuous low-overhead profiling, and can export OTLP to OpenTelemetry collectors; distributed tracing currently favors OpenTelemetry because of context propagation requirements, so combine eBPF as a safety net with OpenTelemetry for detailed, propagated traces.
AI-written summary · about
chapters (13)
- 0:00Start
- 1:43eBPF Landscape is Large
- 2:41What is OpenTelemetry?
- 4:04A Typical OpenTelemetry Set-up
- 6:53Automatic vs Manual Instrumentation
- 8:11Automatic Instrumentation Examples
- 13:35Why Distributed Tracing is Hard
- 14:43Approaches Compared
- 15:32Use Case: Profiling
- 17:51eBPF Instrumentation Matrix
- 18:48Creating Spans With OpenTelemetry
- 23:38The Reality of Software Systems
- 24:34Key Take-Aways
related talks
34mNetwork Observability with eBPF and OpenTelemetry
31meBPF for Observability: The Good, the Bad, and the Ugly
37meBPF: Revolutionizing Observability and Telemetry for Modern Applications
18mOpenTelemetry and Observability: What, Why, and Why Now?
45mSimplifying Instrumentation in complex systems at scale with Open Telemetry
22mUnified Observability
30mOpenTelemetry 101
31mZero instrumentation observability with eBPF