审计对性能的影响
开启详细审计规则之后，系统态 CPU 与磁盘 IO 都会上升，尤其是对大目录做递归监控或用写规则覆盖全路径时，开销会被明显放大。等保与合规要求审计留存，但审计范围必须按关键对象收敛，否则性能代价与磁盘消耗都会失控。评估与精简规则是运维的基本功。
基本信息
| 用途 | 评估并收敛审计规则带来的性能影响 |
|---|---|
| 常用命令 | auditctl -l 列出规则、auditctl -s 查看状态、ausearch 检索记录 |
| 日志位置 | /var/log/audit/audit.log |
| 关注指标 | 系统态 CPU、日志写入速率与磁盘占用 |
典型使用场景
- 上线审计规则后系统态 CPU 明显上升，定位是哪些规则导致
- 审计日志暴涨吃满磁盘，需要收敛范围并补上轮转
- 合规检查要求留存，需在覆盖面与开销之间平衡
- 确认某类关键操作是否被完整记录
- 评估关键目录监控对业务的实际影响
- 精简冗余规则并回头验证效果
常用示例
常用示例
systemctl status auditd --no-pager | head # 确认审计服务状态
sudo auditctl -l | wc -l # 统计当前规则条数
sudo auditctl -s | head # 查看状态与丢失计数
ls -l /var/log/audit/audit.log # 观察日志大小增长
tail -n 5 /var/log/audit/audit.log # 查看最新记录
sudo ausearch -ts today -k 关键字 | tail -n 20 # 按关键字检索记录常见开销来源
| 做法 | 开销 | 建议 |
|---|---|---|
| 对大目录递归监控 | 系统态 CPU 与 IO 明显上升 | 改为具体文件或关键路径 |
| 监听可执行文件执行 | 高频调用场景开销大 | 限定必要目录范围 |
| 全路径写入监控 | 日志量巨大 | 按业务关键对象收敛 |
| 未配轮转规则 | 磁盘被审计日志吃满 | 配置轮转与保留策略 |
| 丢失计数增长 | 记录不完整，影响合规 | 降低规则密度或提高缓冲 |
审计日志暴涨同样会吃满磁盘：轮转与保留策略必须与规则一起配置，否则审计本身就会变成故障源。
对大目录做递归监控是典型的自伤操作：系统态 CPU 与磁盘 IO 一起抬升，业务受影响却很难第一时间联想到审计规则。
定位可疑规则时，可以先把某一组规则单独禁用并观察系统态占用是否回落，用对比方式缩小范围，比逐条猜测可靠得多。