mongodb 6.0 副本集审计日志仅企业版支持，社区版无该功能；各节点须独立配置auditlog，云托管实例需通过控制台或api开通，filter为严格json字符串，路径须本地可写且不可共享。
MongoDB 6.0 副本集开启审计日志，前提是必须使用 Enterprise Edition；Community 版本无论怎么配 auditLog 都不会生效——它压根没编译进二进制。
确认你用的是 MongoDB Enterprise Edition
社区版和企业版在审计功能上是硬性割裂的，不是配置问题，是代码缺失。验证方法只有两个：
- 执行
mongod --version，输出中必须含enterprise字样（如db version v6.0.20-ent） - 连接到任意节点后运行
db.runCommand({getCmdLineOpts: 1})，返回结果里要有auditLog字段；社区版即使配置了也会被完全忽略，不报错也不加载
如果你用的是阿里云/腾讯云托管的 MongoDB 实例，直接看控制台实例详情页的版本标识——“企业版”字样必须明确出现，不能只写“6.0”。ECS 自装企业版但连的是云数据库地址，本地 mongod.conf 配置无效。
副本集各节点必须独立配置 auditLog
副本集不是主节点配了就全生效。每个 mongod 进程（包括 primary、secondary、arbiter）都需单独启用审计，否则未配置的节点不会记录自身发生的操作（比如 secondary 上执行的 rs.stepDown() 就可能漏掉）。
-
auditLog.path必须指向该节点本地可写的路径，例如/data/mongodb/audit/audit.json，不能共用 NFS 或共享盘（并发写会损坏 JSON 格式） -
auditLog.format推荐用JSON（非json），大小写敏感；BSON虽然性能略好，但调试时无法直接cat查看 -
auditLog.filter是字符串，不是对象：必须用单引号包裹整个值，内部双引号不可省，例如'{ "atype": { "$in": ["authCheck", "insert", "update"] } }'
最小可用配置示例（写入各节点的 /etc/mongod.conf）：
auditLog:
destination: file
path: /data/mongodb/audit/audit.json
format: JSON
filter: '{ "atype": { "$ne": "authenticate" } }'
云环境（如阿里云）不认本地 mongod.conf 的 auditLog 配置
你在阿里云控制台看到的 MongoDB 实例，其底层 mongod 进程由云平台统一管控，你上传或修改的 /etc/mongod.conf 完全无效。审计开关只能通过：
- 控制台路径：「云数据库 MongoDB 版」→ 实例详情页 → 「正式版审计日志」→ 「开通审计日志」
- API 调用：使用 DAS OpenAPI 的
EnableAuditRule，传入的filter是标准 JSON 字符串，不是 YAML 语法
注意：开通前需确保已开通 SLS 日志服务，并为 RAM 用户授予 AliyunLogFullAccess 和自定义策略 dds:CheckServiceLinkedRole。云平台的 filter 设置走图形化构建器，不暴露原始 JSON，避免手写格式错误。
auditLog.filter 写错会导致 mongod 启动失败且无明确提示
filter 语法看似像 MongoDB 查询，实则是严格校验的 JSON 字符串。常见挂起点：
- 漏写外层单引号：
filter: { "atype": "insert" }→ 启动报错Failed to parse audit filter - 内部键名用了单引号：
'{ 'atype': 'insert' }'→ JSON 解析失败 - 误用 JS 简写：
"$in": ["insert"]写成"$in": "insert"→ 过滤失效，但进程仍能启动 - 事件类型拼错：
"authCheck"写成"authcheck"或"auth"→ 对应事件永不记录
推荐先用最宽泛的 filter 测试：'{ "atype": { "$exists": true } }'，确认日志生成后再逐步收紧。生产环境务必排除 authenticate，否则日志量爆炸（每秒数百条）。
真正容易被忽略的是：副本集多数节点可能长期静默，但一旦发生故障切换，新 primary 的审计日志是否连续、是否包含接管前的操作痕迹，全取决于它自己有没有配对的 auditLog。别只盯着主节点。
