Stop Letting auditd Drop Your Security Events Under Load

Technical Briefing | 10/21/2026

Everyone tells you to enable auditd for compliance, so you do. You slap a bunch of rules in place to track execve and file access, and everything is quiet. Until you get hit with a spike in traffic or a noisy cron job that triggers thousands of system calls. Suddenly, your audit logs are missing entries or the system freezes because auditd can’t keep up with the kernel buffer. I have seen this silently kill production performance more times than I care to admit.

The kernel buffer is smaller than you think

By default, the kernel audit backlog buffer is pitifully small. If your application pushes syscalls faster than auditd can pull them from the kernel, you hit the audit_backlog_limit. Depending on your configuration, the system will either stop logging or, worse, just freeze the calling process to prevent the event from escaping audit. That is a guaranteed way to introduce latency spikes that make your developers weep.

auditctl -b 8192

• Check your current backlog status with auditctl -s to see if the lost count is climbing.
• Increase the backlog buffer size in audit.rules to at least 8192 if you are running anything beyond a basic setup.
• Move your audit logs to a dedicated high-speed disk partition to prevent disk I/O contention with your application logs.

Audit rules should be surgeons not butchers

Most admins just copy-paste massive rule sets from a blog post they found five years ago. That is how you end up auditing every single open syscall, which is absolute suicide for performance. If you only care about who touched that specific sensitive config file, scope your rules tightly using path or directory watches. Don’t let your auditing layer turn into a performance bottleneck that forces you to choose between security and uptime.

Keep an eye on the lost count in your dmesg logs. If it is ticking upward, don’t just increase the buffer again. It is a sign that you need to prune your ruleset before you start missing the one incident you actually need to see in those logs.