What Is eBPF?

What Is eBPF?

eBPF (Extended Berkeley Packet Filter) is a Linux kernel technology that allows engineers to run programs safely inside or alongside privileged operating-system contexts, most commonly the Linux kernel. These programs can observe and react to events such as system calls, network activity, function execution, and process behavior without requiring changes to the kernel source code or traditional kernel modules.

In practice, eBPF gives developers and platform teams a way to see what is happening much closer to the operating system. This makes it useful for observability, networking, security, tracing, profiling, and performance troubleshooting, especially in environments where application-level instrumentation cannot provide enough detail.

You can think of eBPF as a programmable observation and control layer inside the operating system. Instead of rebuilding the kernel every time you need new visibility or behavior, eBPF programs can attach to specific events and run when those events occur.

eBPF at a Glance

What Does eBPF Stand For?

BPF originally stood for Berkeley Packet Filter and was designed for filtering network packets. Over time, the technology expanded far beyond packet filtering, and the modern form became known as eBPF, historically meaning extended BPF.

Today, the official eBPF project and Linux documentation treat BPF and eBPF largely as standalone terms rather than meaningful acronyms. The older packet-filtering implementation is sometimes called classic BPF, or cBPF, to distinguish it from modern eBPF.

What Problem Does eBPF Solve?

Traditional monitoring tools often have limited visibility into what happens inside the operating system. Application instrumentation can show request latency, errors, and business context, but it may not reveal lower-level issues such as TCP retransmissions, system calls, kernel scheduling, or process behavior.

eBPF helps close this gap by observing operating-system activity without changing the kernel or modifying every application. It gives teams deeper visibility into networking, processes, containers, and system behavior, which is especially useful in dynamic cloud-native environments.

Why Is eBPF Useful for Kubernetes?

Kubernetes environments change constantly as pods are created, removed, moved, and scaled. Traditional host-level monitoring can struggle to keep up with this level of change.

An eBPF-enabled agent running on a Kubernetes node can observe activity across multiple containers and workloads without adding separate instrumentation to each one. It can show which pods are communicating, where network latency appears, how much traffic is flowing, or whether connections are being retransmitted.

Kubernetes metadata can then connect this low-level data with clusters, namespaces, pods, and services. This combination makes eBPF particularly useful for Kubernetes networking, observability, performance troubleshooting, and security.

How Does eBPF Work?

eBPF programs are event-driven. Instead of running continuously like a normal application, they are attached to specific points in the kernel or user space and execute when the relevant event occurs.

A simplified flow looks like this:

Event → eBPF hook → eBPF program → Process or store data → User-space tool

For example, an eBPF program can attach to a network event and capture information whenever a new connection is created. Another program might run whenever a particular kernel function executes or an application calls a specific user-space function.

Before an eBPF program can run, the kernel verifies it. The verifier checks properties such as memory access, execution paths, and whether the program can terminate safely. Programs that do not pass verification are rejected.

After verification, programs can be compiled using a Just-In-Time compiler on supported systems so they run efficiently. This combination of verification and efficient execution is one of the reasons eBPF can be used for production monitoring and networking workloads.

What Are eBPF Hooks?

Hooks are points where an eBPF program can attach and wait for an event. Different hook types give eBPF visibility into different parts of the operating system or application.

For example, tracepoints provide predefined kernel events, while kprobes can attach to kernel functions. Uprobes provide similar visibility into functions running in user-space applications, and networking hooks such as XDP can process packets at very early stages of the network stack.

This flexibility is important because teams can observe activity at the level most relevant to the problem they are investigating. A networking tool and a CPU profiler may both use eBPF, but they attach to completely different events.

What Are eBPF Maps?

eBPF programs often need to store information or communicate with user-space applications. They do this using data structures called eBPF maps.

A program might use a map to count network connections, store timestamps, track process information, or aggregate measurements before sending them to a monitoring tool. This allows some processing to happen close to where the events occur rather than exporting every individual event.

In an observability system, an eBPF program may gather low-level measurements while a user-space agent reads the resulting data and sends it to an observability backend.

What are different eBPF use cases?

eBPF started with networking but now supports a much broader set of use cases. The most common areas are observability, networking, security, tracing, and profiling.

eBPF for Observability, Tracing, and Continuous Profiling

eBPF observability uses kernel-level visibility to collect information about application and system behavior. It can observe network connections, system calls, disk activity, processes, and other low-level events without requiring changes to every application.

This is especially useful in cloud-native environments where many services run across containers and different programming languages. An eBPF-based agent can observe multiple workloads from the same node and add visibility that application-level instrumentation may miss.

For example, if an API becomes slow but traces show little additional processing time inside the application, eBPF may reveal a spike in TCP retransmissions between the API and a downstream service. Instead of stopping at "the API is slow," the team can see that requests are waiting on network communication.

This makes eBPF valuable for identifying issues such as network latency, DNS delays, disk I/O, system calls, and scheduling behavior that may not be obvious from traditional application telemetry alone.

eBPF for Tracing

Tracing with eBPF allows engineers to inspect functions, system calls, and other execution events without necessarily modifying the application source code.

For example, engineers can attach probes to kernel functions using kprobes or inspect user-space functions using uprobes. This can help troubleshoot performance problems when traditional application logs or metrics do not explain what is happening.

eBPF tracing tools are particularly useful for short-lived investigations because probes can often be attached dynamically to a running system.

eBPF for Continuous Profiling

eBPF can also be used to continuously sample application stack traces and identify where CPU time is being spent. This makes it useful for continuous profiling and flame graphs.

Instead of instrumenting each application manually, an eBPF profiler can observe multiple processes running on the same machine. OpenTelemetry now has an eBPF-based profiling implementation designed to collect profiling information from Linux workloads.

Profiling helps answer questions that metrics and traces cannot always answer, such as which functions are consuming the most CPU or which code paths are responsible for expensive processing.

eBPF for Networking

Networking remains one of eBPF's strongest use cases. Programs can inspect, route, filter, or modify network traffic directly within the Linux networking stack.

This can be used for high-performance packet processing, load balancing, network policy enforcement, service networking, and detailed network observability. Projects such as Cilium use eBPF extensively for Kubernetes networking and security.

Because packet processing can happen close to the kernel, eBPF can reduce some of the overhead associated with repeatedly moving networking decisions between kernel space and user space. The eBPF project highlights large-scale networking and load balancing as one of the technology's core production use cases.

eBPF for Security

Security tools can use eBPF to observe system calls, process activity, file access, and network behavior. This gives security systems visibility into what applications and workloads are doing at the operating-system level.

For example, eBPF can help detect unexpected process execution, unusual network connections, access to sensitive files, or suspicious system-call patterns. Security systems can then combine this information with container, Kubernetes, or workload context.

The advantage is that visibility happens below the application layer. An application does not need to voluntarily generate a log before the security platform can see many types of activity.

What Are the Benefits of eBPF?

One of the main benefits of eBPF is deep visibility without requiring changes to every application. Since it can observe activity at the operating-system level, a single eBPF-based agent can often monitor workloads written in several languages.

eBPF can also provide visibility that traditional application instrumentation does not have. Network packets, kernel scheduling, system calls, disk operations, and TCP behavior all happen below the application layer, so kernel-level observation can reveal problems that would otherwise be difficult to diagnose.

Another benefit is flexibility. eBPF programs can be attached dynamically to different events, allowing tools to add observability, security, or networking capabilities without rebuilding the Linux kernel.

Performance is also an important part of the design. eBPF programs run close to the events they observe and can aggregate or filter data before sending it to user space, which can reduce unnecessary processing and data movement.

What Are the Limitations of eBPF?

eBPF provides excellent system-level visibility, but it does not automatically understand application intent.

An eBPF tool may know that an HTTP request returned an error or that a particular database connection was slow, but it may not know that the request belonged to a customer checkout, a premium account, or a specific business workflow.

Application-level instrumentation is still important when teams need custom spans, business attributes, user context, application events, or detailed framework information. Dash0 similarly notes that eBPF instrumentation and language-level SDK instrumentation provide different levels of context and often work best together.

eBPF capabilities can also depend on operating-system and kernel support. Different Linux kernel versions expose different hooks and features, so compatibility needs to be considered when deploying eBPF-based tools across older or mixed environments.

Finally, eBPF itself can be complex. Most engineering teams do not write raw eBPF programs directly and instead use tools such as Cilium, bpftrace, BCC, or observability platforms that hide much of the implementation detail.

eBPF vs. Traditional Application Instrumentation

eBPF and traditional application instrumentation observe systems from different layers. eBPF works closer to the operating system and kernel, while application instrumentation works inside the application using SDKs, libraries, or framework integrations.

eBPF does not replace traditional monitoring, logs, metrics, or distributed tracing. Instead, it adds deeper system, network, and runtime visibility that application-level instrumentation may not capture.

In practice, both approaches work well together. An investigation might move from an alert to a metric, then a trace, eBPF network data, and finally application logs to understand the full cause of a problem.

eBPF vs. OpenTelemetry

eBPF and OpenTelemetry solve different problems.

eBPF is a technology for observing and extending operating-system behavior. OpenTelemetry is a standard framework for generating, collecting, processing, and exporting telemetry.

OpenTelemetry instrumentation usually captures application-level traces, metrics, and logs. eBPF can complement that data with kernel, networking, profiling, and automatic application observations.

The two can also work directly together. OpenTelemetry eBPF Instrumentation can use eBPF to observe applications and generate standard OpenTelemetry telemetry that can be exported using OTLP.

A simplified architecture may look like:

Application and kernel activity → eBPF instrumentation → OpenTelemetry telemetry → Collector → Observability platform

This approach allows eBPF to provide automatic visibility while OpenTelemetry provides standardized telemetry and transport.

Is eBPF Safe?

Running programs in a privileged operating-system context naturally raises safety concerns. eBPF addresses part of this risk through its verifier, which analyzes programs before allowing them to execute.

The verifier checks properties such as unsafe memory access, invalid execution paths, and whether program execution can complete within acceptable constraints. Programs that fail these checks are rejected.

However, eBPF should not be interpreted as automatically safe in every situation. Access to loading eBPF programs is itself security-sensitive, and production systems should follow operating-system permissions and security controls appropriate to their environment.

Who Uses eBPF?

eBPF is widely used across cloud infrastructure, networking, security, and observability systems. The eBPF project highlights production usage by organizations including Google, Meta, Netflix, Cloudflare, and others for applications such as network processing, load balancing, security auditing, performance monitoring, and observability.

It is also the foundation of several popular cloud-native projects and tools. Most developers using these platforms may benefit from eBPF without directly writing or managing an eBPF program themselves.

How Do I Get Started With eBPF?

Most teams do not need to start by writing eBPF programs from scratch. The easiest approach is to begin with existing tools such as bpftrace, BCC, Cilium, or an eBPF-enabled observability platform and use them to explore network activity, system calls, CPU usage, or application behavior.

If you want to learn how eBPF programs work, start with basic Linux concepts and then explore hooks, maps, the verifier, and common tracing tools. From there, you can move to frameworks such as libbpf, BCC, or higher-level libraries that simplify loading and managing eBPF programs.

For production use, begin with a specific problem rather than adopting eBPF everywhere at once. For example, use it to investigate network latency, profile CPU usage, or improve Kubernetes visibility, then expand as the use case becomes clear.

The Bottom Line

eBPF is a programmable technology that makes it possible to safely run verified programs in privileged operating-system contexts, most commonly the Linux kernel. It provides detailed visibility into networking, processes, system calls, application functions, and other low-level activity without requiring teams to modify the kernel source code.

Its most common uses today include observability, networking, tracing, continuous profiling, security, and cloud-native infrastructure. In Kubernetes environments especially, eBPF can provide broad visibility across workloads without instrumenting every application independently.

eBPF does not replace application instrumentation or OpenTelemetry. It adds another layer of visibility. Combining kernel-level eBPF data with application traces, metrics, logs, and OpenTelemetry context can provide a much more complete view of how a system behaves.