Zero Code Observability with eBPF.

Nov 9, 2021. By Anil Abraham Kuriakose

Tweet Share Share

Zero Code Observability with eBPF

Current observability practices are primarily based on manual instrumentation. This process requires adding relevant code into the user’s custom application logic to generate observability and telemetry inputs. This approach can become quite overhead and create an entry barrier for many IT teams planning to implement observability in their customer application environment. Even this is applicable for microservices-based applications running in containers and orchestrated with Kubernetes.

What is eBPF? In Linux, memory utilization is split between kernel space and user-space. The kernel space memory is used by the core of the operating system components. The kernel space has full and unrestricted access to all hardware — memory, storage, CPU, etc. Due to the restricted access of the kernel space, kernel space is protected and allows to run only the most trusted code, which includes the kernel itself and various device drivers. The eBPF is a mechanism for Linux applications to execute code in Linux kernel space. eBPF has already been used to create networking, debugging, tracing, firewalls, and more programs.

The eBPF is an extended and newer version of the BPF based Linux system observability instrumentation. With eBPF, one can attach custom and system-specific bytecode to all functions exported via the kernel symbol table without impacting the kernel activities. The eBPF took care of kernel space's safety aspect when crossing the user space boundaries. The kernel verification module will refuse to load any eBPF program if invalid pointer de -references are detected or once the system reaches the maximum stack size limit. The eBPF are not allowed loops except loops with constant upper bounds reached at the compile time. From the bytecode, eBPF is exposed to call only a small subset of specific helper functions. The eBPF programs are automatically get terminated at some point and never exhausted any system resources. Hence there is no system instability or any kernel panic issues. Conversely, some might find eBPF too restrictive compared to the "freedom" kernel modules offer. Still, the trade-offs are likely to favor eBPF over "module-oriented" instrumentation mainly because of the guarantee that eBPF programs cannot harm the kernel. However, that's not the only benefit.

What is eBPF Observability? An eBPF program can be used to support different use cases like kernel security monitoring and system reliability engineering. And another most essential use case is system monitoring and observability. The eBPF is part of the Linux core, and it doesn't depend on any other applications or third-party components. Since the eBPF is sitting along with the kernel, it can collect system performance and reliability data with a lot of granularity and detail that other tools instrumenting at the userspace are not possible. Also, eBPF enables monitoring process-by-process details, network packet details, filesystem details, input-output details, and kernel and device driver details. Also, it can manage the kernel version changes with a stable application binary interface (ABI). Also, eBPF will not introduce any performance overhead and help system administrators trace heavily loaded systems without impacting the workload performance. The eBPF is mainly used in Linux systems, and there is no equivalent module in windows systems. But they can get similar data from the Windows event tracking module.

eBPF for observability into container apps and services In the recent past, container adoption increased, and there is a need to build observability around apps and backing services running in containers. Furthermore, the observability should allow capturing demand metrics from low-level components with very minimal overhead. The best tool here is eBPF because we can use it to capture details at the kernel & user level and generate on-demand reports, graphs, heat maps for containers, microservices, and applications.

Since containers are well integrated with the Linux kernel, a built-in BPF JIT compiler and an in-kernel verifier are used to validate eBPF programs. This allows container applications to do user-defined instrumentation on a live kernel image that can never crash, hang, or interfere negatively with the kernel. eBPF provides an in-kernel implementation of storage maps such as histograms and hash-maps, which helps efficiently copy summarized monitoring data from kernel to user space with low overhead.

These features make eBPF programs safe to run in production and allow admins and engineers to collect crucial data from systems for performance analysis and monitoring.

The eBPF utility doesn't solve every problem under the sun. It works only on Linux, so it's of no help for monitoring Windows-based environments. At the time of publication, admins need root access to use most of its features. And while tools like bpftrace and bcc make it relatively easy to write and deploy eBPF programs, they are still maturing.

To learn more about system and container observability, please visit our observability page

Share this blog.

Tweet Share Share