磁盘满时auditd配置调整方法

当 auditd 遇到磁盘写满时，关键配置如 `audit_backlog_limit` 和 `rate_limit` 实际完全失效——前者仅在队列满但磁盘可写时起作用，后者只限制用户态写入速率，无法阻止内核持续生成审计事件；真正有效的防护机制是主动的空间管理：必须协同配置 `space_left`（如250MB）、`space_left_action`（推荐执行清理脚本）、`max_log_file` 与 `num_logs` 实现日志轮转，并启用 `max_log_file_action = rotate` 和 `flush = incremental`；同时切勿忽略 `.trash/` 目录的隐性空间占用，且磁盘清空后需手动 `systemctl restart auditd` 才能恢复服务，否则进程可能停滞在 error 状态导致审计中断。

auditd 磁盘满时 audit_backlog_limit 不起作用？

磁盘满时 audit_backlog_limit 实际上完全失效——它只在内核审计队列满、但磁盘尚可写入时触发丢弃行为；一旦 /var/log/audit/audit.log 所在分区使用率达 100%，auditd 会直接停止写日志，此时 backlog 队列持续堆积，最终导致内核丢弃审计事件（audit_lost 计数上升），且不触发任何 backlog 限流逻辑。

实操建议：

• 必须配合 space_left 和 action_mail_acct 使用，提前在磁盘使用率达 75%–85% 时告警并清理
• audit_backlog_limit 建议设为 8192（默认值），过小（如 64）会导致高频事件下大量丢弃，过大（如 65536）可能加剧内存压力且无助于磁盘满问题
• 检查是否启用了 disk_full_action = halt 或 disk_error_action = syslog，这些配置在磁盘满时会改变 auditd 行为，但不会恢复写入能力

为什么调高 rate_limit 无法缓解磁盘满？

rate_limit 控制的是每秒允许写入的审计消息条数（单位：条/秒），它只影响用户空间 auditd 守护进程向磁盘刷日志的速度，不控制内核审计子系统的生成速率。当磁盘已满，auditd 即使收到内核发来的事件，也无法落盘，rate_limit 形同虚设。

常见错误现象：auditctl -s | grep rate 显示 rate_limit = 0（即不限速），但磁盘仍快速打满——这说明问题不在速率限制，而在日志体积本身（例如开启了 -a always,exit -F arch=b64 -S execve 后大量记录命令执行）。

实操建议：

• 先用 ausearch -m avc --start today | wc -l 和 ausearch -m SYSCALL --start today | wc -l 判断日志爆炸来源
• 若非必要，禁用高频 syscall 监控，例如移除 -S execve 或加 -F path=/usr/bin/ 白名单过滤
• rate_limit 仅建议用于临时压制（如设为 10），长期依赖它掩盖日志设计缺陷反而会丢失关键事件

真正能防止磁盘被 auditd 写满的关键配置项

核心不是限速或限队列，而是让 auditd 主动管理磁盘空间。以下三项必须协同设置：

• space_left = 250：当剩余空间 ≤ 250MB 时触发 action（单位 MB，注意不是百分比）
• space_left_action = email 或 exec：推荐设为 exec 并指向一个清理脚本，例如 exec="/usr/local/bin/clean-audit-log.sh"
• max_log_file = 10：单个日志文件上限（单位 MB），配合 num_logs = 5 可实现最多 50MB 循环覆盖，避免无限追加

注意：max_log_file_action = rotate 必须启用，否则即使设了 num_logs，auditd 也不会自动轮转；另外，flush = incremental 比 data 更节省 I/O，适合低配机器。

清理后 auditd 不自动恢复写入？检查 auditctl -s 中的 enabled 和 pid

磁盘满曾导致 auditd 进入 error 状态后退出，即使清空磁盘，进程也不自动拉起——这是 systemd 下的常见表现。此时 auditctl -s 会显示 enabled = 2（即 disabled）或 pid = 0。

实操步骤：

• 运行 systemctl status auditd，确认状态是否为 failed 或 inactive
• 手动重启：systemctl restart auditd，而非仅 auditctl -e 1（后者只对已运行的进程生效）
• 验证恢复：auditctl -s | grep "enabled\|pid" 应显示 enabled = 1 和有效 pid 值
• 补救遗漏：若重启前已有 backlog 积压，内核可能已丢弃部分事件，需结合 ausearch -m CONFIG_CHANGE 查看 audit 规则是否被意外重置

最易忽略的一点：很多运维脚本只清理 /var/log/audit/ 下的旧日志，却忘了 /var/log/audit/.trash/（auditd 1.8+ 默认启用垃圾箱机制），这个目录默认保留 30 天已删除日志，也会占满磁盘。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。