# What Is eBPF and Why Does It Matter for Observability?
URL:: https://newrelic.com/blog/best-practices/what-is-ebpf
Author:: Lavanya Chockalingam
## Highlights
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c1xp0gvss0dg0cxhg1g3t))
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c2hmvgjn5kvdpay07wmb6))
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c2jcks1tckd2n0cpsp6vt))
> 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](https://man7.org/linux/man-pages/man7/bpf-helpers.7.html). ([View Highlight](https://read.readwise.io/read/01fp0c33hqc6m7cafsvr3nhvwx))
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c36skhvtkczz2b2t611hx))
> • **Speed and performance.** eBPF can move packet processing from the kernel-space and into the user-space. Likewise, eBPF is a just-in-time (JIT) compiler. After the bytecode is compiled, eBPF is invoked rather than a new interpretation of the bytecode for every method.
> • **Low intrusiveness.** When leveraged as a debugger, eBPF doesn’t need to stop a program to observe its state.
> • **Security.** Programs are effectively sandboxed, meaning kernel source code remains protected and unchanged. The verification step ensures that resources don’t get choked up with programs that run infinite loops.
> • **Convenience.** It’s less work to create code that hooks kernel functions than it is to build and maintain kernel modules.
> • **Unified tracing.** eBPF gives you a single, powerful, and accessible framework for tracing processes. This increases visibility and security.
> • **Programmability.** Using eBPF helps increase the feature-richness of an environment without adding additional layers. Likewise, since code is run directly in the kernel, it’s possible to store data between eBPF events instead of dumping it like other tracers do.
> • **Expressiveness.** eBPF is expressive, capable of performing functions usually only found in high-level languages. ([View Highlight](https://read.readwise.io/read/01fp0c42scrzknbgw659pybqns))
> Some developers might find eBPF inadequate to use because:
> • **It’s restricted to Linux and a recent kernel.** eBPF was developed in the Linux kernel and is completely oriented around it. That makes it less portable than other tracers. Additionally, you need a fairly recent kernel. If you’re running anything older than v 4.13, you won’t be able to use it.
> • **Sandboxed programs are limited.** eBPF derives increased security by limiting what resources programs can access. However, by limiting what parts of the OS a program can access, functionality is also potentially limited. ([View Highlight](https://read.readwise.io/read/01fp0c5284jdq1wpe7nn1f9sre))
> When eBPF typically works well
> eBPF is rapidly gaining traction in [cloud native applications](https://newrelic.com/solutions/cloud-native). As a result, eBPF is used most commonly in two situations:
> • **There’s a need for observability using kernel tracing.** In this situation, eBPF is faster and more accurate. There are no [context switches](https://www.quora.com/What-is-context-switching-in-Linux) involved, and eBPF programs are event-based so nothing runs without a specific trigger—and you won’t miss any occurrences.
> • **Traditional security monitoring doesn’t work.** eBPF is finding lots of uses in distributed and container-based environments, including [Kubernetes](https://kubernetes.io/blog/2017/12/using-ebpf-in-kubernetes/). In these environments, eBPF can close the visibility gap because it can provide visibility into [HTTP traffic](https://blog.pixielabs.ai/ebpf-http-tracing/). ([View Highlight](https://read.readwise.io/read/01fp0c7vx86p53xd2naz4dc3cj))
> [Pixie](http://pixielabs.ai/) (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. ([View Highlight](https://read.readwise.io/read/01fp0c8bvcyz42ys5tcn8axvpa))
> eBPF is observability made efficient ([View Highlight](https://read.readwise.io/read/01fsy16ms5nh3jbvx8phmesncv))
> 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. ([View Highlight](https://read.readwise.io/read/01fsy16xvmzvpe78j1zd7dwxa7))
---
Title: What Is eBPF and Why Does It Matter for Observability?
Author: Lavanya Chockalingam
Tags: readwise, articles
date: 2024-01-30
---
# What Is eBPF and Why Does It Matter for Observability?
URL:: https://newrelic.com/blog/best-practices/what-is-ebpf
Author:: Lavanya Chockalingam
## AI-Generated Summary
What is eBPF? Here’s everything to know about this new Linux kernel technology that’s revolutionizing observability in distributed environments.
## Highlights
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c1xp0gvss0dg0cxhg1g3t))
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c2hmvgjn5kvdpay07wmb6))
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c2jcks1tckd2n0cpsp6vt))
> 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](https://man7.org/linux/man-pages/man7/bpf-helpers.7.html). ([View Highlight](https://read.readwise.io/read/01fp0c33hqc6m7cafsvr3nhvwx))
> 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. ([View Highlight](https://read.readwise.io/read/01fp0c36skhvtkczz2b2t611hx))
> • **Speed and performance.** eBPF can move packet processing from the kernel-space and into the user-space. Likewise, eBPF is a just-in-time (JIT) compiler. After the bytecode is compiled, eBPF is invoked rather than a new interpretation of the bytecode for every method.
> • **Low intrusiveness.** When leveraged as a debugger, eBPF doesn’t need to stop a program to observe its state.
> • **Security.** Programs are effectively sandboxed, meaning kernel source code remains protected and unchanged. The verification step ensures that resources don’t get choked up with programs that run infinite loops.
> • **Convenience.** It’s less work to create code that hooks kernel functions than it is to build and maintain kernel modules.
> • **Unified tracing.** eBPF gives you a single, powerful, and accessible framework for tracing processes. This increases visibility and security.
> • **Programmability.** Using eBPF helps increase the feature-richness of an environment without adding additional layers. Likewise, since code is run directly in the kernel, it’s possible to store data between eBPF events instead of dumping it like other tracers do.
> • **Expressiveness.** eBPF is expressive, capable of performing functions usually only found in high-level languages. ([View Highlight](https://read.readwise.io/read/01fp0c42scrzknbgw659pybqns))
> Some developers might find eBPF inadequate to use because:
> • **It’s restricted to Linux and a recent kernel.** eBPF was developed in the Linux kernel and is completely oriented around it. That makes it less portable than other tracers. Additionally, you need a fairly recent kernel. If you’re running anything older than v 4.13, you won’t be able to use it.
> • **Sandboxed programs are limited.** eBPF derives increased security by limiting what resources programs can access. However, by limiting what parts of the OS a program can access, functionality is also potentially limited. ([View Highlight](https://read.readwise.io/read/01fp0c5284jdq1wpe7nn1f9sre))
> When eBPF typically works well
> eBPF is rapidly gaining traction in [cloud native applications](https://newrelic.com/solutions/cloud-native). As a result, eBPF is used most commonly in two situations:
> • **There’s a need for observability using kernel tracing.** In this situation, eBPF is faster and more accurate. There are no [context switches](https://www.quora.com/What-is-context-switching-in-Linux) involved, and eBPF programs are event-based so nothing runs without a specific trigger—and you won’t miss any occurrences.
> • **Traditional security monitoring doesn’t work.** eBPF is finding lots of uses in distributed and container-based environments, including [Kubernetes](https://kubernetes.io/blog/2017/12/using-ebpf-in-kubernetes/). In these environments, eBPF can close the visibility gap because it can provide visibility into [HTTP traffic](https://blog.pixielabs.ai/ebpf-http-tracing/). ([View Highlight](https://read.readwise.io/read/01fp0c7vx86p53xd2naz4dc3cj))
> [Pixie](http://pixielabs.ai/) (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. ([View Highlight](https://read.readwise.io/read/01fp0c8bvcyz42ys5tcn8axvpa))
> eBPF is observability made efficient ([View Highlight](https://read.readwise.io/read/01fsy16ms5nh3jbvx8phmesncv))
> 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. ([View Highlight](https://read.readwise.io/read/01fsy16xvmzvpe78j1zd7dwxa7))