You set up auditd because compliance told you to, or maybe you actually wanted to see who was deleting files in /etc. But after a week, your IO wait is through the roof and your disk latency is making the server crawl. Most tutorials tell you to enable everything under the sun, but they ignore the fact that the audit dispatcher can easily become a bottleneck that chokes your kernel.

Why your log rules are probably garbage

If you are watching every write to /tmp or tracking every single fork syscall without filtering, you are just burning CPU cycles. The kernel has to process these events before they even hit the log file. You should be filtering out noise at the kernel level. Stop logging things that don’t matter and focus only on the security boundary you are trying to protect.

auditctl -a always,exit -F arch=b64 -S execve -k sensitive_execution
auditctl -d always,exit -F arch=b64 -S execve -k sensitive_execution

• Avoid logging every file read operation by using exclusion filters in audit.rules
• Prioritize process execution logging over path-based rules when possible
• Move your audit logs to a dedicated high-speed partition to isolate IO pressure

Test the impact before you push to the fleet

Before you roll out that new policy, run a quick load test with a tool like stress-ng while watching your audit rates with auditd -s. If the lost events counter starts climbing, you have already pushed the system past its limits. You are better off with fewer, meaningful logs than a million entries of garbage that hide the one actual attack you are trying to detect.

Keep an eye on the audit backlog limit in /etc/audit/auditd.conf. If your applications are jittery, bump the backlog value slightly, but keep in mind that a larger buffer just hides the real performance degradation occurring underneath. If you can’t keep up, simplify the rules.