eBPF may sound like just another dense technical acronym. But the term--which is short for extended Berkeley Packet Filter--is gaining buzz as more and more organizations leverage eBPF to provide low-level visibility into complex systems. Here's everything you need to know about what extended Berkeley Packet Filter is, how eBPF works and why eBPF is important in modern, cloud-native environments.
What Is Extended Berkeley Packet Filter?
Extended Berkeley Packet Filter is an interface within the Linux kernel that makes it possible to run custom code within the kernel itself. There are other ways to run programs in kernel mode on Linux, like loading a kernel module. And, of course, most programs in Linux don’t need to run in the kernel in the first place. But extended Berkeley Packet Filter has three killer features that make it different from other Linux-based programs:
- Low-level access: Because extended Berkeley Packet Filter programs run inside the kernel, they can access low-level system resources that would otherwise not be directly available to conventional, user space programs. That's a powerful advantage if you need to monitor or collect data from processes running deep inside a Linux environment.
- Simplicity: Running extended Berkeley Packet Filter programs doesn't require making changes to the kernel code itself, so you don't need to run a custom kernel or recompile anything to take advantage of eBPF. You don't even need to load any kernel modules. You just need a way to interface with the eBPF framework, which is built into the kernel by default.
- Lightweight: Programs run through extended Berkeley Packet Filter consume minimal resources. That means you pay a negligible "cost" to collect data through eBPF.
How Long Has eBPF Been Around?
The roots of extended Berkeley Packet Filter can be traced back to the Berkeley Packet Filter, which was first implemented in the 1990s as a way to help monitor networking operations in Linux and other Unix-like systems.
eBPF, which can be used to do much more than just monitor networking (hence, the name extended Berkeley Packet Filter), was introduced into the Linux kernel in 2014.
Why Is eBPF Important Today?
At first, the integration of eBPF into the Linux kernel didn't generate much fanfare, partly because tools that make it easy to write and deploy eBPF programs didn’t mature until a couple of years after eBPF was introduced. But eBPF has become a hot topic during the past few years within communities focused on monitoring--including both application performance monitoring and security monitoring. This is because eBPF provides unparalleled advantages for collecting information about application performance and security. By making it possible, in essence, to peer deep inside the Linux kernel and monitor how the system handles transactions at the lowest level, eBPF allows teams to gain much deeper visibility than they could by monitoring surface-level data alone.
For example, consider network monitoring. Traditionally, your only real source of visibility into network performance was tracking traffic as it flowed across the network itself and looking at sources like logs. If you wanted to figure out exactly what happened to individual packets when they were sent or received by an application, there wasn't a great way to do that, unless you customized the operating system in such a way that it would expose that data--which was rarely practical to do.
With extended Berkeley Packet Filter, you can write a program to perform low-level traces inside the operating system without any special configuration to the operating system.
eBPF is also especially handy in situations where collecting conventional monitoring data is difficult or impossible--such as when you are dealing with applications running in ephemeral containers. Because eBPF collects data at the operating system level rather than from inside applications or containers, it allows you to trace whatever you want without having to figure out a way to get the data out of the container--and without even having to run any special code inside the container (or a sidecar) to get the data.
In some ways, eBPF exemplifies the differences between observability and monitoring. Traditionally, IT teams merely monitored what happened on the surface of their environments. Technologies like eBPF help to enable complete observability by allowing engineers to trace what is happening deep inside systems.
Who Benefits from eBPF?
Extended Berkeley Packet Filter offers advantages for stakeholders across the IT organization. For developers, it means much less time spent writing and building custom kernel code to figure out what is happening inside the kernel. For IT teams, it simplifies monitoring stacks by reducing the number of tools engineers need to deploy to gain visibility into systems.
And for business stakeholders, eBPF can help enable more efficient and more reliable systems. The fact that eBPF and many of the core tools associated with it are open source technology sweetens the deal, too, because it means businesses don't need to invest in expensive proprietary technology to take advantage of eBPF.
How Can You Get eBPF?
If you're running a Linux kernel built any time in the past six or seven years, eBPF should already be installed. However, to interact with it, you'll typically want to use a tool that makes it easy to write and deploy programs that interface with the eBPF backend. Examples include bpftrace and Cilium.
Some proprietary monitoring and observability platforms, like Flowmill (which was acquired by Splunk in 2020) and Kentik, have also begun to integrate eBPF as one method of achieving visibility into complex systems. So, if you don't want to do the dirty work of managing eBPF programs and analyzing the data they generate yourself, you can deploy a commercial observability suite that uses eBPF under the hood.
