MongoDB 默认不启用审计日志，dropCollection 操作无记录；需在 4.2+ 社区版或企业版中配置 auditLog 参数并显式包含 atype: "dropCollection" 规则才能捕获。
如何确认 MongoDB 是否启用了审计日志并捕获 dropCollection
默认情况下，MongoDB **完全不记录任何审计日志**，dropCollection 操作不会自动留下痕迹。必须显式启用审计功能，并配置为捕获 dropCollection 事件类型。
检查是否启用：连接到 mongod 实例后运行 db.runCommand({ getAuditLog: 1 }) —— 如果返回 "no such cmd" 或报错 command not found，说明审计模块未启用（4.2+ 才内置；4.0 需企业版）。
启用前提：
- 使用 MongoDB Community Edition 4.2+ 或 Enterprise Edition（4.0+ 支持更细粒度）
- 启动时必须带
--auditDestination file --auditFormat JSON --auditPath /var/log/mongodb/audit.log等参数（或在mongod.conf的auditLog块中配置） - 审计规则需明确包含
dropCollection：例如{ "atype": "dropCollection", "success": true }，否则即使启用了审计，该操作也会被过滤掉
从审计日志里快速定位 dropCollection 记录的关键字段
审计日志是 JSON 行格式（每行一个事件），dropCollection 事件的核心识别依据不是操作名本身，而是 atype 和 param 结构。
典型匹配模式：
-
"atype": "dropCollection"—— 必须存在，这是事件类型的唯一标识 -
"param": { "ns": "mydb.mycollection" }——ns字段给出被删库名和集合名，注意不含引号（JSON 原始值） -
"local": { "ip": "10.0.1.22", "port": 27017 }—— 客户端 IP 和端口，但仅对直连有效；通过 mongos 或代理时可能显示为中间节点地址 -
"remote": { "ip": "192.168.5.100", "port": 56789 }—— 实际发起请求的客户端地址（比local更可靠） -
"user": { "user": "admin", "db": "admin" }—— 认证用户，若用空用户或未认证连接，此字段可能缺失或为{}
示例 grep 命令提取所有 drop 操作：
grep '"atype":"dropCollection"' /var/log/mongodb/audit.log | grep '"ns":"mydb\.users"'
dropCollection 在分片集群中的日志表现与陷阱
在 sharded cluster 中，dropCollection 请求由 mongos 接收并转发给 config server 和各 shard，但**只有 mongos 和目标 shard 会各自记录一条审计日志** —— 这容易误判为重复操作或多人操作。
关键区别点：
- mongos 日志中
"param.ns"是完整命名空间（如"test.users"），且"remote"是应用真实 IP - shard 节点日志中
"param.ns"可能是内部命名（如"test.users.23a7f"分片后缀），且"remote"显示为 mongos 地址而非终端用户 - config server 日志中通常只记录元数据变更（如
dropDatabase或 chunk 清理），**一般不记录dropCollection事件**，除非显式配置了 config server 审计 - 如果集合跨多个 shard，你可能在多个 shard 日志中看到同名
"atype":"dropCollection"，但时间戳应高度接近（毫秒级），且"param.uuid"字段（若存在）可用来做唯一性比对
没有审计日志时，还能否反向推断谁执行了 dropCollection
不能直接确认“谁”，但可通过间接线索缩小范围：
- 检查
mongod.log（非审计日志）：启用verbosity: { verbosity: 2 }后，部分版本会在日志中打印类似Command dropCollection ... from client=10.0.1.22:54321的信息，但无用户身份，且默认级别下不输出 - 查看 oplog：在
local.oplog.rs中搜索{ "op": "c", "ns": "mydb.$cmd", "o": { "drop": "mycollection" } }，结合"ts"时间戳，再查同一时间窗口内的 auth 日志或应用访问日志 - 数据库快照/备份时间点：若定期 mongodump 或使用云服务快照，对比删除前后快照的
listCollections输出，可确认发生时间窗口，再结合运维系统（如堡垒机、K8s audit log）排查该时段登录记录 - 应用层埋点：最可靠的方式是在 driver 层统一封装
dropCollection调用，强制记录调用栈、trace ID、操作人账号（如从 JWT 解析）—— 审计日志只是兜底，不是第一道防线
真正棘手的是：审计日志本身不可篡改，但若没提前开启，它就不存在；而一旦开启，又必须确保磁盘不爆、权限不泄露、日志轮转策略合理——这些比“怎么查”更决定你能否查到。
