We've all been there. You want to add observability to your Java service, so you pull in the OpenTelemetry SDK, configure exporters, annotate your endpoints, set up context propagation, and hope nothing breaks. It works, but it's a lot of ceremony just to see what your application is doing.

What if I told you there's a way to get full distributed tracing on a Java HTTP server without touching a single line of application code? No SDK, no agent, no bytecode manipulation. Just eBPF at the kernel level doing all the heavy lifting.

In this article, we'll walk through a minimal demo that proves exactly that.

The Problem

Adding observability to Java applications traditionally comes with a cost. You need to integrate the OpenTelemetry SDK, instrument your endpoints manually, configure exporters, and manage dependencies. For a large microservices system, this instrumentation overhead can be significant—both in terms of development time and runtime performance.

More importantly, not every application can be instrumented. Legacy services, third-party binaries, or quick prototypes like a simple HttpServer demo don't have the luxury of a rich framework with instrumentation hooks. What if the tracing happened below the application layer entirely?

That's where eBPF comes in.

What Is eBPF (And Why Should You Care)?

eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that lets you run sandboxed programs directly in the kernel space. Think of it as a way to hook into system calls, network events, and kernel functions without modifying the kernel source code.

For observability, this means you can intercept HTTP requests and responses at the syscall level—reading the raw bytes flowing through read() and write() calls on socket file descriptors. The application doesn't know it's being observed. No SDK, no agent, no sidecar with HTTP proxying. Just the kernel quietly watching traffic.

Grafana Beyla is an open-source tool that packages this eBPF magic into a drop-in sidecar. It automatically detects HTTP traffic, generates OpenTelemetry-compatible spans, and exports them to any OTLP-compatible backend.

The Architecture

The demo project is a three-container system orchestrated with Docker Compose:

Technology Choices

Notice there's no Maven, no Gradle, no Spring. The Java file is compiled directly with javac inside the Dockerfile. This is intentional—it proves that Beyla works on even the most bare-bones Java application.

The Java Server

The application is a single 47-line Java file. Two endpoints, zero dependencies:

The /slow endpoint sleeps for 500ms before responding. This is intentional—it creates a visible latency span in the distributed trace, making it easy to spot in Jaeger.

The Dockerfile is equally minimal:

The Beyla Configuration

Here's where the eBPF magic happens. The Beyla sidecar runs alongside the Java container with these key settings:

Two environment variables do all the work:

• BEYLA_OPEN_PORT=8080 — tells Beyla which port to monitor for HTTP traffic
• BEYLA_EXECUTABLE_NAME=java — tells Beyla which process to instrument

That's it. No code changes. No SDK dependency. Beyla hooks into the kernel-level syscalls and starts producing traces automatically.

The beyla-config.yml file is actually empty—all configuration is driven by environment variables. This keeps things clean and easy to understand.

The Jaeger Backend

Jaeger receives the traces via OTLP/gRPC on port 4317 and exposes its UI on port 16686:

Once the stack is running, open http://localhost:16686 to see the Jaeger UI.

Putting It All Together

Starting the stack is a single command:

To generate some traffic, run the test script:

This sends 10 requests (5 to /hello, 5 to /slow) with 1-second delays between each. Now head over to Jaeger and you'll see:

• Service name: pure-java-ebpf
• Individual spans for each HTTP request
• Latency breakdown showing the 500ms delay on /slow requests
• Full request/response timing without any code instrumentation

The traces appear because Beyla intercepted the HTTP traffic at the syscall level, parsed the HTTP protocol, and generated OpenTelemetry spans—all without the Java application knowing.

Key Insights

The most important takeaway from this demo is that eBPF-based observability fundamentally changes the instrumentation model. Instead of instrumenting your code (which requires SDKs, agents, and code changes), you instrument at the kernel level (which requires zero application changes).

This has several practical implications:

• Zero-code instrumentation — works on any Java application, including legacy services and third-party binaries
• No runtime overhead on the application — the tracing happens in kernel space, not in your JVM
• Protocol-agnostic — Beyla can detect HTTP, gRPC, SQL, and other protocols automatically
• Framework-independent — works with Spring, Quarkus, plain Java, or anything that uses standard syscalls

The tradeoff is that you need privileged access to the host kernel, which isn't always possible in managed Kubernetes environments. But for development, testing, and self-hosted infrastructure, it's a game-changer.

Conclusion

Getting distributed tracing on a Java application doesn't have to mean pulling in the OpenTelemetry SDK and rewriting your endpoint handlers. With eBPF and Grafana Beyla, you can get full observability on a plain Java HttpServer with zero code changes.

This demo is intentionally minimal—47 lines of Java, no frameworks, no build tools. But the principle scales to any Java application. The eBPF layer doesn't care about your framework; it cares about syscalls.

If you've been putting off adding observability to a service because of the integration overhead, eBPF might be the nudge you need.

Resources

• Grafana Beyla Documentation
• eBPF.io
• Jaeger Tracing
• OpenTelemetry OTLP Spec
• Source Code