eBPF: Revolutionizing Cloud-Native Observability in 2026

Introduction: The Kernel-Level Observability Revolution

The observability landscape has undergone a tectonic shift. For over a decade, engineering teams relied on a familiar playbook: instrument application code, deploy sidecar proxies, install agents, and hope that the resulting telemetry data told a coherent story. This approach worked when systems were simple. But in the era of distributed microservices running across multi-cloud Kubernetes clusters, the traditional observability stack has buckled under its own weight. The overhead of sidecars, the fragility of manual instrumentation, and the blind spots left by application-level-only monitoring have become liabilities that organizations can no longer afford.

Enter eBPF -- extended Berkeley Packet Filter -- a technology that fundamentally changes how we observe, secure, and understand production systems. Rather than instrumenting applications from the outside, eBPF operates at the kernel level, providing a programmable data plane that can observe every syscall, network packet, file access, and process execution without modifying a single line of application code.

By 2026, eBPF has moved far beyond its experimental roots. It is now the backbone of observability infrastructure at companies like Netflix, Meta, Google, Cloudflare, and thousands of enterprises running cloud-native workloads at scale. The CNCF ecosystem has coalesced around eBPF-powered tools, and the technology has become a defining feature of how modern platform engineering teams build and operate their observability stacks.

This article provides a comprehensive, technically deep exploration of eBPF for cloud-native observability. We will cover the fundamental architecture, walk through the major tools in the 2026 ecosystem, examine production deployment patterns, and explore the limitations and trade-offs that engineering teams must navigate. Whether you are evaluating eBPF-based observability tools or building custom eBPF programs, this guide will give you the foundational understanding you need.

eBPF Fundamentals: How the Technology Works

Understanding eBPF requires grasping a few core concepts that differentiate it from traditional kernel modules and userspace monitoring approaches. At its heart, eBPF is a virtual machine embedded in the Linux kernel that allows you to run sandboxed programs in kernel space, triggered by specific events, without the risks traditionally associated with kernel programming.

The eBPF Virtual Machine and Instruction Set

The eBPF virtual machine operates on a register-based instruction set with eleven 64-bit registers, a program counter, and a 512-byte stack. Programs are written in a restricted subset of C (or increasingly in Rust via the Aya framework), compiled to eBPF bytecode, and then loaded into the kernel through the bpf() system call. The instruction set supports arithmetic operations, memory access, function calls, and conditional jumps, but deliberately excludes constructs like unbounded loops and arbitrary memory access that could compromise kernel stability.

Each eBPF program is limited in size -- historically to 4,096 instructions, though this limit has been raised to one million instructions in recent kernel versions. This constraint forces programs to be focused and efficient, which aligns well with observability use cases where you want to extract specific data points with minimal overhead.

The Verifier: Safety at Load Time

The eBPF verifier is the critical safety mechanism that makes the entire technology viable. Before any eBPF program executes in the kernel, the verifier performs static analysis to guarantee several properties:

• Termination: The program must provably terminate. The verifier walks all possible execution paths to ensure there are no infinite loops. Bounded loops (with a compile-time-determinable upper bound) were added in kernel 5.3 and are now widely used.
• Memory safety: Every memory access must be within bounds. The verifier tracks pointer types and ensures that programs cannot read or write arbitrary kernel memory.
• Type safety: The verifier maintains type information for all registers and ensures that helper function arguments match expected types.
• Stack safety: Stack usage must remain within the 512-byte limit, and the verifier ensures no out-of-bounds stack access.
• No null pointer dereferences: The verifier tracks whether pointers can be null and requires explicit null checks before dereferencing.

The verifier has grown substantially more sophisticated over time. In kernel 6.x releases, it gained support for complex data structures, improved loop handling, and better support for global functions and function-by-function verification. These improvements have expanded what eBPF programs can do while maintaining the safety guarantees that kernel developers require.

JIT Compilation: Native Performance

Once the verifier approves an eBPF program, the Just-In-Time (JIT) compiler translates the bytecode into native machine instructions for the host architecture. JIT compilation is available for x86-64, ARM64, RISC-V, s390x, and other architectures. The resulting native code runs at near-native speed, which is why eBPF-based observability tools can achieve single-digit microsecond overhead per event -- orders of magnitude faster than userspace tracing approaches.

JIT compilation also provides a security benefit: the compiled programs run in read-only memory and cannot be modified after compilation, eliminating an entire class of runtime attacks.

eBPF Maps: The Data Bridge

eBPF maps are the primary mechanism for storing state and communicating data between eBPF programs running in kernel space and userspace applications. Maps are key-value data structures that come in many types:

• Hash maps (BPF_MAP_TYPE_HASH): General-purpose key-value storage, used for tracking per-connection metadata, counting events by type, or maintaining lookup tables.
• Array maps (BPF_MAP_TYPE_ARRAY): Fixed-size arrays indexed by integer, ideal for per-CPU counters or configuration parameters.
• Ring buffers (BPF_MAP_TYPE_RINGBUF): High-performance, variable-length event streaming from kernel to userspace. Ring buffers replaced the older perf event arrays and offer better performance characteristics with a shared memory region.
• LRU maps (BPF_MAP_TYPE_LRU_HASH): Hash maps with automatic eviction of least-recently-used entries, useful for connection tracking where memory bounds must be maintained.
• Per-CPU maps: Variants of hash and array maps that maintain separate copies for each CPU core, eliminating lock contention at the cost of higher memory usage.
• Stack trace maps (BPF_MAP_TYPE_STACK_TRACE): Specialized maps for capturing kernel and userspace stack traces, foundational for profiling use cases.

Maps are the glue that makes eBPF observability practical. An eBPF program attached to a network socket can record packet metadata into a ring buffer, which a userspace agent then reads, enriches with Kubernetes metadata, and exports as OpenTelemetry spans. This division of labor -- minimal processing in the kernel, rich processing in userspace -- is the architectural pattern underlying every major eBPF observability tool.

Helper Functions: Controlled Kernel Interaction

eBPF programs cannot call arbitrary kernel functions. Instead, they interact with the kernel through a set of helper functions that are explicitly exposed and documented. These helpers provide controlled access to kernel capabilities:

• bpf_probe_read_kernel() and bpf_probe_read_user(): Safely read memory from kernel or userspace address spaces.
• bpf_ktime_get_ns(): Get the current kernel timestamp in nanoseconds, essential for latency measurements.
• bpf_get_current_pid_tgid(): Get the PID and thread group ID of the current process.
• bpf_get_current_comm(): Get the command name of the current process.
• bpf_perf_event_output() and bpf_ringbuf_output(): Send data from kernel to userspace through maps.
• bpf_get_stackid(): Capture stack traces for profiling.
• bpf_skb_load_bytes(): Read packet data from network buffers.

The helper function API has expanded dramatically since kernel 5.x. By kernel 6.8 and beyond, there are over 200 helper functions available, covering networking, tracing, cgroup management, timer operations, and more. This rich API is what enables eBPF programs to serve such diverse observability use cases.

Program Types and Attach Points

eBPF programs are categorized by type, which determines where they can be attached and what helpers they can call. The program types most relevant to observability include:

• kprobes and kretprobes: Attach to the entry and return of any kernel function. This is the foundation of kernel-level tracing -- you can instrument any of the thousands of functions in the Linux kernel without recompilation.
• uprobes and uretprobes: The userspace equivalent of kprobes. Attach to the entry and return of any function in a userspace binary, enabling application-level tracing without code changes.
• tracepoints: Attach to stable, well-defined instrumentation points in the kernel. Unlike kprobes, tracepoints are part of the kernel's stable ABI and are less likely to break across kernel versions.
• perf events: Attach to hardware and software performance counters, enabling CPU profiling, cache miss analysis, and other hardware-level observability.
• socket filters: Inspect and filter network packets at the socket level.
• XDP (eXpress Data Path): Process packets at the earliest point in the network stack, before the kernel allocates an sk_buff. XDP programs can achieve line-rate packet processing and are used for DDoS mitigation, load balancing, and high-performance network observability.
• TC (Traffic Control): Attach to the kernel's traffic control layer for packet classification and manipulation.
• cgroup programs: Attach to cgroup hooks for per-container network and resource control, directly relevant to Kubernetes observability.
• LSM (Linux Security Modules): Attach to security hooks for runtime security monitoring and enforcement.

BTF and CO-RE: Portable eBPF Programs

One of the historically significant challenges with eBPF was portability. eBPF programs compiled for one kernel version might not work on another because kernel data structure layouts change between versions. Two technologies solve this problem:

BTF (BPF Type Format) is a compact metadata format that describes the types and data structures used by the kernel. Modern kernels ship with BTF information embedded, which allows eBPF programs to understand the layout of kernel structures at load time.

CO-RE (Compile Once, Run Everywhere) is a framework built on BTF that allows eBPF programs to be compiled once and run on any kernel version that provides BTF information. The CO-RE mechanism uses relocations -- similar to how a linker resolves symbols -- to adjust field offsets and structure sizes at load time. This means an eBPF program compiled on kernel 6.1 can run on kernel 6.8 without recompilation, even if the relevant kernel structures have changed layout.

CO-RE has been transformative for the eBPF ecosystem. Before CO-RE, tools like BCC compiled eBPF programs on the target machine using LLVM, requiring a full compiler toolchain on every production node. With CO-RE, precompiled eBPF programs can be distributed as binaries, dramatically simplifying deployment and reducing resource requirements on production machines.

The eBPF Observability Stack in 2026

The ecosystem of eBPF-powered observability tools has matured rapidly. What was once a collection of experimental projects has become a robust set of production-grade tools, many of which are CNCF-hosted or backed by major vendors. Let us examine the key players.

Cilium and Hubble: Network Observability Without Sidecars

Cilium has become the de facto standard CNI (Container Network Interface) plugin for Kubernetes environments that demand both performance and observability. At its core, Cilium replaces the traditional iptables-based networking stack with eBPF programs that handle packet routing, load balancing, network policy enforcement, and observability at the kernel level.

Hubble is Cilium's observability layer. It provides deep network visibility by leveraging the eBPF datapath that Cilium already operates. Hubble can observe:

• L3/L4 flow visibility: Every TCP/UDP connection between pods, services, and external endpoints is tracked with metadata including source/destination identity, port, protocol, and Kubernetes labels.
• L7 protocol analysis: Hubble can parse HTTP, gRPC, Kafka, and DNS traffic at the protocol level, extracting request/response metadata without requiring sidecars or application instrumentation.
• DNS observability: Every DNS query and response is captured, providing visibility into service discovery patterns, DNS resolution latency, and potential DNS-based attacks.
• Network policy audit: Hubble shows which network policies are being applied to traffic flows, making it possible to debug connectivity issues caused by misconfigured policies.
• Service dependency mapping: By aggregating flow data, Hubble automatically generates service dependency maps that show how microservices communicate.

Hubble's architecture is elegant in its simplicity. eBPF programs running in the kernel datapath emit events into per-CPU ring buffers. The Hubble agent running as a DaemonSet reads these events, enriches them with Kubernetes metadata (pod names, namespaces, labels), and makes them available through a gRPC API. Hubble UI provides a graphical interface for exploring flows, and Hubble metrics exports Prometheus-compatible metrics derived from the flow data.

In 2026, Cilium's position has been further solidified by its graduation as a CNCF project and its adoption as the default CNI in major managed Kubernetes offerings. The combination of networking, security, and observability in a single eBPF-powered data plane has proven to be a compelling alternative to the traditional approach of layering separate tools for each concern.

Pixie: Scriptable Application Observability

Pixie, originally developed by Pixie Labs and now a CNCF sandbox project, takes a different approach to eBPF observability. Where Hubble focuses on network flows, Pixie aims to provide full-stack application observability -- including request tracing, CPU profiling, and database query analysis -- entirely through eBPF, with zero manual instrumentation.

Pixie deploys as a set of agents (called PEMs -- Pixie Edge Modules) that run eBPF programs to capture:

• HTTP/gRPC request traces: Pixie automatically traces HTTP/1.1, HTTP/2, and gRPC requests by attaching uprobes to TLS libraries and kprobes to socket operations. It captures request/response bodies, headers, latencies, and error codes.
• Database query tracing: SQL queries to MySQL, PostgreSQL, Cassandra, and Redis are automatically captured by tracing the relevant protocol parsing in the kernel networking stack.
• CPU flame graphs: Pixie uses perf events to continuously profile CPU usage and generate flame graphs that show where applications spend their time.
• Network traffic analysis: Similar to Hubble, Pixie captures network flows, but with additional application-layer enrichment.

What makes Pixie unique is its PxL scripting language -- a Python-like language that allows users to write custom queries against the live telemetry data being captured by eBPF. PxL scripts can aggregate, filter, and transform data in real-time, and the results are displayed in Pixie's web-based UI or exported through its API.

Pixie's approach of keeping data local to the cluster -- processing and storing telemetry data on the edge rather than sending it to a central backend -- is particularly appealing for organizations with data sovereignty requirements or cost concerns about egressing large volumes of telemetry data.

Cilium Tetragon: Runtime Security Observability

Tetragon is Cilium's runtime security observability and enforcement tool. While Hubble focuses on network visibility, Tetragon focuses on process-level visibility -- what programs are running, what files they access, what system calls they make, and what network connections they establish.

Tetragon achieves this by attaching eBPF programs to kernel hooks at multiple levels:

• Process lifecycle events: Tetragon tracks process creation (execve), exit, and credential changes, building a real-time process tree for every container.
• File access monitoring: By attaching to VFS (Virtual File System) operations, Tetragon can detect and alert on file reads, writes, and permission changes in sensitive paths.
• Network connection tracking: Tetragon monitors connect(), accept(), sendmsg(), and recvmsg() syscalls to build a complete picture of network activity at the process level.
• Syscall monitoring: Custom TracingPolicy resources allow users to define which syscalls to monitor and what actions to take (log, alert, or kill the offending process).

Tetragon's TracingPolicy CRD (Custom Resource Definition) is its primary configuration mechanism. A TracingPolicy defines which kernel functions to instrument, what arguments to capture, and what actions to take when conditions are met:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-sensitive-files
spec:
  kprobes:
    - call: 'security_file_open'
      syscall: false
      args:
        - index: 0
          type: 'file'
      selectors:
        - matchArgs:
            - index: 0
              operator: 'Prefix'
              values:
                - '/etc/shadow'
                - '/etc/passwd'
                - '/etc/kubernetes/pki'
          matchActions:
            - action: Sigkill

This example monitors attempts to open sensitive files and terminates processes that try to access Kubernetes PKI material. The ability to both observe and enforce security policies at the kernel level, with sub-millisecond response times, makes Tetragon a powerful complement to traditional security tools.

Grafana Beyla: Zero-Code Auto-Instrumentation

Grafana Beyla represents one of the most accessible entry points to eBPF-based observability. Released as a stable 1.0 in 2024 and now widely adopted, Beyla provides automatic instrumentation for HTTP, HTTPS, gRPC, and SQL database calls without any code changes, sidecar proxies, or SDK integrations.

Beyla works by attaching uprobes to well-known functions in common runtimes and libraries:

• Go: Beyla instruments the net/http package, gRPC libraries, and database drivers by attaching uprobes to exported function symbols.
• Node.js, Python, Ruby, Java: Beyla instruments the TLS/SSL libraries used by these runtimes (OpenSSL, GnuTLS, BoringSSL), allowing it to capture encrypted HTTP traffic by hooking the plaintext stage of TLS processing.
• Kernel-level: For protocols that do not use TLS, Beyla attaches to socket operations in the kernel to capture request/response data.

The telemetry data that Beyla produces is natively formatted as OpenTelemetry metrics and traces. Beyla exports RED metrics (Rate, Error, Duration) for every service it discovers, and it generates distributed traces that show request flow across service boundaries. This data can be sent directly to any OpenTelemetry-compatible backend -- Grafana Cloud, Jaeger, Tempo, or a generic OTLP collector.

Beyla's value proposition is compelling: deploy a single DaemonSet, configure a few environment variables, and immediately get request-level metrics and traces for every service in the cluster, regardless of programming language, without touching application code.

Coroot and Groundcover: Full-Stack eBPF Observability Platforms

The 2025-2026 period has seen the emergence of commercial and open-source platforms that bundle multiple eBPF-based observability capabilities into unified products.

Coroot is an open-source observability platform that uses eBPF for automatic service mapping, request tracing, log collection, and profiling. Coroot differentiates itself by focusing on automated root cause analysis -- it correlates metrics, traces, and logs to automatically identify the root cause of performance issues and presents actionable insights rather than raw data.

Groundcover takes a similar approach, positioning itself as a full-stack observability platform that replaces traditional APM tools. Groundcover uses eBPF to capture application-level metrics, distributed traces, and logs at the kernel level, then processes and stores this data in a cost-efficient manner. Their pitch is straightforward: replace expensive per-host APM agent licenses with a single eBPF-powered platform at a fraction of the cost.

Both platforms reflect a broader trend: eBPF is not just a technology for building observability primitives -- it is becoming the foundation for complete observability platforms that aim to replace the traditional stack of metrics, tracing, and logging tools.

How eBPF Replaces Traditional Monitoring Approaches

The shift from traditional monitoring to eBPF-based observability is not merely incremental -- it represents a fundamentally different architecture. Understanding why this matters requires examining the specific pain points that eBPF eliminates.

The Sidecar Problem

In the traditional service mesh model (Istio, Linkerd), a sidecar proxy (typically Envoy) runs alongside every application container. These sidecars intercept all network traffic, providing mTLS, load balancing, and observability. The problem is that sidecars carry significant overhead:

• Memory: Each Envoy sidecar consumes 50-200MB of RAM. In a cluster with 1,000 pods, that is 50-200GB of memory dedicated to proxies.
• Latency: Traffic must be redirected through the sidecar using iptables rules, adding 1-3 milliseconds of latency per hop. In a request that traverses five services, that is 10-30 milliseconds of added latency from proxies alone.
• CPU: Sidecar proxies consume 2-5% CPU per pod for traffic processing.
• Operational complexity: Sidecar injection, version management, and debugging proxy issues add operational burden.

eBPF-based networking (as implemented by Cilium) eliminates the sidecar entirely. Network policy enforcement, load balancing, and observability happen in the kernel datapath. There is no userspace proxy, no iptables redirection, and no per-pod memory overhead. The result is lower latency, reduced resource consumption, and simpler operations.

The Instrumentation Tax

Traditional APM tools require manual instrumentation: developers must add SDK calls to their code to generate traces, metrics, and logs. This creates several problems:

• Development velocity: Instrumenting code takes time and must be maintained as code evolves.
• Inconsistency: Different teams instrument differently, leading to gaps and inconsistencies in telemetry data.
• Legacy services: Old services that no one wants to modify remain uninstrumented and invisible.
• Polyglot environments: Each programming language requires its own SDK and instrumentation patterns.

eBPF-based tools like Beyla and Pixie eliminate this tax entirely. Because they operate at the kernel level, they can observe any process regardless of programming language, framework, or deployment model. A Go microservice, a legacy Java monolith, and a Python data pipeline are all equally visible.

Blind Spot Elimination

Traditional monitoring creates blind spots wherever instrumentation is absent. Infrastructure-level activities -- kernel operations, system calls, file system access, process lifecycle events -- are typically invisible to application-level monitoring tools. eBPF eliminates these blind spots by operating at the kernel level where all activity is visible.

Consider a scenario where a containerized application experiences intermittent latency spikes. With traditional monitoring, you might see elevated response times in your APM traces, but the root cause -- say, a noisy neighbor process causing CPU throttling via cgroup limits, or a kernel memory allocation stall -- would be invisible. With eBPF-based observability, you can correlate application-level latency with kernel-level events like scheduler delays, page faults, or I/O wait times, giving you the complete picture needed to diagnose the issue.

Kernel-Level Tracing and Profiling

eBPF's tracing capabilities are among its most powerful features for observability. The ability to dynamically instrument any kernel or userspace function, without restarting processes or recompiling code, provides a level of introspection that was previously impossible in production environments.

Kprobes: Dynamic Kernel Instrumentation

Kprobes (kernel probes) allow eBPF programs to attach to the entry point of virtually any function in the Linux kernel. When the instrumented function is called, the eBPF program executes and can read function arguments, inspect kernel state, and record data into maps.

For observability, kprobes are used extensively to trace:

• File system operations: Attaching to VFS functions like vfs_read(), vfs_write(), and vfs_open() reveals I/O patterns, file access frequencies, and latency distributions.
• Network operations: Tracing tcp_connect(), tcp_sendmsg(), and tcp_recvmsg() provides visibility into TCP connection establishment, data transfer, and retransmission behavior.
• Scheduler operations: Tracing finish_task_switch() and sched_switch reveals scheduling latency, CPU migration patterns, and priority inversion issues.
• Memory allocation: Tracing kmalloc(), kfree(), and page_alloc_slowpath() helps identify memory allocation patterns and potential memory pressure.

The power of kprobes lies in their dynamism. You can attach a kprobe to any kernel function at runtime, collect data for a specific window, and detach it when done -- all without any impact on the kernel when probes are not active.

Uprobes: Application-Level Tracing Without Code Changes

Uprobes extend the kprobe concept to userspace binaries. By attaching to specific function entry points in compiled binaries or shared libraries, eBPF programs can trace application behavior at the function level.

For observability, uprobes enable scenarios like:

• TLS decryption visibility: Attaching uprobes to SSL_read() and SSL_write() in OpenSSL allows eBPF programs to capture plaintext request/response data before encryption, providing protocol-level visibility for HTTPS traffic without requiring TLS termination proxies or certificate injection.
• Runtime-specific tracing: Attaching to Go's runtime.newproc() traces goroutine creation, while attaching to Java's JIT compilation functions can track JIT behavior.
• Database client tracing: Attaching to database client library functions (e.g., PQexec() in libpq for PostgreSQL) captures every SQL query with timing information.

Tracepoints: Stable Kernel Instrumentation

While kprobes can attach to any kernel function, they are tied to the kernel's internal implementation, which can change between versions. Tracepoints provide stable instrumentation points that are part of the kernel's supported interface. Key tracepoints for observability include:

• sched:sched_process_exec and sched:sched_process_exit: Track process lifecycle.
• syscalls:sys_enter_* and syscalls:sys_exit_*: Trace specific system call entry and exit.
• net:net_dev_xmit and net:netif_receive_skb: Track network packet transmission and reception.
• block:block_rq_issue and block:block_rq_complete: Monitor block I/O operations.

Tracepoints are the preferred instrumentation point for production observability tools because they are stable across kernel versions, well-documented, and carry minimal performance overhead.

Perf Events: Hardware-Level Profiling

eBPF programs can attach to hardware and software performance monitoring counters (PMCs) exposed through the perf subsystem. This enables profiling capabilities that go beyond software-level observability:

• CPU cycle profiling: Sample the instruction pointer at fixed intervals to build flame graphs showing where CPU time is spent.
• Cache miss analysis: Count L1/L2/L3 cache misses to identify memory access patterns that degrade performance.
• Branch misprediction tracking: Identify hot code paths where branch prediction fails, causing pipeline stalls.
• TLB miss counting: Detect memory access patterns that cause Translation Lookaside Buffer misses, which can significantly impact performance for memory-intensive workloads.

The combination of perf event-based profiling with kprobe/uprobe-based tracing gives observability teams a complete performance analysis toolkit that spans from hardware counters to application-level request tracing.

Network Observability with eBPF

Network observability is where eBPF has had its most visible impact on the cloud-native ecosystem. The ability to observe network traffic at the kernel level -- without sidecars, without packet captures, without application instrumentation -- has transformed how teams understand their network infrastructure.

Flow-Level Visibility

At the most basic level, eBPF provides complete visibility into network flows -- every TCP/UDP connection, with metadata about source, destination, port, protocol, bytes transferred, packets sent/received, and connection duration. In a Kubernetes context, this flow data is enriched with pod names, namespaces, service names, and labels, providing a rich picture of service-to-service communication.

Cilium Hubble generates flow records by instrumenting the kernel's network stack at the TC (traffic control) and socket levels. Each flow record includes:

• Source and destination identity (pod, service, external endpoint)
• L3/L4 protocol information (TCP, UDP, ICMP)
• Connection state (SYN, SYN-ACK, FIN, RST)
• Byte and packet counts
• TCP flags and retransmission counts
• Associated Kubernetes network policies (allow/deny)

This flow data powers service dependency maps, traffic analysis, and network policy debugging. Teams can answer questions like "which services does my payment service communicate with?" or "why is traffic between service A and service B being dropped?" without deploying any additional infrastructure.

DNS Monitoring

DNS is the backbone of service discovery in Kubernetes and cloud environments, yet it is often a monitoring blind spot. eBPF-based DNS monitoring captures every DNS query and response at the kernel level, providing visibility into:

• Query patterns: Which services are making DNS queries, how frequently, and for which domains.
• Resolution latency: How long DNS resolution takes, which can be a significant contributor to overall request latency.
• Failure patterns: NXDOMAIN responses, timeouts, and SERVFAIL errors that indicate misconfigured services or DNS infrastructure issues.
• DNS-based threats: DNS tunneling, domain generation algorithm (DGA) detection, and unauthorized DNS resolution attempts.

Cilium Hubble captures DNS traffic by intercepting UDP packets on port 53 and parsing the DNS protocol. Because this happens at the kernel level, it captures all DNS activity regardless of which DNS client library the application uses.

L7 Protocol Analysis Without Sidecars

One of the most compelling eBPF capabilities is Layer 7 (application protocol) visibility without sidecar proxies. By using a combination of kprobes on socket operations and uprobes on TLS libraries, eBPF-based tools can parse application-layer protocols including:

• HTTP/1.1 and HTTP/2: Request method, URL, status code, headers, and timing.
• gRPC: Service name, method, status, and message sizes.
• Kafka: Topic, partition, message key, and consumer group.
• Redis: Command type, key, and response time.
• MySQL and PostgreSQL: SQL query text, execution time, and row counts.
• MongoDB: Operation type, collection, and query filter.

This protocol-level visibility was traditionally the exclusive domain of sidecar proxies like Envoy or dedicated protocol analyzers. eBPF achieves the same visibility with dramatically lower overhead because parsing happens at the kernel level, avoiding the context switches and memory copies that sidecar-based approaches require.

Added monitoring latency in milliseconds: sidecar proxy approach vs eBPF kernel-level approach.

Security Observability with eBPF

Security observability -- the ability to detect, investigate, and respond to security threats in real-time -- is an area where eBPF excels beyond any traditional approach. Because eBPF operates at the kernel level, it can observe security-relevant events that are completely invisible to application-level monitoring.

Runtime Threat Detection

Traditional security tools rely on log analysis, file scanning, or network signature matching. eBPF enables real-time runtime threat detection by monitoring actual system behavior:

• Unexpected process execution: Detecting when a container spawns a shell (/bin/sh, /bin/bash), runs a package manager (apt, yum), or executes a network tool (curl, wget, nmap) that should not be present in a production container.
• Privilege escalation: Monitoring setuid(), setgid(), capset(), and other capability-related system calls to detect attempts to escalate privileges.
• Container escape attempts: Detecting attempts to mount the host filesystem, access the Docker socket, or manipulate namespaces and cgroups from within a container.
• Suspicious network activity: Identifying outbound connections to known malicious IP addresses, unusual port scanning behavior, or DNS queries to command-and-control domains.

Tetragon excels in this space by combining detection with enforcement. When a TracingPolicy detects a security violation, Tetragon can take immediate action -- including sending a SIGKILL to the offending process -- in under one millisecond. This is orders of magnitude faster than traditional approaches that rely on log collection, alerting, and manual response.

Syscall Monitoring

System calls are the interface between userspace applications and the Linux kernel. Monitoring system calls provides a comprehensive view of what every process on the system is doing. eBPF-based syscall monitoring captures:

• File operations: open(), read(), write(), unlink(), rename() -- who is accessing what files and when.
• Process operations: execve(), fork(), clone() -- process creation chains and command-line arguments.
• Network operations: socket(), connect(), bind(), listen(), accept() -- complete network activity at the process level.
• Permission operations: chmod(), chown(), setxattr() -- changes to file permissions and extended attributes.

This level of visibility enables security teams to establish behavioral baselines for their workloads and detect anomalies. If a web server process that normally only performs read(), write(), accept(), and sendmsg() syscalls suddenly starts calling execve() or ptrace(), that deviation from the baseline is a strong indicator of compromise.

File Integrity Monitoring

eBPF-based file integrity monitoring (FIM) surpasses traditional FIM tools (like AIDE or Tripwire) by operating in real-time rather than through periodic scanning. By attaching to VFS operations, eBPF programs can detect file modifications the instant they occur, capturing:

• The file path being accessed or modified
• The process performing the modification (PID, binary name, container ID)
• The operation type (create, modify, delete, permission change)
• The complete process ancestry (who spawned the process that modified the file)

This real-time capability is critical for detecting attacks like webshell deployment, configuration file tampering, and rootkit installation, where the time between compromise and detection directly impacts blast radius.

Performance Profiling with eBPF

eBPF has transformed performance profiling from a point-in-time debugging exercise into a continuous, always-on capability that runs in production with negligible overhead.

Continuous Profiling

Continuous profiling captures CPU stack traces, memory allocation patterns, and off-CPU time for every process, all the time. Unlike traditional profilers that are run ad-hoc when a problem is suspected, continuous profiling provides a historical record of performance behavior that can be queried after the fact.

Tools like Parca, Pyroscope (now part of Grafana), and Polar Signals use eBPF-based profiling to:

• Sample CPU profiles at configurable intervals (typically 100Hz) using perf events, capturing both kernel and userspace stack traces.
• Track memory allocations by instrumenting the kernel's memory allocator, showing which code paths are allocating the most memory.
• Measure off-CPU time by tracing scheduler events, revealing where processes are waiting (I/O, lock contention, network, sleep).

The overhead of eBPF-based continuous profiling is remarkably low -- typically under 1% CPU overhead -- because the sampling happens in the kernel and only aggregated data is transmitted to userspace. This makes it practical to run profiling continuously in production, even on latency-sensitive workloads.

Flame Graphs from eBPF

Flame graphs, pioneered by Brendan Gregg, have become the standard visualization for performance profiles. eBPF makes flame graph generation straightforward:

1. An eBPF program attached to perf events samples the instruction pointer and captures the stack trace at regular intervals.
2. Stack traces are stored in a stack trace map, with each unique stack trace counted.
3. A userspace agent reads the stack trace map, symbolizes the addresses (using debug info or DWARF symbols), and generates the flame graph.

Modern continuous profiling platforms generate flame graphs automatically and allow users to compare profiles across time windows, diff profiles between releases, and filter profiles by specific processes, containers, or Kubernetes deployments. This transforms flame graphs from a debugging tool into a continuous performance monitoring capability.

Latency Analysis

eBPF enables precise latency analysis at multiple levels of the stack:

• Syscall latency: Attaching kprobes to the entry and return of system calls reveals how long the kernel takes to complete operations. High read() latency on a disk-backed file system might indicate I/O pressure, while high futex() latency indicates lock contention.
• Scheduler latency: Tracing the time between when a task becomes runnable and when it actually runs on a CPU reveals scheduling delays caused by CPU saturation or priority issues.
• Network latency: Tracing TCP connection establishment (connect() to handshake completion), DNS resolution, and per-request latency provides a complete picture of network-induced delays.
• I/O latency: Tracing block I/O operations from request submission to completion shows storage device performance and identifies I/O bottlenecks.

By correlating these latency measurements across the stack, teams can decompose end-to-end request latency into its constituent parts and identify precisely where time is being spent.

eBPF and OpenTelemetry Integration

OpenTelemetry (OTel) has become the industry standard for telemetry data collection and export. The integration between eBPF-based observability tools and OpenTelemetry is one of the most significant developments in the 2025-2026 landscape.

Auto-Instrumentation Without Code Changes

The OpenTelemetry project has historically focused on SDK-based instrumentation, requiring developers to add OTel library calls to their code. eBPF-based auto-instrumentation flips this model by generating OTel-compatible telemetry data from kernel-level observations.

Grafana Beyla is the most prominent example of this approach. Beyla generates OpenTelemetry metrics and traces that conform to OTel semantic conventions, meaning the telemetry data it produces is indistinguishable from SDK-generated data in downstream systems. A Grafana Cloud dashboard built on OTel traces works identically whether those traces came from the OTel Java SDK or from Beyla's eBPF auto-instrumentation.

This is powerful because it allows organizations to adopt OpenTelemetry incrementally. Teams can deploy Beyla to get immediate baseline observability for all services, then selectively add SDK-based instrumentation for services where they need custom attributes, business metrics, or deeper context. The eBPF-generated and SDK-generated telemetry coexists seamlessly in the same backend.

The OTel Collector and eBPF

The OpenTelemetry Collector has gained eBPF-based receivers that can ingest telemetry data directly from eBPF programs. The hostmetricsreceiver uses eBPF-based collection for certain metrics on Linux systems, and experimental receivers for eBPF-generated traces have been under active development.

The architectural pattern that has emerged is:

1. eBPF programs running in the kernel capture raw events (network packets, syscalls, function calls).
2. A userspace agent (Beyla, Pixie PEM, custom agent) reads events from eBPF maps, enriches them with metadata, and converts them to OTLP format.
3. The enriched OTLP data is sent to an OTel Collector for further processing, sampling, and export.
4. The Collector exports to one or more backends (Grafana Cloud, Jaeger, Datadog, New Relic, etc.).

This architecture cleanly separates the concerns of data capture (eBPF in the kernel), data enrichment (userspace agent), data processing (OTel Collector), and data storage/visualization (backend).

OpenTelemetry Semantic Conventions for eBPF

As eBPF-based auto-instrumentation has matured, the OpenTelemetry community has worked to ensure that eBPF-generated telemetry follows the same semantic conventions as SDK-generated telemetry. This means:

• HTTP spans use the same attribute names (http.request.method, url.path, http.response.status_code) regardless of whether they were generated by eBPF or an SDK.
• Database spans use standard attributes (db.system, db.statement, db.operation) for consistency across collection methods.
• Network metrics use standard names (system.network.io, system.network.connections) whether collected by eBPF or traditional means.

This standardization is critical for the long-term viability of eBPF-based observability. It ensures that organizations are not locked into eBPF-specific tooling and can mix and match collection methods without losing semantic interoperability.

Building Custom eBPF Programs

While off-the-shelf tools cover many observability use cases, there are scenarios where custom eBPF programs are needed. The ecosystem for building custom eBPF programs has matured significantly, with multiple frameworks and languages available.

libbpf and CO-RE: The Modern C Approach

libbpf is the canonical C library for building eBPF programs. Combined with CO-RE, libbpf provides a workflow where eBPF programs are written in restricted C, compiled with Clang/LLVM to produce BPF bytecode, and loaded using libbpf's loader. The CO-RE mechanism handles kernel version portability automatically.

A typical libbpf-based observability program follows this structure:

// trace_opens.bpf.c - eBPF kernel-side program
#include "vmlinux.h"
#include "bpf/bpf_helpers.h"
#include "bpf/bpf_tracing.h"

struct event {
    u32 pid;
    char comm[16];
    char filename[256];
    u64 timestamp;
};

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 256 * 1024);
} events SEC(".maps");

SEC("tracepoint/syscalls/sys_enter_openat")
int trace_openat(struct trace_event_raw_sys_enter *ctx)
{
    struct event *e;
    e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
    if (!e) return 0;

    e->pid = bpf_get_current_pid_tgid() >> 32;
    e->timestamp = bpf_ktime_get_ns();
    bpf_get_current_comm(&e->comm, sizeof(e->comm));
    bpf_probe_read_user_str(&e->filename,
        sizeof(e->filename),
        (const char *)ctx->args[1]);

    bpf_ringbuf_submit(e, 0);
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

The corresponding userspace loader reads events from the ring buffer, enriches them with additional context (container ID, Kubernetes metadata), and exports them to whatever backend the user needs.

cilium/ebpf: The Go Framework

For Go-based observability tools, the cilium/ebpf library provides a pure-Go framework for loading and interacting with eBPF programs. This library is used by Cilium itself, Tetragon, and many other Go-based eBPF tools. It handles loading BPF bytecode, managing maps, attaching programs to hooks, and reading events, all from Go code without CGo dependencies.

The cilium/ebpf library has become the de facto standard for Go-based eBPF development, with excellent documentation and a large community. For observability teams that are already building their platform in Go, this library provides a natural path to custom eBPF instrumentation.

Aya: eBPF in Rust

Aya is a Rust framework for building eBPF programs that has gained significant traction since 2024. Aya allows both the kernel-side eBPF program and the userspace loader to be written in Rust, providing memory safety guarantees for the userspace component and a familiar language for the growing Rust-in-infrastructure community.

Aya's key advantages include:

• No libc dependency: Aya can build fully statically linked binaries, simplifying distribution.
• Rust's type system: The userspace component benefits from Rust's ownership model and type safety.
• Async support: Aya integrates with Tokio for async event processing.
• Growing ecosystem: The aya-rs organization maintains a collection of eBPF programs and libraries.

BCC and bpftrace: Rapid Prototyping

BCC (BPF Compiler Collection) and bpftrace remain valuable for rapid prototyping and ad-hoc analysis, even though they are not typically used in production observability systems.

bpftrace is particularly useful for one-off investigations. Its awk-like syntax allows engineers to write powerful tracing programs in a single line:

# Trace all file opens by process name
bpftrace -e 'tracepoint:syscalls:sys_enter_openat {
    printf("%s opened %s\n", comm, str(args->filename));
}'

# Histogram of read() syscall latency in microseconds
bpftrace -e 'tracepoint:syscalls:sys_enter_read {
    @start[tid] = nsecs;
}
tracepoint:syscalls:sys_exit_read /@start[tid]/ {
    @usecs = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

# Count syscalls by process and syscall name
bpftrace -e 'tracepoint:raw_syscalls:sys_enter {
    @[comm, args->id] = count();
}'

BCC provides similar capabilities with a Python frontend, which makes it suitable for building more structured analysis tools. However, BCC's requirement for on-host compilation (it uses LLVM/Clang at runtime) makes it less suitable for production deployment compared to CO-RE-based approaches.

eBPF Limitations and Challenges

Despite its transformative capabilities, eBPF is not without limitations. Engineering teams evaluating eBPF-based observability must understand these constraints.

Kernel Version Requirements

eBPF capabilities are tied to kernel version. While the basic eBPF infrastructure has been present since kernel 4.x, many of the features that modern observability tools depend on require newer kernels:

• CO-RE support: Requires kernel 5.2+ with BTF enabled.
• Ring buffers: Available from kernel 5.8+.
• Bounded loops: Supported from kernel 5.3+.
• BPF LSM hooks: Available from kernel 5.7+.
• BPF timers: Available from kernel 5.15+.
• Multi-kprobe: Available from kernel 5.18+.

In practice, this means that eBPF-based observability tools work best on relatively recent kernels. Organizations running older LTS kernels (RHEL 7 with kernel 3.10, for example) may find that many eBPF features are unavailable. The good news is that most managed Kubernetes services and modern Linux distributions now ship with kernel 5.10+ or later, where the majority of eBPF features are available.

Windows eBPF

Historically, eBPF was a Linux-only technology. Microsoft's eBPF for Windows project has made progress in bringing eBPF to Windows, but as of 2026, Windows eBPF support remains more limited than Linux. The eBPF for Windows implementation runs eBPF programs in a userspace runtime (rather than the kernel) and supports a subset of the program types and helper functions available on Linux.

For organizations with mixed Linux/Windows environments, this means that eBPF-based observability tools may not provide consistent coverage across all platforms. Most eBPF observability vendors have focused exclusively on Linux, where the technology is most mature.

Verification Complexity

The eBPF verifier, while essential for safety, can be a source of frustration for developers building custom eBPF programs. The verifier's static analysis is conservative -- it rejects programs that it cannot prove are safe, even if they would be safe in practice. Common verifier challenges include:

• Complex data structure traversal: Following linked lists or tree structures in kernel memory can require careful programming to satisfy the verifier's bounds-checking requirements.
• Variable-length data: Processing variable-length strings or protocol payloads requires explicit bounds checks that can make code verbose and difficult to read.
• State tracking across tail calls: When eBPF programs use tail calls (jumping to another eBPF program), state tracking across the boundary can be tricky.
• Verifier scaling: Very large or complex eBPF programs can hit the verifier's instruction processing limit, even if the program itself is within the instruction count limit.

The verifier has improved significantly in recent kernel versions, with better error messages, support for more complex control flow, and higher processing limits. But it remains one of the steeper parts of the eBPF learning curve.

BTF Availability

CO-RE requires BTF (BPF Type Format) information to be present in the kernel. While most modern distributions enable BTF by default, some older or specialized kernels may not include it. Without BTF, eBPF programs must be compiled for the specific kernel version they will run on, which complicates distribution and deployment.

The BTFHub project maintains a repository of BTF files for older kernels, providing a workaround for environments where kernel BTF is not available. Tools like pahole can generate BTF data from kernel debug information, offering another path for kernels that were not originally compiled with BTF support.

Performance Considerations

While eBPF programs are highly efficient, they are not free. Each eBPF program that fires on a hot path (like every network packet or every syscall) adds some overhead. For most observability use cases, this overhead is negligible -- single-digit microseconds per event, which translates to well under 1% CPU overhead even under high load.

However, certain patterns can lead to higher overhead:

• Excessive map lookups: Each map lookup involves a hash table traversal. Programs that perform many map lookups per event can accumulate noticeable overhead.
• Large data copies: Copying large amounts of data from kernel to userspace (e.g., full packet payloads or large file contents) can be expensive.
• High-frequency events: Attaching to events that fire millions of times per second (like every context switch on a busy system) requires careful program design to minimize per-event cost.

Production eBPF observability tools address these concerns through careful program design, sampling strategies, and configurable event filtering.

Production Deployment Patterns

Deploying eBPF-based observability in production Kubernetes environments follows established patterns that balance coverage, performance, and operational simplicity.

DaemonSet-Based Agents

The most common deployment pattern is the DaemonSet-based agent. A single agent pod runs on every node in the cluster, loading eBPF programs into the kernel and collecting events from all pods on that node. This pattern is used by Cilium, Hubble, Tetragon, Beyla, Pixie, and most other eBPF observability tools.

The DaemonSet agent typically requires:

• Privileged access: eBPF programs must be loaded by a process with CAP_BPF, CAP_PERFMON, and CAP_SYS_ADMIN capabilities. Most agents run as privileged containers or with specific capability grants.
• Host PID namespace: To trace processes in other containers, the agent must share the host's PID namespace.
• Host networking or access to the kernel network namespace: For network observability, the agent needs access to the host's network stack.
• Volume mounts: Access to /sys/kernel/debug, /sys/fs/bpf, and potentially /proc for kernel function discovery and BTF access.

A typical DaemonSet specification for an eBPF observability agent:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ebpf-observability-agent
  namespace: observability
spec:
  selector:
    matchLabels:
      app: ebpf-agent
  template:
    metadata:
      labels:
        app: ebpf-agent
    spec:
      hostPID: true
      hostNetwork: true
      containers:
        - name: agent
          image: observability/ebpf-agent:latest
          securityContext:
            privileged: true
          volumeMounts:
            - name: sys-kernel-debug
              mountPath: /sys/kernel/debug
              readOnly: true
            - name: sys-fs-bpf
              mountPath: /sys/fs/bpf
            - name: proc
              mountPath: /host/proc
              readOnly: true
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
      volumes:
        - name: sys-kernel-debug
          hostPath:
            path: /sys/kernel/debug
        - name: sys-fs-bpf
          hostPath:
            path: /sys/fs/bpf
        - name: proc
          hostPath:
            path: /proc

Sidecar-Less Service Mesh

eBPF has enabled a new class of service mesh implementations that operate without sidecar proxies. Cilium's service mesh capabilities, for example, provide mTLS, load balancing, traffic management, and observability entirely through eBPF programs running in the kernel. This eliminates the per-pod overhead of sidecar proxies while maintaining the functionality that service mesh users expect.

The sidecar-less architecture works by:

1. eBPF programs in the kernel intercept network traffic at the socket or TC layer.
2. Identity-based network policies are enforced based on Kubernetes labels and SPIFFE identities.
3. Traffic management rules (retries, timeouts, circuit breaking) are applied in the kernel datapath.
4. Observability data (flows, metrics, traces) is generated as a byproduct of the network processing.

This architecture is particularly appealing for high-performance workloads where the latency overhead of sidecar proxies is unacceptable, and for organizations that want service mesh capabilities without the operational complexity of managing a sidecar fleet.

Kernel Compatibility Management

Managing kernel compatibility across a fleet of nodes is a practical concern for eBPF deployments. Production teams should maintain a kernel compatibility matrix that maps eBPF features to minimum kernel versions across their supported distributions.

Tools like Cilium and Tetragon include runtime kernel feature detection and will gracefully degrade their functionality when running on older kernels, enabling eBPF programs that are available while disabling those that require newer features. This graceful degradation pattern is essential for heterogeneous fleets where not all nodes run the same kernel version.

Best practices for kernel compatibility management include:

• Standardize kernel versions: Where possible, standardize on a single kernel version across the fleet. This simplifies eBPF program testing and reduces the surface area for compatibility issues.
• Test across kernel versions: Include kernel version variation in your CI/CD pipeline for eBPF programs. Tools like virtme-ng make it straightforward to test eBPF programs against multiple kernel versions.
• Monitor BTF availability: Ensure that BTF is enabled in your kernel configuration (CONFIG_DEBUG_INFO_BTF=y). Without BTF, CO-RE portability is not available.
• Track kernel feature requirements: Document which eBPF features each observability tool requires and validate that your fleet meets those requirements before deployment.

Comparison with Traditional APM Tools

The rise of eBPF-based observability has not gone unnoticed by traditional APM vendors. Datadog, New Relic, Dynatrace, and Splunk have all incorporated eBPF capabilities into their agents, recognizing that kernel-level data collection provides superior coverage and lower overhead compared to purely application-level instrumentation.

How Traditional APM Vendors Are Adopting eBPF

Datadog was an early adopter of eBPF for its infrastructure monitoring agent. Datadog's system-probe component uses eBPF for network performance monitoring (NPM), universal service monitoring (USM), and cloud workload security (CWS). The Datadog agent uses eBPF to capture TCP/UDP flows, HTTP request metadata, and security-relevant system events without requiring application-level instrumentation.

New Relic acquired Pixie Labs and integrated Pixie's eBPF-based auto-instrumentation into its platform. New Relic customers can deploy Pixie alongside the New Relic agent to get automatic coverage for services that have not been manually instrumented.

Dynatrace has integrated eBPF into its OneAgent for Linux-based environments, using it for deeper process-level visibility and network flow analysis. Dynatrace's approach combines its traditional bytecode injection (for deep application-level tracing) with eBPF (for kernel-level system and network visibility).

Grafana Labs has invested heavily in eBPF through Beyla and its integration with the broader Grafana observability stack (Mimir for metrics, Tempo for traces, Loki for logs, Pyroscope for profiling). The Grafana approach is notable for being fully open-source, with eBPF-generated data flowing through standard OpenTelemetry pipelines.

When eBPF Replaces Traditional APM -- and When It Does Not

eBPF-based observability excels at:

• Infrastructure-level visibility: Network flows, syscall patterns, file access, process lifecycle. This is data that traditional APM tools simply cannot capture.
• Automatic service discovery and baseline coverage: Every process on a node is automatically observed, eliminating the "unknown unknowns" problem.
• Low-overhead monitoring: Under 1% CPU overhead compared to 3-8% for traditional agents with bytecode injection.
• Polyglot environments: eBPF works identically across all programming languages and runtimes.

Traditional APM tools still have advantages for:

• Deep application-level tracing: Custom business metrics, user session tracking, and application-specific context require SDK instrumentation that eBPF cannot replicate.
• Code-level diagnostics: Method-level profiling, exception tracking, and variable inspection require bytecode injection or SDK integration.
• Distributed tracing context propagation: eBPF can observe individual requests but cannot propagate trace context (W3C Trace Context headers) across service boundaries without application-level support.
• Mature ecosystems: Traditional APM vendors offer polished dashboards, alerting, anomaly detection, and integrations that eBPF-native tools are still catching up to.

The pragmatic approach that most organizations are adopting in 2026 is a hybrid model: eBPF for baseline infrastructure and network observability, with selective SDK-based instrumentation for critical services where deep application-level context is needed.

Enterprise observability approach distribution in 2026 based on industry surveys.

Real-World Case Studies

eBPF's impact is best understood through the lens of organizations that have deployed it at scale. These case studies illustrate the practical benefits and challenges that teams encounter in production.

Netflix: eBPF for Fleet-Wide Performance Analysis

Netflix has been one of the most visible advocates of eBPF-based observability. Their FlameScope and FlameCommander tools use eBPF-based continuous profiling to analyze performance across their massive fleet of microservices. Netflix's approach involves:

• Continuous CPU profiling using perf events, capturing stack traces across all production instances at 49Hz (chosen to avoid aliasing with common system frequencies).
• TCP retransmission analysis using kprobes on tcp_retransmit_skb() to detect and diagnose network reliability issues across their AWS infrastructure.
• Custom eBPF programs for specific investigation needs, built using BCC and bpftrace for ad-hoc analysis and libbpf for production-grade tools.

Netflix has reported that eBPF-based profiling has helped them identify and fix performance regressions that saved millions of dollars in compute costs by reducing unnecessary CPU consumption.

Meta: eBPF at Hyperscale

Meta (formerly Facebook) operates one of the largest eBPF deployments in the world. Their use of eBPF spans:

• Katran: An XDP-based L4 load balancer that processes billions of packets per second across Meta's global infrastructure. Katran uses eBPF to implement consistent hashing, health checking, and session persistence at line rate.
• bpfd: Meta's BPF daemon that manages the lifecycle of eBPF programs across their fleet, providing centralized deployment, monitoring, and version management for thousands of eBPF programs.
• Network observability: eBPF-based flow analysis across Meta's data center networks, providing visibility into traffic patterns, congestion, and failures at a scale that would be impossible with traditional network monitoring.

Meta has contributed extensively to the upstream eBPF subsystem in the Linux kernel, driving improvements in verifier capability, helper function additions, and performance optimizations that benefit the entire ecosystem.

Google: eBPF in GKE and Beyond

Google has integrated eBPF deeply into Google Kubernetes Engine (GKE) through its adoption of Cilium as the optional datapath for GKE networking. Google's use of eBPF includes:

• GKE Dataplane V2: Built on Cilium, providing eBPF-based networking, network policy enforcement, and network observability for GKE clusters.
• gVisor integration: Google has worked on integrating eBPF with gVisor, their container sandbox runtime, to provide observability for sandboxed workloads.
• Internal infrastructure: Google uses eBPF extensively in their internal production infrastructure for performance analysis, security monitoring, and network debugging.

Cloudflare: eBPF at the Edge

Cloudflare's use of eBPF is focused on their edge network, where eBPF programs handle DDoS mitigation, packet processing, and observability at massive scale:

• XDP-based DDoS mitigation: Cloudflare's L4 DDoS protection uses XDP programs to drop attack traffic at the NIC driver level, before it enters the kernel's network stack. This approach can handle multi-terabit-per-second attacks with minimal impact on legitimate traffic.
• flowtrackd: Cloudflare's eBPF-based connection tracking system that maintains state for billions of concurrent connections across their edge network.
• Packet analysis: eBPF programs that analyze traffic patterns, detect anomalies, and provide real-time visibility into the traffic flowing through Cloudflare's network.

Cloudflare has published extensively about their eBPF use cases and has contributed tools and libraries back to the open-source ecosystem.

The Future of eBPF Observability

As we look ahead from 2026, several trends are shaping the future of eBPF-based observability.

eBPF Beyond Linux

While eBPF remains Linux-centric, efforts to bring eBPF-like capabilities to other platforms are accelerating. Microsoft's eBPF for Windows project continues to evolve, and there are early explorations of eBPF-like programmability in FreeBSD and other operating systems. The long-term vision of a portable, cross-platform kernel programmability framework is ambitious but increasingly plausible.

AI-Assisted Observability with eBPF

The combination of eBPF's rich data collection with AI/ML-based analysis is an emerging trend. eBPF captures a firehose of low-level system data; AI models can identify anomalies, correlate events across subsystems, and predict issues before they impact users. Several startups and established vendors are building AI-powered analysis layers on top of eBPF-collected data, promising to reduce the cognitive load on SRE teams by surfacing actionable insights from the noise of kernel-level telemetry.

eBPF and Wasm Convergence

The intersection of eBPF and WebAssembly (Wasm) is another area of active exploration. Both technologies provide sandboxed execution environments with safety guarantees, but they target different domains: eBPF for kernel-space programmability and Wasm for portable userspace execution. Hybrid approaches that use eBPF for data collection and Wasm for data processing are being explored as a way to combine the strengths of both technologies.

Standardization and Interoperability

The eBPF Foundation, hosted by the Linux Foundation, is working to standardize eBPF across implementations and promote interoperability. As eBPF moves beyond a single-kernel-feature to a cross-platform technology, standardization of the instruction set, map types, and helper function API will become increasingly important.

Getting Started: Practical Recommendations

For engineering teams looking to adopt eBPF-based observability, here is a practical roadmap:

Phase 1 -- Evaluate and pilot (weeks 1-4): Deploy Grafana Beyla as a DaemonSet in a staging environment. Beyla requires minimal configuration and provides immediate HTTP/gRPC/SQL metrics and traces. This gives your team a taste of eBPF-based auto-instrumentation with low risk and effort.

Phase 2 -- Network observability (weeks 4-8): If you are running Kubernetes, evaluate Cilium as your CNI. The migration from Calico or other CNIs to Cilium is well-documented and enables Hubble for network flow visibility. If changing CNI is not feasible, standalone Hubble or similar tools can provide network observability without replacing your CNI.

Phase 3 -- Security observability (weeks 8-12): Deploy Tetragon for runtime security monitoring. Start with built-in TracingPolicies for common security scenarios (shell execution in containers, sensitive file access, unexpected network connections), then develop custom policies based on your threat model.

Phase 4 -- Deep integration (weeks 12+): Integrate eBPF-generated telemetry with your existing observability stack through OpenTelemetry. Set up continuous profiling with Pyroscope or Parca. Evaluate whether custom eBPF programs are needed for organization-specific observability requirements.

Throughout this process, maintain a kernel compatibility matrix for your fleet, establish playbooks for debugging eBPF agent issues, and ensure that your security team is comfortable with the privileged access requirements of eBPF-based tools.

Conclusion

eBPF has fundamentally changed what is possible in cloud-native observability. By moving instrumentation into the kernel, eBPF eliminates the trade-offs that characterized traditional monitoring: no more choosing between visibility and performance, no more blind spots from uninstrumented services, no more sidecar proxies consuming resources for the privilege of seeing your own traffic.

The technology is not a silver bullet. Kernel version requirements, verification complexity, and the need for privileged access are real constraints that must be managed. And for deep application-level context -- business metrics, user session tracking, custom trace attributes -- SDK-based instrumentation remains necessary.

But the trajectory is clear. eBPF-based observability has moved from experimental curiosity to production necessity. The CNCF ecosystem, major cloud providers, and traditional APM vendors have all converged on eBPF as a foundational technology. Engineering teams that invest in understanding and adopting eBPF-based observability today are positioning themselves for a future where kernel-level visibility is not a luxury but an expectation.

The kernel has always known everything about your system. With eBPF, it can finally tell you.