审计功能需显式配置--auditFilter才能记录delete/update操作，推荐BSON日志格式以保留类型信息，审计日志仅记录操作元数据（如params.q查询条件），不存文档快照，变更流不可替代审计日志。
审计功能能记录 delete / update 操作，但默认不开启，且 auditFilter 必须显式包含 delete 和 update 类型，否则日志里根本不会出现这些事件。
启动时必须加 --auditFilter 才能捕获删改行为
只配 --auditDestination 和 --auditPath 不够，MongoDB 会默认只记极少数系统事件。删改类操作必须靠 --auditFilter 显式放行：
-
--auditFilter '{ atype: { $in: ["delete", "update"] } }'是最简有效写法 - 如果还想要 insert 或 authCheck，就扩展数组：
$in: ["insert", "update", "delete", "authCheck"] - filter 是 BSON 查询表达式，不能用正则或模糊匹配；
atype: "delete"这种精确匹配更稳妥，避免误漏 - filter 中字段名必须小写，
AType或atype_都无效
auditLog.format 选 BSON 还是 JSON？
生产环境强烈建议用 BSON：
-
BSON格式保留完整类型信息（比如ObjectId、ISODate、NumberLong），后续用mongorestore或mongoshell 解析无损 -
JSON会把ObjectId("...")转成字符串、ISODate(...)转成 UTC 字符串，丢失原始语义，查问题时容易误判时间精度或主键结构 - 日志体积上 BSON 略小，写入压力略低 —— 对高频删改场景有实际意义
审计日志里怎么定位具体哪条文档被删/改？
审计日志本身不记录文档内容，只记操作元数据。关键字段包括：
-
atype：值为delete或update -
ns：命名空间，格式如"mydb.orders"，明确到库和集合 -
params.q：删除或更新所用的查询条件（BSON 格式），例如{ "status": "cancelled" } -
params.u：仅 update 有，表示$set、$inc等更新操作符内容 -
remote：客户端 IP 和端口，可追溯操作来源
注意：params.q 是原始查询条件，不是匹配到的文档。想确认删了哪些数据，得拿这个条件去原集合反查 —— 审计日志不存快照。
变更流（change stream）和审计日志别混用
有人想用 db.collection.watch() 替代审计，这是错的：
- 变更流只对开启
changeStreamPreAndPostImages的集合生效，且delete事件里只有 pre-image（删前快照），没操作者、没 IP、没时间戳精度（只有clusterTime） - 审计日志由 mongod 进程内核级记录，绕过所有应用层逻辑，哪怕连接被异常中断、事务回滚、甚至写失败（如权限拒绝），只要进入审计钩子就会留痕
- 二者目的不同：变更流用于业务同步，审计日志用于合规追责 —— 后者必须独立部署、不可被应用代码绕过
真正要“追踪删改行为”，auditLog 是唯一满足审计合规要求的方式；其它方案都缺上下文、易伪造、或覆盖不全。
