Guest post originally published on New Relic’s blog by Lavanya Chockalingam, Senior Product Marketing manager at New Relic

Working within the Linux kernel is ideal when implementing security, networking, and observability features. However, it’s not without its challenges. Whether modifying kernel source code or adding modules, developers have traditionally found themselves contending with complicated infrastructure and abstracted layers that are difficult to debug. Extended BPF (eBPF) solves both of these problems.

Extended Berkeley Packet Filter (eBPF) is a kernel technology (starting in Linux 4.x) that allows programs to run without having to change the kernel source code or adding additional modules. You can think of it as a lightweight, sandbox virtual machine (VM) inside the Linux kernel, where programmers can run BPF bytecode that takes advantage of specific kernel resources.

Using eBPF eliminates the need to change kernel source code and streamlines the ability of software to leverage existing layers. As a result, it’s a powerful technology with the potential to fundamentally alter how services like networking, observability, and security are delivered.

Here’s a closer look at what it is, how it works, and when to consider implementing it.

How eBPF works

eBPF programs are event-driven and attached to a code path. The code path contains specific triggers—called hooks—which execute any attached eBPF programs when they’re passed. Some examples of hooks include network events, system calls, function entries, and kernel tracepoints.

When triggered, the code is compiled first to the BPF bytecode. In turn, the bytecode is verified before it runs, to ensure it doesn’t create a loop. This step prevents the program from compromising the Linux kernel either accidentally or on purpose.

After a program is triggered at a hook, it then makes helper calls. These helper calls are functions that equip eBPF with many features for accessing memory. Helper calls need to be pre-defined by the kernel, but the list of what functions exist continues to grow.

eBPF was initially used as a way to increase observability and security when filtering network packets. However, over time, it became a way to make the implementation of user-supplied code safer, more convenient, and better-performing.

The advantages of eBPF

eBPF is typically used to trace user-space processes, and its advantages shine here. It’s a safe and useful method to ensure:

eBPF best practices

Since eBPF is such a new technology, many things remain unexplored. Best practices around eBPF are still evolving as the technology gains prominence. While no defined set of best practices exist, there are a few things that you can do to ensure effective, efficient programs.

If you’re using eBPF for your ecosystem, we recommend that you:

The pitfalls of eBPF

Although it’s powerful, eBPF is not a silver bullet that suits every project or ecosystem. eBPF does have some notable disadvantages, which can make it frustrating to work within certain instances. Some developers might find eBPF inadequate to use because:

When eBPF typically works well

eBPF is rapidly gaining traction in cloud native applications. As a result, eBPF is used most commonly in two situations:

You might also find eBPF deployed for other security measures, including:

New Relic and eBPF

Pixie (acquired by New Relic), is an open source, kubernetes-native-in-cluster observability platform that provides instant visibility into Kubernetes workloads with no manual instrumentation. eBPF provides most of the magic behind the Pixie platform. As described earlier, eBPF allows you to run restricted code when an event is triggered. This event could be a function call either in kernel space(kprobes) or userspace(uprobes). Pixie uses both uprobes and kprobes to enable observability across services and applications. 

Pixie automatically harvests telemetry data by leveraging eBPF, and its edge-machine intelligence connects this data with Kubernetes metadata to provide visibility while maintaining data locality. This visibility complements New Relic’s powerful Kubernetes observability solution. And starting in late May, you’ll be able to send Pixie-generated telemetry data to New Relic One, gaining scalable retention, powerful visualizations, advanced correlation, and intelligent alerting capabilities.

eBPF is observability made efficient

eBPF is a new technology that improves observability, networking, and security in the Linux kernel. It eliminates the need to change kernel source code or add modules, so you can create a richer infrastructure to support your system without overcomplicating it.

We took a look at what eBPF is, how it works, and why it’s so useful in distributed environments. By monitoring from the kernel layer, many of the challenges associated with observability in the cloud are solved. You can enjoy deeper visibility, more context, and more accuracy in your data.

Sign up for New Relic’s free tier and experience the magic of eBPF for observability.