auditd日志增长过快需三重治理：设rate_limit限速（如50）、调max_log_file（如20MB）和num_logs（如6）控制轮转、精简auditctl规则（如过滤root、禁用/proc监控）。
auditd 日志增长过快的典型表现
磁盘空间在几小时内被 /var/log/audit/audit.log 占满，df -h 显示 /var 分区使用率飙升，journalctl -u auditd 可能报 disk full 或 write failed 错误。这不是日志轮转没配，而是审计事件本身太密集（比如大量 execve、openat 调用），轮转前日志已撑爆磁盘。
rate_limit 是最直接的抑制手段
rate_limit 控制每秒允许写入 audit.log 的事件条数，超限后事件被丢弃（不记录），但 auditd 不会崩溃。它比单纯调大轮转频率更治本——因为源头减量了。
- 编辑
/etc/audit/auditd.conf，找到并修改：rate_limit = 50（默认为 0，即不限速） - 值设多少取决于业务：普通服务器 20–100 足够；高频容器宿主机可设 200，但需配合
backlog_limit - 注意：
rate_limit对 priority=high 的事件（如 syscall 审计失败）无效，这类仍会强制记录 - 修改后必须重启服务：
systemctl restart auditd，仅 reload 不生效
log_file 和 max_log_file 配合轮转防爆盘
单个日志文件不能任其无限增长，max_log_file 是硬性截断阈值，单位是 MB，不是字节。它和 num_logs 共同决定本地留存策略。
-
log_file = /var/log/audit/audit.log（保持默认即可） -
max_log_file = 20（建议 10–50 MB，避免单文件过大影响 grep 和 logrotate 处理） -
num_logs = 6（保留最多 6 个归档，配合rotate_method = keep_logs） - 禁用
rotate_method = syslog，它依赖 rsyslog，反而增加延迟和不可控性 - 不要依赖系统 logrotate 管理 audit.log：auditd 自带轮转逻辑，外部轮转可能造成文件句柄错乱
auditctl 规则粒度控制才是长期解法
rate_limit 和轮转只是兜底，真正减少日志量要从规则源头下手。盲目启用所有 syscall 审计（如 -a always,exit -F arch=b64 -S all）必然爆炸。
- 优先用
-F uid!=0过滤掉 root 行为（若只需监控普通用户） - 用
-F path=/tmp替代宽泛的-F dir=/，避免递归抓取整个文件系统 - 禁用低价值事件：
auditctl -e 2 && auditctl -d -w /proc -p wa（移除对 /proc 的写监控） - 检查冗余规则：
auditctl -l | wc -l超过 200 条就该梳理了；用ausearch -m avc -i确认 SELinux AVC 是否在刷屏，必要时调整策略而非记日志
真正难的是平衡安全需求与运维成本——一条漏掉的规则可能埋下隐患，一百条过度规则会让日志失去可读性。配置没有银弹，得结合 ausearch -i -ts recent 实际查几天的事件分布再动手删减。
