Observability rollouts used to start the same way: pick an agent per language, wire an SDK into every service, redeploy the fleet, and argue about sidecar memory. eBPF reorders the work - the kernel already sees every syscall and socket, and one node agent can export that truth for every workload at once. Here is how it works, which tools to run, and where it honestly stops.
What does zero-instrumentation observability actually mean?
Zero-instrumentation observability means collecting metrics, traces, service maps, and profiles by loading eBPF programs into the Linux kernel instead of adding SDKs, language agents, or sidecar proxies to applications. The kernel already mediates every syscall, socket, and scheduler event; eBPF exports that ground truth without touching application code, images, or deployment manifests.
Zero refers to code changes, not to work. You still deploy a collector DaemonSet, run storage, and build dashboards - what disappears is the per-service, per-language instrumentation project that stalls most observability programs. A fleet of 200 services in five languages gets baseline RED metrics (rate, errors, duration) in an afternoon instead of a quarter. What you give up is semantic depth: the kernel sees what your code does, never what it means. That trade shapes everything below.
How does eBPF collect telemetry without code changes?
eBPF programs attach to kernel hook points - tracepoints for syscalls and the scheduler, kprobes on kernel functions, uprobes on user-space library functions - and copy small structured events into ring buffers. A userspace collector reassembles those events into HTTP requests, SQL queries, and spans, then exports standard OpenTelemetry data.
The interesting part is protocol reconstruction. By hooking the socket read and write paths, the collector captures request and response payloads and parses them against protocol grammars - HTTP/1.1, HTTP/2, gRPC, MySQL, PostgreSQL, Redis, Kafka, DNS - rebuilding each transaction with latency, status, and peer identity. Kubernetes enrichment then maps the socket to a cgroup, the cgroup to a container, and the container to a pod and namespace.
Two properties make this safe to run fleet-wide:
- ▸The verifier. Every eBPF program is statically checked before loading: bounded execution, no arbitrary memory access, no way to crash the kernel from a logic bug.
- ▸CO-RE portability. Programs compile once and relocate against each kernel's BTF type information, so one agent binary runs across kernel versions without per-node compilation.
We covered the underlying eBPF machinery in more depth in eBPF in Production: Rewiring Networking and Observability; this piece stays on the observability workflow.
Which eBPF observability tools should you evaluate in 2026?
A current shortlist: OpenTelemetry eBPF Instrumentation - grown from Grafana Beyla, which was donated to the OpenTelemetry project - for RED metrics and traces; Pixie for in-cluster debugging with full protocol traces; Coroot for SLO-centric service maps; Odigos for distributed-tracing rollout; Parca or Grafana Pyroscope for continuous profiling; Cilium Hubble for network flows.
One-line differentiators, with the caveat that project status shifts fast enough that you should verify before committing:
- ▸OpenTelemetry eBPF Instrumentation (Beyla lineage) - auto-instruments HTTP and gRPC services for metrics and traces, exports native OTLP, fits an existing Grafana or OTel stack with minimal ceremony.
- ▸Pixie - CNCF sandbox tooling that keeps full-fidelity protocol traces in-cluster with short retention; superb for live debugging, not a long-term telemetry store.
- ▸Coroot - builds service maps and ties them to SLOs and cost; open-core, opinionated, quick to first value.
- ▸Odigos - focuses on rolling out distributed tracing across a polyglot fleet by combining eBPF with OTel pipelines.
- ▸Parca and Grafana Pyroscope - always-on CPU profiling via eBPF, typically low single-digit overhead, answering which function burns the CPU across the whole fleet.
- ▸Cilium Hubble - network-flow observability if you already run Cilium; pairs naturally with the eBPF dataplane described in The Programmable Network: eBPF Observability and Network Automation in 2026.
Pick one primary source for metrics and traces; the tools overlap heavily, and running two protocol parsers per node doubles cost for little gain.
What does eBPF observability replace - and what stays?
It typically replaces per-language APM agents for baseline RED metrics, sidecar-based telemetry collection, and the first wave of manual OpenTelemetry SDK wiring. It does not replace business-level custom spans, structured application logs, or domain metrics - the kernel cannot see that an HTTP 200 carried a failed payment.
The replacement math is concrete. Sidecar telemetry costs memory per pod - tens of MB times thousands of pods - plus injection complexity; a node agent amortizes that to one process per node. Language agents cost upgrade coordination across every service team, forever. Many teams also keep their service mesh for mTLS and routing but retire it as a telemetry source, which shrinks the mesh's resource envelope and failure surface.
What stays: SDK instrumentation on the minority of services where business context pays for itself. A common steady state is eBPF for the fleet-wide baseline plus hand-instrumented OTel spans on the five or ten services where engineers actually debug logic, all flowing into the same backend under the same semantic conventions.
Can eBPF see inside TLS-encrypted traffic?
Often yes - by attaching uprobes to TLS library functions such as SSL_read and SSL_write in OpenSSL, where data exists in plaintext at the function boundary, before encryption ever happens. Coverage varies by stack: dynamically linked OpenSSL is straightforward, Go's crypto/tls needs per-binary symbol resolution, and JVM TLS remains the weakest case across most tools.
The mechanism matters for expectations. Nothing is decrypted on the wire; the probe reads arguments of a function the application was calling anyway. That is why support is per-library: BoringSSL and statically linked builds need their own offsets, stripped binaries complicate symbol lookup, Go works when the tool resolves runtime symbols for the specific binary version, and some tools quietly fall back to a JVM agent for Java - which breaks the zero-instrumentation promise, so ask vendors directly.
The same capability is a security story: an attacker who can load eBPF programs can read your plaintext too. Restrict program loading, verify agent images, and monitor for unexpected loaders - runtime tools like the one we cover in Runtime Threat Detection with Tetragon: An eBPF Security Playbook for Kubernetes can watch for exactly that.
What are the hard limits of eBPF observability?
Four limits recur: distributed trace context is hard to propagate without touching headers, so cross-service traces may be inferred rather than exact; kernel and BTF requirements exclude older nodes; per-language gaps around TLS and async runtimes persist; and payload capture at high cardinality can overwhelm storage unless you sample deliberately.
The context-propagation limit deserves detail. A proper distributed trace requires a traceparent header traveling with each request; injecting headers from kernel space is intrusive, so tools either rewrite at the socket layer for simple protocols, correlate spans by socket and timing with error bars, or ask for a minimal SDK assist on edge services. Async runtimes - Node's event loop, Go goroutines - further complicate attributing kernel events to logical requests. Expect excellent per-service telemetry and good-but-not-perfect cross-service traces, improving release by release.
Environment limits are blunter: no eBPF on serverless platforms like Lambda, partial visibility on Fargate-class runtimes, immature Windows support, and old enterprise kernels on long-lived on-prem fleets may miss the BTF floor entirely.
How much overhead and cost does it add?
Vendor benchmarks and field reports typically put agent CPU in the 1 to 5 percent range per node with per-request latency added in microseconds, but the honest answer is workload-dependent: high connection rates with deep payload parsing cost more. The larger bill usually lands downstream, in metric cardinality and trace storage, not in the agent.
Control it the same way you control any telemetry pipeline:
- ▸Measure on a canary node pool with an A/B comparison before fleet rollout, and watch the agent's ring-buffer drop counters - silent data loss is worse than overhead.
- ▸Cap cardinality deliberately. Per-pod labels on histogram metrics explode series counts; aggregate to workload level unless you need pod granularity.
- ▸Tier retention. Full traces for days, aggregates for months.
Weigh the spend against what it retires: sidecar memory across the fleet, per-host APM licensing, and the engineering quarters of SDK rollout. The unit-economics framing from Kubernetes FinOps: From Cluster Bill to Unit Economics applies directly - observability cost per request is a number worth knowing.
How do you roll it out on a production cluster?
Roll out in four steps: deploy the collector DaemonSet to one node pool, validate the discovered service map against topology you already trust, wire exports into your existing Prometheus, Tempo, or OTLP backend rather than a parallel stack, then expand fleet-wide - and delete the instrumentation it replaces only after alert parity holds through two release cycles.
Three details prevent regret. Keep OpenTelemetry semantic conventions everywhere so eBPF-sourced and SDK-sourced signals land in the same dashboards without forking. Document per signal where it comes from, because during an incident nobody should wonder whether a missing span means a broken service or a coverage gap. And security-review the agent itself: it is a privileged DaemonSet with kernel access and plaintext visibility, so pin versions, verify signatures, and include it in your supply-chain review like any other high-privilege component.
How TuniCyberLabs helps
We build and operate observability stacks for Kubernetes and hybrid fleets across the EU and North Africa - eBPF auto-instrumentation, OpenTelemetry pipelines, Grafana and Prometheus backends, and the cost governance that keeps telemetry bills sane. If your fleet still depends on per-language agents or has no baseline visibility at all, see our engineering services and we will scope a rollout.