When Not to Use eBPF for Observability and Security

The extended Berkeley Packet Filter, or eBPF, is often touted as a "revolutionary" technology (including by me) for observability, security, and other use cases where the ability to peer deep inside an operating system is valuable.

But that doesn't mean eBPF is the right tool for every job a sysadmin may face. As this article explains, it's important to know when not to use eBPF, and when to stick with more traditional methods of observing, securing, and otherwise managing systems.

A Short Definition of eBPF

Before delving into reasons why you shouldn't always use eBPF, let's define what eBPF means and why folks are so excited about it.

eBPF is a framework built into modern versions of Linux that makes it possible to run custom programs in kernel space. What that means in non-overly technical terms is that with eBPF, you can execute code that allows you to collect data directly from the operating system to determine what's happening on a server or computer.

That's a big deal because conventionally, the only way to monitor a system is to rely on software that runs in user space. Interfacing with the operating system from user space is much less efficient than running monitoring software directly inside the operating system (or more specifically, in the kernel, which is the core of the operating system). As a result, workflows like system monitoring take longer and consume more resources when you perform them using user space software.

Related:Observability vs. Monitoring: Who Needs Which When?

With eBPF, though, you can collect information necessary to detect performance problems, troubleshoot issues, manage security risks, and more in a hyper-efficient way.

The Limitations and Drawbacks of eBPF Observability

eBPF is a really powerful technology, and there's good reason to be excited by it. But it also has some drawbacks that make it a less than ideal fit for some use cases.

Windows lacks eBPF support

Currently, eBPF works only on Linux. Microsoft is actively working on a version of eBPF for Windows, but it's unclear when (or if) it will be production-ready.

So, for now, you have to use Linux if you want to take advantage of eBPF.

The complexity of eBPF programming

Writing eBPF programs that can execute in kernel space is a complex task. The programs are usually written in familiar languages, like C, but you need specialized knowledge of eBPF and low-level Linux kernel processes to author eBPF code.

That may be fine if you're a seasoned C programmer who has been living and breathing Unix-like operating systems since the days of System V. But if your programming skills are limited to churning out basic Python code, eBPF might not be the tool for you.

Related:AI-Powered Apps Bring a New Level of Observability Challenges

eBPF requires privileged mode to be secure

To execute eBPF programs, you need root access to a server in most cases.

It's possible to configure a server to support eBPF for users who are not root. That's known as unprivileged eBPF. However, because giving ordinary users the ability to execute code of their choosing in kernel space is pretty insecure (to put it mildly), you would almost never do that on a production system.

What this means is that eBPF is only practical in situations where you have root-level access to a server. You can't, for example, use eBPF to monitor the physical infrastructure in a public cloud platform because only the cloud provider has root access to its servers.

eBPF is constantly changing

All Linux kernels since version 4.16, which debuted in 2018, support eBPF. However, eBPF has evolved since its introduction, and eBPF on one kernel might work differently than eBPF on a different kernel.

As a result, it can be challenging to use eBPF as the basis for tasks like observability and security when you need to support multiple servers that run markedly different versions of Linux. In that case, you may find yourself having to tweak your eBPF programs to adapt them to the different kernels, a task that could be more complicated than simply relying on user space tools that work consistently across all kernels. (In general, kernel versions have much less of an impact on how user space software behaves.)

You need other tools to work with eBPF data

eBPF is a super-efficient way of collecting data from servers, but eBPF doesn't do anything to help you analyze that data or detect relevant trends. For those tasks, you'll need to feed your data into other tools.

If you don't mind setting data pipelines, this isn't a big deal. But if you prefer an all-in-one observability or security solution, you'll be better served by a platform that both collects and helps analyze your data.

It's worth noting that some monitoring and observability tools now offer eBPF collectors that simplify the process of collecting data via eBPF and feeding it into environments where admins can analyze it. For now, however, that approach remains relatively rare, as most tools rely on traditional strategies that involve user space data collection agents.

Conclusion: eBPF: An Amazing Tool That Not Everyone Needs

In sum, the people who should use eBPF are those who need to observe or secure Linux environments, have extensive programming and operating system expertise, have full access to their servers, and can handle the setup and maintenance of complex data analytics pipelines.

For everyone else, the power of eBPF may be outweighed by its complexity. eBPF is a great tool, but for some teams and use cases, traditional observability and security software is a better solution.