mongodb 5.0 的 auditlog.filter 仅在启用审计（--auditdestination 配置为 file 或 syslog）时生效，支持基于 atype、ns 等字段的 bson 查询过滤，但不支持 authcheck 等特定事件及正则等操作符。
MongoDB 5.0 支持通过 auditLog.filter 配置审计事件的细粒度过滤，但必须注意：该字段仅在启用审计（--auditDestination）的前提下生效，且不支持所有操作类型——比如 auditAuthorizationSuccess 在 5.0 中无法被 filter 拦截，它始终被记录（除非整个审计被关闭）。
auditLog.filter 的语法和生效前提
filter 是一个标准 BSON 查询文档，语义等同于 find() 的查询条件，作用于审计事件日志的结构体。它只在审计已启用时起效，且必须与 auditLog.destination 同时配置。
-
auditLog.destination必须设为file或syslog（console不支持 filter） - filter 文档不能包含正则、$text、$where 等服务器端执行操作符
- 字段名需严格匹配审计事件结构，例如
atype（操作类型）、user、ip、ns（命名空间） - 常见可过滤的
atype值包括：createCollection、dropCollection、insert、update、delete、authCheck
配置示例：只记录敏感集合的写操作
假设你只想审计对 users 和 transactions 集合的 insert、update、delete 操作，其他一概忽略：
auditLog:
destination: file
path: /var/log/mongodb/audit.log
format: JSON
filter:
atype: {$in: ["insert", "update", "delete"]}
ns: {$in: ["myapp.users", "myapp.transactions"]}
注意：ns 字段格式为 <database>.<collection></collection></database>，不含引号；若用命令行启动，需将 filter 写成单行 JSON 并用 --auditFilter 参数传入（如 --auditFilter '{"atype":{"$in":["insert"]}}'），但强烈建议用配置文件避免 shell 转义问题。
容易被忽略的兼容性限制
MongoDB 5.0 的 auditLog.filter 不处理以下情况，配置了也无效：
-
atype: "authCheck"类型的事件无法用user字段精确过滤（例如{"user": "admin"}不生效），只能靠atype+param粗筛 - 分片集群中，
mongos上配置的 filter 不会下推到mongod分片节点；每个mongod必须单独配置自己的auditLog.filter - filter 不影响审计日志的格式或字段存在性，它只是“事后丢弃”，所以日志体积仍可能很大——真正要降量，得结合
atype白名单 +ns限定
最常出错的是把 filter 当成通用日志级别开关，其实它只做匹配丢弃，不改变审计模块本身的触发逻辑。如果发现 filter 没生效，优先检查 auditLog.destination 是否用了 console，或者配置是否加载成功（可用 db.runCommand({getCmdLineOpts: 1}) 查看实际生效参数）。
