mongodb副本集需显式启用auditlog并设auditauthorizationsuccess: true才能记录dml操作；仅主节点记录ddl/dml日志，从节点不记录dml且5.0+起不记录ddl；auditfilter可精确过滤事件类型。
MongoDB副本集默认不开启审计（audit），要监控所有DDL与DML操作，必须显式启用 auditLog 并配置筛选器；但注意：从 MongoDB 5.0 起，从节点不再记录 DDL 审核事件（仅主节点记录），且对 local 和 system.profile 的 DDL 操作仍会记录。
auditLog 配置必须在主节点 mongod.conf 中设置
审计功能只在 mongod 进程启动时加载生效，无法运行时动态开启。配置项必须写入每个副本集成员的配置文件（如 /etc/mongod.conf），但只有主节点实际产生 DDL/DML 审计日志（从节点仅记录部分系统事件）。
-
auditLog是顶层配置块，不能放在security或systemLog下 - 必须指定
destination（支持file或syslog），format推荐用JSON（便于后续解析） - 若写入文件，确保
path目录存在、mongod 用户有写权限，否则启动失败并报错Failed to open audit log file - 示例片段：
auditLog: destination: file format: JSON path: /var/log/mongodb/audit.log
auditAuthorizationSuccess 必须设为 true 才能捕获 DML 操作
默认情况下，MongoDB 审计只记录身份验证、授权失败、DDL 等高危事件，DML（insert/update/delete/find）操作不会被记录，除非显式启用授权成功事件审计。这是最容易遗漏的关键点。
- 在配置文件中添加：
auditAuthorizationSuccess: true（注意是顶层字段，非嵌套在security内） - 该设置会使每次通过权限校验的读写操作都生成一条审计日志，日志量激增，需评估磁盘和 I/O 压力
- 若只关心变更类操作（非查询），可配合审计筛选器进一步缩小范围，但
find默认也会被记录 - 重启
mongod后，可用db.runCommand({getAuditLog: 1})验证是否生效（返回非空表示已启用）
使用 auditFilter 精确控制 DDL/DML 事件类型
盲目开启全部审计会导致日志爆炸，尤其在高频写入场景。应通过 auditFilter 限定只捕获真正关心的操作，比如只监控集合创建、索引变更和文档级修改。
-
auditFilter是 JSON 字符串，需转义后填入配置文件的auditLog.filter字段 - 常见有效过滤表达式：
-
{"atype": "createCollection"}—— 仅捕获新建集合 -
{"atype": {"$in": ["insert", "update", "delete"]}}—— 仅捕获增删改 -
{"atype": {"$regex": "^ddl$|^dml$"}, "param.ns": {"$not": {"$regex": "^admin\."}}}—— 排除 admin 库的 DDL/DML - 注意：正则匹配
ns（命名空间）时，test.users格式不含引号，不要写成"test\.users"
副本集下审计日志不自动同步，需单独收集与分析
审计日志是本地文件或系统日志，不会通过 Oplog 复制，也不会出现在任何集合中。这意味着每个节点的日志必须独立采集，主节点宕机切换后，新主节点的日志路径和内容是全新的。
- 不要依赖
rs.syncFrom()或复制机制获取审计数据 - 生产环境建议用 Filebeat + Logstash 或直接对接 SIEM 工具，按节点 IP + 主从角色打标
- 若用
syslog输出，需确保 syslog 服务本身高可用，否则日志丢失无回溯 - 审计日志中的
localTime是 UTC 时间，且不同节点时钟偏差会影响事件排序，务必启用 NTP 同步
最常被忽略的是 auditAuthorizationSuccess: true 这个开关——没它，insert 和 update 永远不会进审计日志；其次是误以为从节点也会记录 DML，实际上它连主节点的 DDL 日志都不全。配置完务必用 db.runCommand({getAuditLog: 1, limit: 1}) 实测，别只看进程是否启动成功。
