This page lists a number of open source projects that use eBPF as the underlying core technology. These projects are not under the eBPF Foundation but are listed here as a survey of the eBPF project landscape today.
BCC is a toolkit for creating efficient kernel tracing and manipulation programs built upon eBPF, and includes several useful command-line tools and examples. BCC eases writing of eBPF programs for kernel instrumentation in C, includes a wrapper around LLVM, and front-ends in Python and Lua. It also provides a high-level library for direct integration into applications.
bpftrace is a high-level tracing language for Linux eBPF. Its language is inspired by awk and C, and predecessor tracers such as DTrace and SystemTap. bpftrace uses LLVM as a backend to compile scripts to eBPF bytecode and makes use of BCC as a library for interacting with the Linux eBPF subsystem as well as existing Linux tracing capabilities and attachment points.
Cilium is an open source project that provides eBPF-powered networking, security and observability. It has been specifically designed from the ground up to bring the advantages of eBPF to the world of Kubernetes and to address the new scalability, security and visibility requirements of container workloads.
Falco is a behavioral activity monitor designed to detect anomalous activity in applications. Falco audits a system at the Linux kernel layer with the help of eBPF. It enriches gathered data with other input streams such as container runtime metrics and Kubernetes metrics, and allows to continuously monitor and detect container, application, host, and network activity.
Katran is a C++ library and eBPF program to build a high-performance layer 4 load balancing forwarding plane. Katran leverages the XDP infrastructure from the Linux kernel to provide an in-kernel facility for fast packet processing. Its performance scales linearly with the number of NIC's receive queues and it uses RSS friendly encapsulation for forwarding to L7 load balancers.
Website | Git Trees | Mailing List | Patches | CI | Office Hours | Docs
The Linux kernel contains the eBPF runtime required to run eBPF programs. It implements the bpf(2) system call for interacting with programs, maps, BTF and various attachment points where eBPF programs can be executed from. The kernel contains a eBPF verifier in order to check programs for safety and a JIT compiler to translate programs to native machine code. User space tooling such as bpftool and libbpf are also maintained as part of the upstream kernel.
Website | GitHub | Patches | Bugtracker
The LLVM compiler infrastructure contains the eBPF backend required to translate programs written in a C-like syntax to eBPF instructions. LLVM generates eBPF ELF files which contain program code, map descriptions, relocation information and BTF meta data. These ELF files contain all necessary information for eBPF loaders such as libbpf to prepare and load programs into the Linux kernel. The LLVM project also contains additional developer tools such as an eBPF object file disassembler.
Website | GitHub | Office Hours | Slack Channel
The eBPF for Windows project is a work-in-progress that allows using existing eBPF toolchains and APIs familiar in the eBPF ecosystem to be used on top of Windows. That is, this project takes existing eBPF projects as submodules and adds the layer in between to make them run on top of Windows.
An extended Berkley Packet Filter CPU implemented in hardware on FPGA. In contrast to classic HDL languages like Verilog or VHDL, Migen/LiteX (both based on Python) where used. Supports custom extensions to 'call' opcode and includes full test suite for each opcode for included emulator and simulator as well as for included hardware targets.
eBPF is designed as a pure Go library that provides utilities for loading, compiling, and debugging eBPF programs. It has minimal external dependencies and is intended to be used in long running processes.
libbpfgo is a Go wrapper around libbpf. It supports BPF CO-RE and its goal is to be a complete implementation of libbpf APIs. It uses CGo to call into linked versions of libbpf.
Major: libbpf
libbpf is a C/C++ based library which is maintained as part of the upstream Linux kernel. It contains an eBPF loader which takes over processing LLVM generated eBPF ELF files for loading into the kernel. libbpf received a major boost in capabilities and sophistication and closed many existing gaps with BCC as a library. It also supports important features not available in BCC such as global variables and BPF skeletons.
Major: libbpf-rs | redbpf
Emerging: Aya
libbpf-rs is a safe, idiomatic, and opinionated wrapper API around libbpf written in Rust. libbpf-rs, together with libbpf-cargo (libbpf cargo plugin) allows to write 'compile once run everywhere' (CO-RE) eBPF programs.
redbpf is a Rust eBPF toolchain that contains a collection of Rust libraries to work with eBPF programs.
Aya is an eBPF library built with a focus on operability and developer experience. It allows for both eBPF programs and their userspace programs to be written in Rust.
Hubble is a fully distributed networking and security observability platform for cloud native workloads. It is built on top of Cilium and eBPF to enable deep visibility into the communication and behavior of services as well as the networking infrastructure in a completely transparent manner.
kubectl-trace is a kubectl plugin that allows for scheduling the execution of bpftrace(8) programs in Kubernetes clusters. kubectl-trace does not require installation of any components directly onto a Kubernetes cluster in order to execute bpftrace programs. When pointed to a cluster, it schedules a temporary job called trace-runner that executes bpftrace.
L3AF is a platform to launch and manage eBPF programs in distributed environments. L3AF empowers users to compose multiple eBPF programs together to solve unique problems in different environments. Using the APIs provided by L3AF, these eBPF programs can be reconfigured, updated, inspected, and reordered on-the-fly. L3AF also provides configurable metrics for the eBPF programs it has launched.
Pixie is an open source observability tool for Kubernetes applications. Pixie uses eBPF to automatically capture telemetry data without the need for manual instrumentation. Developers can use Pixie to view the high-level state of their cluster (service maps, cluster resources, application traffic) and also drill down into more detailed views (pod state, flame graphs, individual full body application requests).
ply is a dynamic tracer for Linux which is built upon eBPF. It has been designed with embedded systems in mind, is written in C and all that ply needs to run is libc and a modern Linux kernel with eBPF support, meaning, it does not depend on LLVM for its program generation. It has a C-like syntax for writing scripts and is heavily inspired by awk(1) and dtrace(1).
Tracee uses eBPF technology to detect and filter operating system events, helping you expose security insights, detect suspicious behavior, and capture forensic indicators.
BumbleBee simplifies building eBPF tools and allows you to package, distribute, and run eBPF programs using OCI images. It allows you to just focus on the eBPF portion of your code and BumbleBee automates away the boilerplate, including the userspace code.
Add your project
- Make sure that the project is meeting the requirements to be listed. See below.
- Open a pull request and provide the required information. Use one of the already listed projects as a template.
- The pull request will be reviewed by the community and merged by one of the maintainers. If you have any questions, feel free to ask on Slack.
Are you maintaining a listed project?
- If you are maintaining one of the listed projects and would like to adjust the content. Get in touch on Slack or open a pull request directly.
Requirements for a project to be listed
Projects can be listed on this page as "Major" or "Emerging". The requirements for being listed as "Emerging" are:
- The project must be open source. All source code must be licensed under an open source license. Any documentation must be licensed under an open license.
- The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed.
- The project must be open to collaboration and have a governance model following open-source best-practices.
In order to be listed as a "Major" project, a project must meet all of the requirements above, plus:
- The project must have more than 50 contributors.
- The project must be actively maintained.
- The project must be used in production-like environments with a significant amount of users. Since this information may not be easily discoverable from a link to the project, such information should be included in the pull request description.