Where eBPF fits in Kubernetes observability.

Most Kubernetes monitoring setups start the same way: a host-metrics agent like Node Exporter, some application instrumentation, and a log or trace pipeline — often an OpenTelemetry Collector feeding logs, metrics and traces to a backend. All of that is still useful. It just answers a specific set of questions, and there's a class of questions it was never designed to answer.

What the usual stack already tells you

Node Exporter reports host-level signal: CPU utilization, memory, disk I/O, network statistics, the general system-level metrics every cluster needs. An OpenTelemetry Collector receives, processes, enriches and exports logs, metrics and traces from whatever sources are already instrumented to send them. Together, that covers a lot of ground.

What it doesn't easily answer: which process opened this network connection, which Kubernetes service actually generated this traffic, where latency is being introduced between two services, which requests are failing and why, or what's happening inside the Linux networking stack itself — especially for services nobody has gotten around to instrumenting yet.

eBPF observes from inside the kernel

eBPF lets observability programs attach directly to points inside the Linux kernel, and in some cases to user-space applications, without changing the application's code. That gives visibility into network traffic, system calls, processes, TCP connections, HTTP/gRPC requests, service-to-service communication and kernel-level behavior — from a vantage point underneath the application, not inside it.

Two concrete examples worth knowing: Grafana Beyla uses eBPF to inspect application executables and the OS networking layer directly, generating RED metrics and trace spans for supported HTTP/S and gRPC services without any code changes. Cilium Hubble takes a related but different angle, using eBPF for network and service visibility across a Kubernetes cluster rather than per-application traces.

Layers, not competitors

The useful way to think about Node Exporter, eBPF agents and application-level OpenTelemetry is as three layers feeding the same pipeline, not three tools competing for the same job:

                    Kubernetes / Cloud Platform
                              |
             +----------------+----------------+
             |                |                |
             v                v                v
        Node Exporter      eBPF Agents       App OTel
             |                |                |
             |          +-----+-----+          |
             |          |           |          |
             |       Network     Process     Traces
             |       / Kernel     / App       / Metrics
             |          |           |          |
             +----------+-----------+----------+
                              |
                              v
                    OpenTelemetry Collector
                              |
                 +------------+------------+
                 v            v            v
               Logs        Metrics       Traces
                 |            |            |
                 +------------+------------+
                              v
                   Observability Backend
                 +------------+------------+
                 v            v            v
             ClickHouse      Mimir       Tempo
                              |
                              v
                           Grafana

Host metrics, kernel/network visibility and application telemetry all land in the same collector, the same backends, the same dashboards. eBPF doesn't replace that pipeline — it adds a layer underneath it that doesn't depend on every service being instrumented.

Where it actually helps

The real advantage isn't "more metrics" — it's where the telemetry gets collected. Instead of requiring every application to be modified, or every call to pass through a proxy, eBPF observes at the kernel and networking layer directly. That matters most when:

• You're running hundreds of services, not a handful.
• Teams use multiple languages and runtimes, so per-language instrumentation libraries don't give uniform coverage.
• Some services — often the oldest ones — can't easily be modified to add instrumentation.
• You need network visibility at the Kubernetes layer, not just inside individual applications.
• You want automatic RED metrics (rate, errors, duration) without an instrumentation rollout.
• You need to correlate infrastructure behavior with application behavior, not just look at each in isolation.

What it doesn't replace

eBPF isn't a substitute for application instrumentation. Beyla's own documentation is explicit about this: it provides generic metrics and transaction-level trace information, while language-level instrumentation remains the right tool when you need deeper application context — custom spans, business-logic-level detail, anything specific to what the code is actually doing. eBPF fills the gap around and underneath instrumentation; it doesn't make instrumentation unnecessary.

The actual question to ask

Put together, a stack built around this layering looks something like: Node Exporter for host metrics, eBPF for kernel, network, process and automatic application visibility, OpenTelemetry for collection and routing, Prometheus or Mimir for metrics, ClickHouse or a similar backend for logs and traces, Grafana for visualization. None of it is exotic — it's the same tools most platform teams already run, arranged so each one covers the layer it's actually good at.

For a platform running 50-plus services, the question worth asking isn't which single agent to standardize on. It's how to collect the right telemetry at the right layer, without the observability stack itself becoming another system that needs a team to operate. That's the design problem — and it's where eBPF earns a place, not as a replacement for what's already there, but as the layer that was missing.