Audit Log Growth Calculator
Estimate auditd log growth per day from event rate and average event size.
Inputs
Used to estimate number of rotated files
Log Growth per Day
103 MB
Total Storage for Retention Period
9.05 GB
Growth per Day (MB)
103.00
Total Storage (GB)
9.05
Rotated Log Files Needed for Retention
186
Step by step
Values used
Audit Events per Second = 5; Average Event Size (bytes) = 250; Retention Period (days) = 90; auditd max_log_file (MB) = 50
Daily growth
growth_per_day = events_per_sec × avg_event_size_bytes × 86400
Log Growth per Day
= 103 MB
Total Storage for Retention Period
= 9.05 GB
Growth per Day (MB)
= 103.00
Total Storage (GB)
= 9.05
Rotated Log Files Needed for Retention
= 186
How it works
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).
Formula
Daily growth
growth_per_day = events_per_sec × avg_event_size_bytes × 86400
- e
- events per second
- s
- average event size (bytes)
Frequently Asked Questions
How do I check the current audit event rate on a live system?
`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`.
What happens when auditd's log storage fills up?
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.
How can I reduce audit log growth without losing important events?
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.