必须使用auditfilter精确匹配权限变更事件，即配置{ "atype": { "$in": ["createuser", "updateuser", "grantrolestouser", "revokerolesfromuser", "dropallusersfromdatabase"] } }，且仅enterprise版支持，社区版完全无效。
只保留权限变更事件，必须用 auditFilter 精确匹配 atype
MongoDB 审计日志默认记录所有操作，但权限变更只占其中极小一部分。不加过滤器，auditLog 会迅速膨胀，且混入大量无关事件（如普通 find、insert），导致告警失焦或漏报。真正有效的做法是启动时就通过 filter 锁定几个关键 atype 值——这些是 MongoDB 官方文档明确定义的权限操作类型，其他字段（如 ns 或 param）对权限审计无直接意义。
必须在 /etc/mongod.conf 的 security.auditLog 段中配置 filter，内容为合法 JSON：
{ "atype": { "$in": ["createUser", "updateUser", "grantRolesToUser", "revokeRolesFromUser", "dropAllUsersFromDatabase"] } }
-
dropAllUsersFromDatabase极易被忽略，但它代表数据库级清空权限，应保留在列表中 - 别加
"authCheck"——它只表示登录成功，不等于权限变更；单独出现无法判断是否越权 - 不要用
"atype": "all"再靠下游过滤，mongod 不会把未匹配的事件写入磁盘，但 CPU 和 I/O 仍会被无效解析消耗
社区版用户会发现 filter 配置完全不生效
这是最常踩的坑：MongoDB 社区版（Community Edition）根本不支持 auditLog 功能，无论你配置多少 filter，服务启动时都会静默忽略，不报错、不警告、也不生成日志文件。只有 Enterprise 版本才真正实现审计能力。
验证方式很简单，在终端执行：
mongod --version
输出中必须包含 Enterprise 字样。如果看到的是 Community，那所有 auditLog 配置都是徒劳的——此时唯一可行路径是升级到 Enterprise，或改用应用层日志 + change stream（但后者无法捕获 grantRolesToUser 这类管理命令）。
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
- 配置了
auditLog却没生成/var/log/mongodb/audit.log？先检查版本 - systemctl restart mongod 成功但日志目录为空？大概率是社区版在“假装工作”
- 别试图用
db.setLogLevel(1)或修改systemLog.verbosity来替代——它们控制的是常规日志，和审计日志完全无关
filter 中的字段名大小写和前缀不能错
filter 是严格 JSON 解析，字段名大小写敏感，且部分字段必须带 param. 前缀。但权限类事件（如 createUser）的 atype 在顶层，不需要前缀；而像 find 或 update 的命名空间则必须写成 param.ns。混淆这两类会导致整个 filter 失效，mongod 退回到记录全部事件。
正确写法示例（仅权限事件，无需额外字段）：
{ "atype": { "$in": ["grantRolesToUser", "revokeRolesFromUser"] } }
- 写成
"ATYPE"或"Atype"→ 过滤器失效 - 误加
"param.atype"→ 语法错误，mongod 启动失败并报Failed to parse audit filter - 混入
"ns": "admin.system.users"（漏掉param.）→ 该条件永远不匹配，但其余 atype 仍生效（属于“部分失效”，最难排查）
auditLog.path 目录权限不足会导致 mongod 启动失败
即使 filter 写对了、版本也对了，mongod 仍可能启动失败，典型错误是：
Failed to open audit log file: Permission denied
这是因为 auditLog.path 指向的目录（如 /var/log/mongodb/）没有被 mongod 进程用户（通常是 mongodb 用户）赋予写权限。这不是运行时报错，而是服务根本起不来。
- 必须提前执行：
sudo mkdir -p /var/log/mongodb && sudo chown mongodb:mongodb /var/log/mongodb - 路径末尾不能带
.log以外的扩展名，某些旧版驱动对.json后缀处理异常 - 不要用
/tmp作为审计日志路径——很多系统策略会定期清理，且 SELinux 可能阻止写入
权限问题不是“偶尔失败”，而是每次重启都卡住。它和 filter 逻辑无关，但会让人误以为是配置写错了。
