系统监控采集工具netdata-1.38.1源码

<!-- title: "Kernel traces/metrics (eBPF) monitoring with Netdata" description: "Use Netdata's extended Berkeley Packet Filter (eBPF) collector to monitor kernel-level metrics about yourcomplex applications with per-second granularity." custom_edit_url: "https://github.com/netdata/netdata/edit/master/collectors/ebpf.plugin/README.md" sidebar_label: "Kernel traces/metrics (eBPF)" learn_status: "Published" learn_topic_type: "References" learn_rel_path: "References/Collectors references/System metrics" --> # eBPF monitoring with Netdata The Netdata Agent provides many [eBPF](https://ebpf.io/what-is-ebpf/) programs to help you troubleshoot and debug how applications interact with the Linux kernel. The `ebpf.plugin` uses [tracepoints, trampoline, and2 kprobes](#how-netdata-collects-data-using-probes-and-tracepoints) to collect a wide array of high value data about the host that would otherwise be impossible to capture. > ❗ eBPF monitoring only works on Linux systems and with specific Linux kernels, including all kernels newer than `4.11.0`, and all kernels on CentOS 7.6 or later. For kernels older than `4.11.0`, improved support is in active development. This document provides comprehensive details about the `ebpf.plugin`. For hands-on configuration and troubleshooting tips see our [tutorial on troubleshooting apps with eBPF metrics](https://github.com/netdata/netdata/blob/master/docs/guides/troubleshoot/monitor-debug-applications-ebpf.md). <figure> <img src="https://user-images.githubusercontent.com/1153921/74746434-ad6a1e00-5222-11ea-858a-a7882617ae02.png" alt="An example of VFS charts, made possible by the eBPF collector plugin" /> <figcaption>An example of virtual file system (VFS) charts made possible by the eBPF collector plugin.</figcaption> </figure> ## How Netdata collects data using probes and tracepoints Netdata uses the following features from the Linux kernel to run eBPF programs: - Tracepoints are hooks to call specific functions. Tracepoints are more stable than `kprobes` and are preferred when both options are available. - Trampolines are bridges between kernel functions, and BPF programs. Netdata uses them by default whenever available. - Kprobes and return probes (`kretprobe`): Probes can insert virtually into any kernel instruction. When eBPF runs in `entry` mode, it attaches only `kprobes` for internal functions monitoring calls and some arguments every time a function is called. The user can also change configuration to use [`return`](#global-configuration-options) mode, and this will allow users to monitor return from these functions and detect possible failures. In each case, wherever a normal kprobe, kretprobe, or tracepoint would have run its hook function, an eBPF program is run instead, performing various collection logic before letting the kernel continue its normal control flow. There are more methods to trigger eBPF programs, such as uprobes, but currently are not supported. ## Configuring ebpf.plugin The eBPF collector is installed and enabled by default on most new installations of the Agent. If your Agent is v1.22 or older, you may to enable the collector yourself. ### Enable the eBPF collector To enable or disable the entire eBPF collector: 1. Navigate to the [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory). ```bash cd /etc/netdata ``` 2. Use the [`edit-config`](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) script to edit `netdata.conf`. ```bash ./edit-config netdata.conf ``` 3. Enable the collector by scrolling down to the `[plugins]` section. Uncomment the line `ebpf` (not `ebpf_process`) and set it to `yes`. ```conf [plugins] ebpf = yes ``` ### Configure the eBPF collector You can configure the eBPF collector's behavior to fine-tune which metrics you receive and [optimize performance]\(#performance opimization). To edit the `ebpf.d.conf`: 1. Navigate to the [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory). ```bash cd /etc/netdata ``` 2. Use the [`edit-config`](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#use-edit-config-to-edit-configuration-files) script to edit [`ebpf.d.conf`](https://github.com/netdata/netdata/blob/master/collectors/ebpf.plugin/ebpf.d.conf). ```bash ./edit-config ebpf.d.conf ``` You can now edit the behavior of the eBPF collector. The following sections describe each configuration option in detail. ### `[global]` configuration options The `[global]` section defines settings for the whole eBPF collector. #### eBPF load mode The collector uses two different eBPF programs. These programs rely on the same functions inside the kernel, but they monitor, process, and display different kinds of information. By default, this plugin uses the `entry` mode. Changing this mode can create significant overhead on your operating system, but also offer valuable information if you are developing or debugging software. The `ebpf load mode` option accepts the following values: - `entry`: This is the default mode. In this mode, the eBPF collector only monitors calls for the functions described in the sections above, and does not show charts related to errors. - `return`: In the `return` mode, the eBPF collector monitors the same kernel functions as `entry`, but also creates new charts for the return of these functions, such as errors. Monitoring function returns can help in debugging software, such as failing to close file descriptors or creating zombie processes. - `update every`: Number of seconds used for eBPF to send data for Netdata. - `pid table size`: Defines the maximum number of PIDs stored inside the application hash table. #### Integration with `apps.plugin` The eBPF collector also creates charts for each running application through an integration with the [`apps.plugin`](https://github.com/netdata/netdata/blob/master/collectors/apps.plugin/README.md). This integration helps you understand how specific applications interact with the Linux kernel. If you want to enable `apps.plugin` integration, change the "apps" setting to "yes". ```conf [global] apps = yes ``` When the integration is enabled, eBPF collector allocates memory for each process running. The total allocated memory has direct relationship with the kernel version. When the eBPF plugin is running on kernels newer than `4.15`, it uses per-cpu maps to speed up the update of hash tables. This also implies storing data for the same PID for each processor it runs. #### Integration with `cgroups.plugin` The eBPF collector also creates charts for each cgroup through an integration with the [`cgroups.plugin`](https://github.com/netdata/netdata/blob/master/collectors/cgroups.plugin/README.md). This integration helps you understand how a specific cgroup interacts with the Linux kernel. The integration with `cgroups.plugin` is disabled by default to avoid creating overhead on your system. If you want to _enable_ the integration with `cgroups.plugin`, change the `cgroups` setting to `yes`. ```conf [global] cgroups = yes ``` If you do not need to monitor specific metrics for your `cgroups`, you can enable `cgroups` inside `ebpf.d.conf`, and then disable the plugin for a specific `thread` by following the steps in the [Configuration](#configuring-ebpfplugin) section. #### Collect PID When one of the previous integrations is enabled, `ebpf.plugin` will use Process Identifier (`PID`) to identify the process group for which it needs to plot data. There are different ways to collect PID, and you can select the way `ebpf.plugin` collects data with the following values: - `real parent`: This is the default mode. Collection will aggregate data for th