auditd规则过多会显著拖慢系统，需通过CPU占比、队列积压、磁盘写压三步快速定位瓶颈，优先审查递归监控、模糊execve、缺失arch过滤等低效规则，并用基准测试量化影响，精简时应聚焦关键路径、加arch和uid过滤、提升backlog并关闭冗余输出。
Audit 规则过多会显著拖慢系统，尤其在高频文件访问、进程创建或网络连接场景下。问题往往不表现为 CPU 持续 100%，而是 延迟升高、I/O 写入突增、auditd 队列积压、甚至 audispd 进程 CPU 占用异常。排查不能只看“有没有规则”，而要验证“每条规则是否在真实产生开销”。
先确认 auditd 是否真成瓶颈
别一上来就删规则。先用三步快速判断：
- 查 auditd 和 audispd 实际 CPU 占比：top -b -n 30 -d 1 | grep -E "(auditd|audispd)" | awk '{sum += $9} END {print sum/30}' —— 若平均 > 3%，需深入
- 看日志队列是否常满：sudo cat /proc/sys/kernel/audit_backlog_limit（默认 64），再执行 sudo cat /proc/sys/kernel/audit_backlog_wait_time；若后者非 0，说明事件在排队等待处理
- 检查磁盘写压力是否来自 audit：iotop -o -b -n 20 -d 1 | grep audit，观察 write B/s 是否持续高于其他日志服务（如 rsyslog）
定位低效规则的典型模式
以下几类规则最易引发性能问题，应优先审查配置文件（/etc/audit/rules.d/*.rules）或运行时规则（sudo auditctl -l）：
- 递归监控宽路径：如 -w /var/log/ -p rwxa —— 会监听整个目录树，/var/log/messages、/var/log/secure 等高频写入文件反复触发，极易打满队列
- 模糊路径 + execve 组合：如 -a always,exit -F path=/bin/ -S execve —— 所有 /bin 下命令启动都会捕获，远不如精确指定 /usr/bin/sudo 或 /bin/bash 高效
- 缺失 arch 过滤的系统调用规则：如 -a always,exit -S connect —— 同时匹配 32 位和 64 位调用，实际业务可能只跑一种架构，白白多一半事件
- 未加 key 标签的通用规则：如监控所有 openat 但没加 -k net_access，导致后续无法用 ausearch 快速过滤，只能全量扫描日志，间接加重 I/O 和分析负担
用基准测试量化每条规则的影响
清空规则后逐组启用，用统一负载测变化：
- 先重置：sudo auditctl -e 0 && sudo auditctl -D && sudo systemctl restart auditd
- 模拟稳定压力：stress-ng --io 2 --timeout 30s 或批量触发目标路径：for i in {1..500}; do ls /etc/passwd > /dev/null; done
- 启用待测规则组后，对比三项指标变化：
• CPU：top 中 audispd 平均占比
• 内存：smem -P audispd -c "pss" 的增量（超 8MB 就算明显）
• 延迟：time for i in {1..100}; do stat /etc/shadow > /dev/null; done 的平均耗时（增幅 > 10% 需优化）
精简与加固并行的操作建议
优化不是简单删规则，而是用更少规则覆盖关键行为：
- 把 -w /etc/ -p wa 拆成只监核心文件：-w /etc/passwd -p wa -k identity、-w /etc/shadow -p wa -k shadow_mod
- 对 execve 监控，加 -F arch=b64（x86_64 系统）和 -F uid!=0（排除 root 自身操作干扰）
- 提高 backlog 容量防丢事件：echo 256 | sudo tee /proc/sys/kernel/audit_backlog_limit（重启 auditd 后生效）
- 关闭非必要审计通道：确认 /etc/audisp/plugins.d/syslog.conf 中 enable = no，避免 audit 事件双写 syslog 加重 I/O
