You set up auditd for compliance because an auditor asked for it. Everything runs fine until a developer deploys a leaky app or a background process starts spinning. Suddenly, your disk fills up, the system logs rotate so fast they become useless, and your primary storage is gasping for air. This happened to me on a high-traffic node, and I learned the hard way that audit rules are not a fire-and-forget affair.

Why your rules are eating your disk alive

Most default configs are way too broad. If you have an audit rule that watches every syscall without filtering by PID or user, you are essentially asking the kernel to log every heartbeat of the system. I have seen production boxes drop off the map because the audit daemon couldn’t keep up with the write pressure. You need to narrow the scope before the kernel hits the backlog limit.

auditctl -a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k user_commands

• Exclude your monitoring agents to stop them from logging themselves into an infinite loop
• Set a sensible max_log_file_action to keep the system responsive when space gets tight
• Use -F auid>=1000 to ignore system-level noise and focus on actual human or app user activity

The trap is thinking audit logs are for debugging. They aren’t. They are for reconstruction after a breach. If you are trying to use them to fix a bug, you are doing it wrong. Check your audit.rules file tonight and ensure you aren’t logging every open file call on the entire filesystem; your future self will thank you when the disk alert doesn’t wake you up at 3 AM.