auditd 日志文件过大导致磁盘满的 auditd.conf rotate 配置模板

auditd日志轮转不生效的直接原因是rotate_logs=no未启用或max_log_file/num_logs配置不当；需显式设置rotate_logs=yes、max_log_file（MB）、num_logs，并重启服务验证。

auditd 日志轮转不生效的常见原因

直接原因是 auditd.conf 中轮转配置未启用或参数冲突。默认安装后，max_log_file 和 num_logs 通常为 0 或未设置，导致日志无限追加；同时 rotate_logs 默认是 no，即使其他参数正确，轮转也不会触发。

• rotate_logs = yes 必须显式开启，否则所有轮转参数被忽略
• max_log_file 单位是 MB，设为 100 表示单个日志文件最大 100MB，超过即触发轮转
• num_logs 控制保留几个历史文件（含当前），设为 6 表示最多保留 audit.log + audit.log.1 ~ audit.log.5
• flush 推荐设为 incremental，避免高负载下日志丢失；freq 可配合设为 20（每 20 条刷一次磁盘）

生产可用的 auditd.conf 轮转模板（直接覆盖）

以下配置适用于中等流量系统（每日审计事件数 ≤ 50 万），兼顾磁盘占用与追溯能力。修改后需重启服务：systemctl restart auditd。

log_file = /var/log/audit/audit.log log_group = audit log_file_mode = 0640 max_log_file = 100 max_log_file_action = rotate space_left = 75 space_left_action = email action_mail_acct = root admin_space_left = 50 admin_space_left_action = halt disk_full_action = halt disk_error_action = syslog rotate_logs = yes num_logs = 6 flush = incremental freq = 20

注意：space_left 和 admin_space_left 是磁盘剩余空间百分比阈值（非 audit 日志自身大小），用于主动预警或保护系统；disk_full_action = halt 在磁盘真正写满前强制停 auditd，防止系统级故障。

验证轮转是否真正工作

光改配置不等于生效。必须确认三点：

• 运行 auditctl -s | grep "enabled"，输出应为 enabled 1，表示 auditd 正在运行
• 检查 ls -lt /var/log/audit/，正常应看到 audit.log 最新，且有 .1～.5 编号文件（数量 ≤ num_logs - 1）
• 手动触发一次轮转：auditctl -r，然后立刻检查文件时间戳和大小变化；若无反应，看 journalctl -u auditd -n 20 是否报 "rotation disabled" 类错误

容易被忽略的磁盘压力点

audit 日志膨胀往往不是单一配置问题，而是多个环节叠加：

• 如果启用了 auditctl -a always,exit -F arch=b64 -S execve 这类高频规则，max_log_file = 100 可能撑不过几小时——先用 ausearch -m avc -ts recent | head -20 看实际事件密度，再调参
• /var/log/audit/ 所在分区若和 / 合并，audit 日志打满会直接卡死 ssh、systemd-journald 等关键服务
• 某些云主机镜像自带 logrotate 对 audit.log 的接管脚本，和 auditd 原生轮转冲突，需检查 /etc/logrotate.d/audit 是否存在并禁用

auditd 轮转逻辑是「写满才切」，没有按时间切分的能力；如果需要按天归档或对接 SIEM，得在外部用 inotifywait 监听 audit.log 文件重命名事件，再做搬运或压缩。