auditd 不具备内核崩溃自愈能力，仅负责审计日志收集与写入；崩溃发生时它已停止运行，但可通过配置 space_left_action 等为 SUSPEND、flush=DATA、隔离日志存储路径等措施，防止其成为崩溃诱因并保障关键事件可追溯。
防止 auditd 成为崩溃导火索
默认配置中若将 disk_full_action = HALT 或 admin_space_left_action = HALT，auditd 会在磁盘耗尽时直接调用系统关机——这看起来像“主动防护”，实则是把可用性让渡给审计完整性，极易被误判为“无缘无故关机”。尤其在 ECS 等云环境中，/var/log/audit/ 所在分区空间有限，风险更高。
- 务必把 space_left_action、admin_space_left_action、disk_full_action 全部设为 SUSPEND（暂停日志写入）而非 HALT 或 SINGLE
- 设置保守阈值：例如 space_left = 500M（非百分比，防小分区误触发）、admin_space_left = 100M
- 确认 max_log_file_action = ROTATE，并配 num_logs = 10，避免日志堆积失控
保障崩溃前最后关键事件可追溯
内核崩溃往往发生在高负载、异常操作或驱动异常之后。若 auditd 在崩溃前已因 flush 策略太松散而丢日志，就丧失了定位根因的线索。
- 将 flush = DATA 或 SYNC（非默认 INCREMENTAL），强制每次写入都落盘；代价是轻微 I/O 增加，但对 crash 分析至关重要
- 搭配 freq = 20（若用 INCREMENTAL），平衡性能与可靠性
- 确保规则中包含关键触发点：如 -a always,exit -F arch=b64 -S execve（记录所有程序执行）、-w /etc/shadow -p wa -k auth_change（密码文件变更）
与系统级崩溃捕获机制协同工作
auditd 不处理崩溃，但 kdump、crashkernel、dmesg 日志才是分析内核态问题的核心。auditd 需和它们“错峰协作”，而非争抢资源。
- 审计日志路径 log_file = /var/log/audit/audit.log 应避开 /var/crash/ 或 /var/log/kdump/ 所在分区，防止 crash dump 写入失败时连带挤占 audit 空间
- 禁用 auditd 对 /proc/kcore 或设备节点（如 /dev/mem）的监控规则——这类访问常伴随内核异常，盲目审计反而加重负担
- 崩溃后第一时间检查 dmesg -T | tail -50 和 journalctl -b -1 | grep -i "audit\|panic\|oops"，交叉验证是 auditd 主动 halt 还是内核自身挂起
