Java Agent vs. eBPF: A Deep Dive into OpenTelemetry Instrumentation Technologies
summary
Local Kubernetes demo instruments a Java name‑generator and a Node front end using OpenTelemetry Java instrumentation and OpenTelemetry eBPF instrumentation; eBPF runs as a single binary exposing Prometheus on :9400 and attaches at runtime, the Java agent requires JVM startup. Under 40 concurrent requests against Tomcat limited to 10 threads the front end and eBPF show 0.8 req/s baseline with 95th ≈800 ms jumping to ~3.5 s, while the Java agent stays at ~800 ms because it measures service time not queue time. Tracing and log context propagation fail for reactive Java with eBPF; recommendation is baseline eBPF + JVM agent for depth.
AI-written summary · about
chapters (18)
- 0:00Java agents vs eBPF intro
- 1:30Child name service demo
- 4:17Instrumentation goals
- 7:50Java agent with ByteBuddy
- 8:54eBPF with BA and OpenTelemetry
- 11:27Complexity differences
- 13:55Key differences
- 14:17eBPF language independence
- 15:40Kubernetes metadata in eBPF
- 17:51Response vs service time
- 22:12HTTP path challenges
- 25:22JVM symbol table in eBPF
- 27:30Distributed tracing limits
- 31:21Log correlation
- 32:44Production impact comparison
- 33:51Protocol support speed
- 35:18Recommended approach
- 38:07Conclusion & Q&A
related talks
24meBPF Application Instrumentation for Java: Challenges, Design, and Real...
30mAgentless instrumentation with eBPF, Prometheus and OpenTelemetry
31mZero instrumentation observability with eBPF
49mDistributed Tracing in Java? OpenTelemetry for the Rescue!
31mUnlocking the Power of OpenTelemetry: Enhancing Design, Development...
24mWhy Does Continuous Profiling Matter to Developers?
35mAn Exemplary Path: Leveraging EBPFs and OpenTelemetry To Auto-instrument for Exemplars
30mInstrument Your Java Applications with OpenTelemetry!