auditLog 路径不应落在 dbPath 下，须独立配置；必须设置 filter 白名单关键事件；logRotate 对其无效，需用 logrotate 等外部工具管理；JSON 格式需正确解析与清理。
auditLog 写入路径是否落在了 dbPath 下？
审计日志默认不进 dbPath，但如果配置时误把 path 指向了 /var/lib/mongodb/（即和数据文件同盘），日志暴增就会直接挤占数据库可用空间。检查你的 mongod.conf 中的 auditLog.destination: file 对应的 path 值，确认它是否独立于 storage.dbPath。常见错误是写成 /var/lib/mongodb/audit.log 而不是 /var/log/mongodb/audit.log。
auditLog 的 format 和 verbosity 是否失控？
MongoDB 审计日志默认记录所有权限相关操作（如 auth、createUser），但若启用了 filter 或未限制事件类型，它可能记录每条 find、update 甚至心跳请求——尤其在高并发应用下，单日轻松生成数十 GB 日志。你必须显式配置 auditLog.filter 来白名单关键事件，例如：
{ "users": [{ "user": "", "db": "" }], "atype": { "$in": ["authCheck", "createUser", "dropUser", "updateRole"] } }
不设 filter 等价于全量抓包，不是“开启审计”，而是“开启磁盘炸弹”。
logRotate 是否对 auditLog 生效？
db.runCommand({logRotate: 1}) 只轮转 MongoDB 自身的 systemLog（即 mongod.log），对 auditLog 完全无效。auditLog 是纯文件追加写入，无内置轮转机制。你必须靠外部工具管理，例如：
- 用
logrotate配置/var/log/mongodb/audit.log，启用rotate 7+size 100M+compress - 确保
postrotate脚本中执行kill -SIGUSR1 $(cat /var/run/mongodb/mongod.pid)（仅限支持该信号的版本）或重启 mongod - 绝对不要依赖 MongoDB 自动切分 auditLog 文件
JSON 格式日志是否被误当二进制处理？
auditLog 默认 format: JSON，每条记录是换行分隔的 JSON 对象（NDJSON）。如果下游解析工具或备份脚本把它当成普通文本反复读取、缓存、复制，可能引发临时文件堆积或重复归档。验证方式：用 head -n 3 /var/log/mongodb/audit.log 看是否为合法 JSON 行；再用 du -sh /var/log/mongodb/audit.log* 查看是否有未压缩的旧轮转文件残留。JSON 本身不比文本更占空间，但缺乏清理策略时，它的可读性反而让人忽略其体积膨胀速度。
真正卡住磁盘的，往往不是 auditLog 本身，而是它和系统日志、oplog、journal、WiredTiger 缓存旧版本一起形成的“空间耦合”——某个环节没切掉，其他环节就永远无法释放。别只盯着 auditLog 配置，先确认它有没有和数据库共用磁盘、有没有被外部流程二次放大、有没有被遗忘在 logrotate 之外。
