Estimate auditd log growth rate and storage needs based on audit rule verbosity.
auditd's audit.log grows in direct proportion to the rate of audited events and each event's serialized size — a busy system with broad audit rules (file watches, syscall auditing, SELinux/AppArmor denials) can generate a meaningful sustained event rate. Daily growth is events/sec × average bytes per event × seconds/day; comparing that to auditd's `max_log_file` and `num_logs` settings (or `max_log_file_action = ROTATE`) shows how many rotated files are needed to cover a compliance-driven retention period (e.g. PCI-DSS commonly requires 90 days readily available, one year total).
Daily growth
growth_per_day = events_per_sec × avg_event_size_bytes × 86400
`ausearch --input-logs -ts today | wc -l` gives today's event count so far, or watch live throughput with `auditctl -s` for kernel-level backlog/rate statistics while tailing `/var/log/audit/audit.log` growth with `du -sh`.
Behavior depends on `admin_space_left_action` and `disk_full_action` in auditd.conf — options range from rotating/ignoring to (in high-security configurations) halting the system entirely (`disk_full_action = halt`) to guarantee no auditable events go unrecorded, so undersizing retention capacity can cause an unexpected system halt.
Narrow audit rules with `-a always,exit -F arch=... -S <specific syscalls> -F key=...` and exclude high-frequency, low-value paths (e.g. use `-a exclude` for noisy syscalls) rather than blanket `-a always,exit -S all`, and route logs to a remote SIEM via `audisp-remote` so local retention can be shorter.