Most of us treat auditd as a set-it-and-forget-it tool until the day the partition hits 100 percent usage and the kernel decides to stop logging anything at all. It is easy to point auditd at every syscall you can think of, but that is a fast track to killing your disk I/O and losing the very logs you set out to capture. I have seen production hosts go read-only because a junior dev enabled execve monitoring on a chatty application server.

Finding the culprit rule

Before you start deleting rules, you need to see what is filling the buffers. You might think the rules you added during a frantic security audit last year are still useful, but if they are generating thousands of events per second on a routine background task, they are actually just a liability. Use the auditctl status command to check your current backlog and drop counts before you touch the config file.

auditctl -s

• Filter out noise from high-frequency system users like nagios or web-data
• Use -F arch=b64 to avoid capturing both 32-bit and 64-bit calls on 64-bit systems
• Group related file watches into single rules rather than individual paths

If you are struggling with auditd filling up, stop watching every single open call. Instead, focus on specific sensitive directories using a path-based watch and filter by user ID. This bit me back when I tried to log all file modifications on a busy /var/tmp folder. It crashed the audit daemon within minutes. Restricting by UID or GID at the rule level is the only way to keep the kernel from choking on your own monitoring overhead.

The next time your log collector starts complaining about lag, check the backlog limit in /etc/audit/audit.rules before blaming the network. If the kernel buffer is smaller than the burst of activity, you lose data. Tuning the backlog to something like 8192 or 16384 on a busy node is usually a smart move, but keep an eye on how much memory that reserves under high load.