先把当时的情况摆出来。一台等保整改过的 CentOS 7，根分区四十 G 忽然满，du 定位到 /var/log/audit/audit.log 有十八 G，systemctl status auditd 显示一直在跑。
排查方向其实有限，先把可能性排一排。安全基线加了 watch 全部命令执行的规则，每条命令都产生一条审计记录。另一种情况是auditd 默认不做轮转，只有 logrotate 里配了才会切。
另外，audit 规则里有 -w / -p wa 监控了整个 /etc，配置文件一多日志量暴涨。少数情况下是logrotate 的 postrotate 没通知 auditd 重新打开文件，切了也还写老文件。
先确认日志体量和增长来源
du -sh /var/log/audit && aureport --summary -i | head再往下看当前生效的规则条数与类型
auditctl -l | wc -l && auditctl -l | head -20给审计日志加轮转与上限
printf '/var/log/audit/audit.log {\n daily\n rotate 7\n maxsize 500M\n compress\n postrotate\n /sbin/service auditd reload > /dev/null 2>&1\n endscript\n}\n' > /etc/logrotate.d/auditd压缩历史日志并立即腾出空间
gzip /var/log/audit/audit.log.1 && logrotate -f /etc/logrotate.d/auditd恢复的判定其实很直接。du -sh 显示审计目录回到 2G 以内，df 根分区使用率降到八成以下，auditctl -l 的规则条数与基线要求一致且日志按天生成新文件。
容易忽略的是，审计日志不能一删了事，等保场景要求留存半年，先确认合规期限再压缩；删规则也要走变更，别为了省空间把关键审计关掉。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。