Identifying memory leaks in complex Linux server environments is traditionally a reactive, post-mortem exercise. Administrators typically rely on tools like top or htop to monitor aggregate memory consumption. When the server inevitably runs out of RAM, the Linux Out-Of-Memory (OOM) killer indiscriminately terminates the offending process, leaving behind minimal diagnostic data. To transition from reactive rebooting to proactive identification, Ubuntu Server administrators must implement real-time, kernel-level monitoring. By combining the Netdata monitoring agent with the power of Extended Berkeley Packet Filter (eBPF) technology, administrators can trace memory allocation at the exact moment a leak occurs.
The Limitations of User-Space Monitoring
Traditional monitoring tools query the /proc filesystem at fixed intervals (usually every few seconds) to calculate memory usage. If a specific daemon (like a poorly optimised Python application or a rogue Java garbage collector) allocates memory but fails to free it, the monitoring tool simply reports a slow, steady increase in overall RAM consumption.
The monitoring tool has no visibility into how or why the application is consuming memory. It cannot tell the administrator which specific internal function called the memory allocation routine. To find the root cause, you must look inside the kernel.
Understanding eBPF and Netdata Integration
eBPF allows safe, sandboxed programs to run directly within the Linux kernel. Netdata is an incredibly lightweight, highly granular, real-time performance monitoring agent. When combined, the Netdata eBPF plugin attaches microscopic “probes” to the Linux kernel’s core memory allocation functions, specifically malloc() and free().
Every single time any application on the Ubuntu server requests a block of memory from the kernel, the eBPF probe intercepts the request, records the exact process ID, the amount of memory requested, and whether that memory was subsequently freed. If malloc() is called repeatedly without a corresponding free(), Netdata immediately flags the behaviour as a memory leak.
Enabling the eBPF Plugin in Netdata
Assuming you already have the standard Netdata agent installed on your Ubuntu server, you must explicitly configure it to utilize the eBPF collector, as it requires elevated kernel privileges.
First, ensure your Ubuntu kernel includes the necessary eBPF headers. Most modern Ubuntu LTS releases (20.04 and newer) support this natively, but you should verify your kernel headers are installed:
sudo apt update
sudo apt install linux-headers-$(uname -r)Next, navigate to the Netdata configuration directory and utilize the built-in configuration editor to modify the eBPF plugin settings. Never edit the raw configuration files directly, as Netdata manages them dynamically.
cd /etc/netdata
sudo ./edit-config ebpf.d.confWithin the configuration file, locate the [global] section and ensure the plugin is enabled. More importantly, scroll to the [ebpf programs] section and ensure that memory is set to yes. This specifically instructs the eBPF compiler to attach probes to the memory allocation subsystems.
[ebpf programs]
memory = yes
process = yes
network = noAnalysing Real-Time Allocation Charts
After saving the configuration, restart the Netdata service to inject the eBPF programs into the kernel.
sudo systemctl restart netdataOpen the Netdata web dashboard (typically located at http://your-server-ip:19999). On the right-hand navigation menu, a new section labelled eBPF will appear. Click on Memory.
The dashboard will now display real-time charts breaking down exactly how many times malloc() and free() are being called per second, segmented by individual application processes. If you suspect a memory leak in an application (for example, a Node.js backend), you will see the malloc metric for the node process consistently spiking high, while the corresponding free metric remains flat or significantly lower.
Because the eBPF plugin collects this data at the kernel level with microsecond precision, it removes all guesswork. You can definitively prove to the development team that their specific application is requesting memory from the Ubuntu kernel and failing to release it, rather than blaming the issue on general operating system overhead.