kernel-collector
kernel-collector copied to clipboard
Linux Kernel eBPF Collectors
kernel-collector
Linux Kernel eBPF Collectors
Directory structure
The respository has the following directory structure:
-
artifacts
: directory that will have the eBPF programs when the compilation process ends. -
co-re
: contains all eBPF programs that utilize eBPF CO-RE (Compile Once - Run Everywhere) technology.-
tests
: contains test cases for our eBPF CO-RE programs.
-
-
docs
: contains an assortment of documentation related to this repository. -
includes
: headers used throughout the project. -
kernel
: contains all eBPF programs that don't utilize eBPF CO-RE technology; these may be considered legacy more and more as time progresses and we shift fully to CO-RE. -
kernel-patches
: contains patches needed to properly compile our legacykernel/
eBPF programs on some kernel versions. -
libbpf
: this is a submodule'd fork of netdata/libbpf which is itself a fork of the officiallibbpf
package, the user-space side of eBPF system calls. -
tools
: scripts used to verify system status before installing eBPF code.
Requirements
Packages
To compile the eBPF programs, it will be necessary to have the following packages:
- libelf headers
- LLVM/Clang; this is because GCC prior to 10.0 cannot compile eBPF code.
- Kernel headers
Initializing Submodules
libbpf
directory is included as a git submodule and it is necessary to fetch contents with the git command below:
git submodule update --init --recursive
Generating Headers
Kernel headers can be extracted directly from the kernel source doing the
following steps (assumes your kernel source is accessible at /usr/src/linux
):
cd /usr/src/linux
make defconfig
make scripts
make prepare
make headers_install
Misc
In case you are using the kernel 5.4
or newer, please comment out the
following line inside the file generated/autoconf.h
:
#define CONFIG_CC_HAS_ASM_INLINE 1
Makefiles
It's also possible that you'll need to change the Makefile
s in this
repository according your environment. The original files were adjusted to
compile on Slackware Linux Current.
Inside kernel/Makefile
, you may need to change the following variables:
-
KERNELSOURCE
: Where is your kernel-source? This variable was set initially to work on Slackware, Fedora and Ubuntu. -
LINUXINCLUDE
: Depending on the Linux distribution, it may be necessary to add or remove directories from this variable. -
LLVM_INCLUDES
: Depending on the kernel version, it may be necessary to change this path.
Building with Docker
There are two build environments that produce different variants of libc and the Linux Kernel.
The build environments are:
-
musl
=>Dockerfile.musl
(based on Alpine 3.11) -
glibc
=>Dockerfile.glibc.generic
(based on Ubuntu 20.04)
glibc
$ docker build -f Dockerfile.glibc.generic -t kernel-collector:glibc ./
$ docker run --rm -v $PWD:/kernel-collector kernel-collector:glibc
musl
$ docker build -f Dockerfile.musl -t kernel-collector:musl ./
$ docker run --rm -v $PWD:/kernel-collector kernel-collector:musl
Different Kernel
To build for a different Kernel version rather than the default just pass the
--build-arg KERNEL_VERSION=<kernel_version>
argument to the docker build
.
For example:
$ docker build -f Dockerfile.musl -t kernel-collector:musl_5_4 --build--arg KERNEL_VERSION=5.4.18 ./
$ docker run --rm -v $PWD:/kernel-collector kernel-collector:musl_5_4
Building with Debug Symbols
To build with debug symbols enabled, set the environment variable DEBUG
to 1
when running the build image.
For example:
$ docker build -f Dockerfile.musl -t kernel-collector:musl ./
$ docker run --rm -e DEBUG=1 -v $PWD:/kernel-collector kernel-collector:musl
This sets EXTRA_CFLAGS=-g
before building.
Manual Compilation
After you've got your kernel/Makefille
properly setup, you can run the
following command to compile all the eBPF programs:
# build in parallel jobs equal to `nproc` (number of processors)
$ make -j`nproc`
When compilation finishes, you will have a file inside the artifacts
directory with contents like the following:
pnetdata_ebpf_process.<kernel version>.o
pnetdata_ebpf_socket.<kernel version>.o
rnetdata_ebpf_process.<kernel version>.o
rnetdata_ebpf_socket.<kernel version>.o
...
p*.o
: eBPF programs used with entry mode, this is the default mode.
r*.o
: eBPF programs used with return mode.
These files have to be copied to your plugins directory, which is usually at
/usr/libexec/netdata/plugins.d/
, for the collector to be able to access them.
After this you can start the new collector ebpf_program.plugin
.
Releasing
To release a new version and create a Github Release:
-
Create a Git tag like so:
$ TAG="v0.0.1"; git tag -a -s -m "Release ${TAG}" "${TAG}" && git push origin "${TAG}"
Replace
v0.0.1
with the next desired tag. SemVer is not strictly being followed here at this time so the specific tagged versions is not so important.This will kick off a Github Action Workflow that will Rebuild the Netdata eBPF Kernel Collector for all Kernel and LIBC variants, create a Github Release and upload all assets to the release to be consumed by anyone or the Netdata Installer.
-
Wait for the CD pipeline to finish in the Github Actions UI.
-
Review the Release, Updates Release Notes, etc in the Github Releases UI.
-
Push the "Publish Release" button in the Github Releases UI.
Contribution
Netdata is open-source software and we are always open for contributions that you can give us.
If you want to contribute an eBPF program, then please be sure that your program matches the following patterns:
- Your program must run on all kernels since at least kernel
4.11
. - Write some code that's responsible to measure the latency of your program.
- We have the variable NETDATASEL, that selects where the functions will be
attached. Be sure that inside your code
0
is associatedkretprobe
, and2
is assoacited withkprobe
.