Auto-instrumenting Java with eBPF: No JVM changes required

Getting OpenTelemetry into Java enterprise applications sounds like it should be easy, until you're staring at a third-party service you can't modify or a JVM you're not allowed to touch.

Java's dynamic compilation makes traditional eBPF probe placement hard. The JIT compiler moves code around, so the static memory addresses that eBPF relies on aren't stable. And the moment traffic hits TLS, which it does for every call to a cloud-managed service, every JDBC connection pool, every gRPC stream, you lose visibility unless you can decrypt in-kernel.

At GrafanaCon, I presented this work alongside Nikola Grcevski, Principal Software Engineer at Grafana Labs. The OpenTelemetry eBPF Instrumentation project (OBI) solves these constraints by correlating kernel-level events with application semantics, without any JVM modification. A small dynamically injected agent handles TLS decryption at the kernel boundary, so traces flow through encrypted connections without touching application code.

For Causely customers, OBI closes a gap that has blocked full topology coverage of Java estates. Once OBI is in place, Causely's causal model has the service dependency data it needs to identify the root cause service in a complex microservices incident and to map the blast radius accurately. In a Java application with 30+ interconnected services, that difference is between "something is slow in checkout" and "the Keycloak token validation service is the origin, and these six downstream services are affected."

eBPF and Java agents are complementary, not interchangeable. Where you need full semantic depth, for example custom business metrics, rich span attributes, the OTel JDK agent is still the right call. Where you can't touch the runtime, OBI covers the gap.

If you’d like to try OBI out on a sample application here are three realistic Java service topologies, all open source:

• Spring Boot + Keycloak + HTTPS — auth flows with encrypted external calls
• Spring Boot + gRPC + Google Pub/Sub — async messaging over TLS
• Quarkus + Postgres (TLS) + Kafka — polyglot data tier with encrypted DB connections

To learn more, watch the full GrafanaCon talk for a deeper walkthrough of how Nikola and team solved this challenge and the tradeoffs to consider when using OBI. Active development is tracked via Issue #880 and PR #891.