auditd 是 Linux 内核审计子系统的用户态守护进程，负责接收内核审计事件并写入日志。在 Debian 上部署安全审计本来是好事，但不少管理员发现：一旦规则写得不够精细，整个系统的 CPU 占用会明显上升，某些场景下磁盘写入量也会暴涨，甚至连 SSH 登录都变得卡顿。这篇文章就来聊聊为什么几条审计规则会有这么大的杀伤力，以及该怎么排查和优化。
auditd 是怎么拖慢系统的：先理解工作原理
Linux 审计子系统由两部分组成：内核中的审计代码负责在系统调用层面拦截事件，用户态的 auditd 进程通过 netlink 套接字接收这些事件，再写入磁盘日志。性能问题的关键在于，审计规则的匹配发生在内核态，而且是同步阻塞的。每一条被监控的系统调用，内核都要遍历规则链做匹配，命中后还要构造审计记录、序列化、通过 netlink 发送到用户态。
单看一次调用的开销并不大，通常在微秒级别。问题出在触发频率上。比如你监控了 /usr/bin 目录下所有文件的执行事件，那么每一次命令执行、每一个脚本调用、甚至 cron 任务里的每一行 shell 都会产生审计事件。一台跑着 CI 流水线的服务器，每分钟可能产生数万次 execve 调用，审计开销就会叠加成肉眼可见的 CPU 占用。
另一个容易被忽视的瓶颈是磁盘写入。auditd 默认以同步方式写日志，每条记录落盘后才算完成。高事件量场景下，日志文件会在几小时内膨胀到 GB 级别，磁盘 IO 压力随之而来。如果日志分区还和其他业务数据共用磁盘，性能劣化会更加明显。
哪些规则写法最容易出问题
下面这条规则是典型的性能杀手，它监控整个 /etc 目录所有文件的所有类型访问：
auditctl -w /etc/ -p rwa -k etc-access
看起来人畜无害，实际上 /etc 下的文件会被几乎所有服务进程反复读取，resolv.conf、ld.so.cache 这类文件每秒可能被读取几十次。加上 a（attribute）权限监控后，每次 stat 调用都会触发匹配判断，CPU 开销直线上升。
第二个常见误区是递归监听大目录。auditctl 的 -w 参数在监控目录时只作用于该目录本身，很多人以为加上 /etc/ 就能监控所有子文件，实际上要配合 -F path 过滤或者使用 dir 字段，但一旦真的对 /etc 这种包含上千文件的目录做了完整监听，每条规则在内核中会展开成对应的 inode 关联，规则表的匹配成本和内存占用都会显著增加。
第三个坑是系统调用级规则没有加过滤条件，例如：
auditctl -a always,exit -S execve
这条规则会记录系统上所有进程的所有 execve 调用，没有任何 key、没有用户过滤、没有路径限制。在容器环境或者高并发业务机上，日志量会瞬间失控。正确做法是尽量叠加过滤字段，缩小命中范围，后面会给出示例。
如何确认性能下降确实来自 auditd
排查的第一步是看数据。使用 pidstat 或 top 观察 auditd 进程的 CPU 占用：
pidstat -p $(pidof auditd) 1 10
如果 auditd 长期占据较高的 CPU，或者内核态 CPU（top 中的 sy 列）异常偏高，基本可以锁定审计子系统。还可以用 perf 看内核热点，确认时间是否花在 audit_filter_syscall 等审计函数上：
perf top -e cycles:k
第二步是评估事件量。通过 ausearch 统计最近产生的事件数量和分布：
ausearch --start today --format csv | wc -l ausearch --start today -k your-key | wc -l
如果某条规则对应的事件数占了大头，优化目标就很明确了。另外查看 /var/log/audit/audit.log 的增长速度，也能直观感受日志压力：
ls -lh /var/log/audit/audit.log sleep 60 ls -lh /var/log/audit/audit.log
一分钟内日志增长超过几十 MB，说明事件量已经失控。临时验证时可以用 auditctl -e 0 关闭审计（需要 root），观察系统负载是否立刻回落，这是最直接的因果验证手段。注意生产环境关闭审计前要确认合规要求允许这么做。
规则优化：从源头减少审计开销
优化的核心思路是减少事件产生量、缩小规则匹配范围。首先是限定权限类型，只监控真正关心的操作。例如只需要发现配置文件被篡改，那就只监控写操作：
# 只监控写和属性变更，不监控读 auditctl -w /etc/passwd -p wa -k identity-change auditctl -w /etc/shadow -p wa -k identity-change auditctl -w /etc/sudoers -p wa -k sudoers-change
其次是使用字段过滤替代宽泛规则。相比监控整个目录，明确指定文件或使用 -F 过滤特定用户、特定系统调用组合，能让规则在内核中提前短路，减少无效匹配：
# 只记录 root 之外用户尝试执行敏感命令的事件 auditctl -a always,exit -S execve -F dir=/usr/sbin/ -F auid!=0 -F auid!=-1 -k priv-cmd
这里 auid!=-1 用于排除未登录的守护进程，能砍掉大量无意义的事件。类似的技巧还有用 -F success=1 只记录成功的操作，失败的噪声事件往往占了日志的一半以上。
第三是控制规则总量。审计规则在内核中按顺序匹配，规则越多，每次系统调用的遍历成本越高。建议定期用 auditctl -l 审查现有规则，删除失效或重复的条目，把规则数量控制在必要范围内。规则应写入 /etc/audit/rules.d/ 下的文件，通过 augenrules --load 统一加载，避免直接 auditctl 临时添加后丢失或堆积。
调整 auditd 自身的落盘行为
除了精简规则，auditd 的配置也值得调整。编辑 /etc/audit/auditd.conf，重点关注这几个参数：
# 日志刷新策略，incremental_async 异步写入开销更低 flush = incremental_async freq = 50 # 单文件上限与保留份数，按磁盘容量规划 max_log_file = 100 num_logs = 5 # 磁盘满时的动作，SYSLOG 比 HALT 温和 space_left_action = SYSLOG max_log_file_action = ROTATE
flush 从默认的 incremental_async 改动时要谨慎，如果当前配置是 sync，每条记录都强制 fsync，性能损失会非常大，改成异步模式通常能立刻缓解磁盘压力。日志轮转参数则决定了磁盘空间的占用上限，避免审计日志吃满分区拖垮整个系统。
最后要提醒的是，性能和安全审计始终是一对需要平衡的目标。如果你的需求只是检测关键文件变更，也可以考虑用 AIDE 这类基于哈希的完整性校验工具替代部分审计规则，它以定时扫描的方式工作，运行时几乎不占用资源。而对于必须实时监控的场景，坚持最小化原则：只监控必要的路径、必要的权限、必要的用户组，让每一行审计日志都有存在的价值。