You set up auditd because compliance demands it or because you are tired of debugging mysterious file access patterns. Two days later, your root partition is pinned at 100 percent, and the system is sluggish because auditd is frantically logging every single syscall in your active directory tree. I have seen this happen on more than one production database server, and it is a quick way to tank performance.

Focusing the audit firehose

The default audit rules are often far too broad, casting a wide net that catches everything from legitimate config changes to repetitive background tasks. Instead of watching every file, we should target the specific syscalls that reveal configuration shifts or unauthorized binary execution. If you keep seeing the logs churn on read operations, you have probably added a watch rule that is way too noisy.

auditctl -w /etc/shadow -p wa -k identity_change

• Avoid watches on high-traffic directories like var log or tmp
• Use key names that you can actually grep for later
• Prefer syscall filtering over file watches for process behavior
• Set an immutable flag in audit.rules to keep developers from turning it off during a troubleshooting session

Why your buffer is failing you

When the kernel produces events faster than the auditd daemon can write them to disk, the audit backlog fills up. Depending on your configuration, the kernel might just drop events or even panic the entire system to prevent unauthorized access during a blind spot. Check the backlog limit in your configuration and tune it based on your actual disk I/O throughput rather than just bumping it until the errors go away.

If you are still hitting bottlenecks, take a look at the rate limiting settings in the audit config. It is better to have a slightly throttled audit trail than to have a locked-up server that refuses to log anything at all because the buffer is overflowed.