防止auditd丢日志的关键是协同管控audit_backlog_limit、内核队列与磁盘空间：该参数仅在队列满且磁盘正常时丢弃最老事件，磁盘满则完全失效；推荐设为8192，配合源头规则精简、space_left保护和rotate轮转三重机制。

要防止高并发系统调用下 auditd 丢日志，关键不是单纯调大底层缓冲区，而是理解 audit_backlog_limit 的真实作用边界，并配合内核队列与磁盘空间协同管控。

audit_backlog_limit 的实际作用和常见误区

这个参数控制的是内核审计子系统中用于暂存待处理事件的内存队列大小（单位：条），仅在以下条件下生效：
— 内核审计队列已满
— 磁盘仍可正常写入
此时若新事件持续到达，auditd 会按 audit_backlog_limit 设置丢弃最老事件，避免内存耗尽。

但它完全不适用于磁盘满场景：一旦 /var/log/audit/ 所在分区使用率达 100%，auditd 直接停止落盘，内核队列持续堆积，audit_lost 计数飙升，而 backlog 限流逻辑彻底失效。

所以盲目调高该值（如设为 65536）既不能解决磁盘满问题，还可能加剧内存压力；过小（如默认 64 或手动设为 32）则在高频 syscall 监控（如 -S execve）时导致大量合法事件被丢弃。

稿定AI

一款融合AI图像生成与智能编辑能力的在线设计工具，可辅助完成图片重绘、线稿处理和人物视觉优化等创作任务。

下载

合理设置 audit_backlog_limit 的建议值

生产环境推荐保持默认值或微调至 8192：

• 默认值（通常为 8192）已在稳定性与容量间取得平衡
• 若确认存在短时 syscall 暴增（如批量脚本执行），可临时提升至 16384，但需同步加强磁盘空间监控
• 避免设为 0（禁用限流）——这会导致内核 OOM Killer 可能杀掉 auditd 或其他关键进程
• 设置命令：sudo auditctl -b 8192（临时生效）；持久化需写入 /etc/audit/rules.d/audit.rules 开头，加一行：-e 2 -b 8192

真正防丢日志的三层协同配置

单靠缓冲区无法治本。必须让 auditd 主动管理资源，形成“内核队列 → 用户空间守护 → 磁盘空间”三级响应：

• 第一层：控制日志生成源头
  禁用非必要高频规则，例如移除未过滤的 -S execve，改用白名单：-a always,exit -F arch=b64 -S execve -F path=/bin/bash -k shell_start
• 第二层：保障 auditd 落盘能力
  在 /etc/audit/auditd.conf 中强制启用空间保护：
  space_left = 250M
space_left_action = exec
admin_space_left = 100M
admin_space_left_action = SUSPEND
• 第三层：确保轮转机制可靠
  max_log_file = 100（MB）
  num_logs = 10
max_log_file_action = ROTATE
  修改后运行 sudo augenrules --load && sudo systemctl restart auditd

验证是否还在丢日志

定期检查内核丢弃计数：

• sudo auditctl -s | grep lost —— 查看 audit_lost 值，非零即表示已有事件丢失
• sudo ausearch -m CONFIG_CHANGE -ts today | grep "backlog limit" —— 看是否有因队列满触发的告警
• df -h /var/log/audit 和 sudo auditctl -s | grep backlog 联合判断：若磁盘未满但 audit_lost > 0，说明 backlog 确实溢出；若磁盘已满，则优先清理空间