MongoDB故障码2860是什么？索引操作与审计功能有何关系？

MongoDB 返回 2860 错误码时，错误信息通常带有 Audit not enabled。字面意思是审计未启用，但这个错误经常在索引相关操作或审计参数配置时冒出，容易让人误以为是索引损坏。实际上，2860 对应的是审计子系统没有激活。当实例没有配置 auditLog.destination 时，任何试图开启审计参数、加载审计过滤器，或者查询审计事件的命令都会被拒绝。

接下来会展开这个错误码的产生条件、它和 createIndexes 等索引 DDL 的关联，以及完整的排查修复路径。

一、错误码 2860 的本质与常见触发场景

错误码 2860 在 MongoDB 内部被称为 AuditNotEnabled。它不属于索引结构损坏、存储引擎异常或网络超时，而是审计功能没有被启动。MongoDB 的审计系统需要在 mongod 启动阶段通过配置参数激活，核心参数是 auditLog.destination。如果这个参数缺失，或者配置了但配置文件没有被正确加载，进程虽然能正常提供读写服务，但审计相关能力处于关闭状态。

常见的触发场景是这样的：DBA 想临时调整审计策略，执行了 db.adminCommand({ setParameter: 1, auditAuthorizationSuccess: true })，结果项直接返回错误码 2860。很多人第一反应是去检查命令语法，实际上命令本身没问题，问题在于审计没有启用。另一个典型场景是业务侧正在创建索引，同时应用层需要读取审计日志以确认谁执行了 DDL，却发现审计文件没有生成任何记录，回头查实例状态时触发 2860。

需要特别说明的是，setParameter 只能调整审计行为参数，例如是否记录授权成功事件、是否记录读写操作，但它不能替代 auditLog.destination 来启动审计引擎。MongoDB 审计目前不支持在运行时直接开启，必须修改配置并重启 mongod。如果误以为 2860 只是参数开关问题，往往会反复修改运行参数而无法解决。

二、索引操作如何进入审计视野

MongoDB 审计事件类型覆盖了大多数 DDL 和 DML。索引相关的事件主要有 createIndexes 和 dropIndexes，此外 collMod 修改集合属性时如果涉及索引选项，也会被审计系统记录。创建索引属于高权限、高风险操作，在生产环境中通常是审计重点。通过审计日志可以知道谁、在什么时间、从哪个客户端、在哪个命名空间上创建了什么索引。

下面是一条典型的 createIndexes 审计事件，JSON 格式的结构如下：

{
  "atype": "createIndexes",
  "local": { "ip": "10.0.0.12", "port": 27017 },
  "remote": { "ip": "10.0.0.99", "port": 55124 },
  "users": [ { "user": "dbAdmin", "db": "admin" } ],
  "roles": [ { "role": "dbAdmin", "db": "orders" } ],
  "param": {
    "ns": "orders.inventory",
    "indexName": "user_id_1",
    "key": { "user_id": 1 }
  },
  "result": 0
}

如果只想让审计日志聚焦索引变更，可以通过 auditLog.filter 进行过滤。下面的配置表示只记录创建索引和删除索引事件，避免全量审计给日志系统带来过大压力：

auditLog:
  destination: file
  format: JSON
  path: /var/log/mongodb/audit.log
  filter: '{ atype: { $in: [ "createIndexes", "dropIndexes" ] } }'

在实际维护中，索引 DDL 与审计的关系体现在两个层面：一是审计是否启用决定了索引操作能否被追踪，二是过滤器的配置会影响索引事件是否出现在日志里。因此当索引操作没有被审计记录时，除了检查权限和日志路径，还要先确认实例是否因 2860 状态而完全没有激活审计。

三、从 2860 到完整审计配置的排查步骤

解决 2860 的第一步是检查 mongod 的启动配置。打开 mongod.cfg 或启动命令，确认是否存在 auditLog 配置块。如果完全没有，就需要补上 auditLog.destination、auditLog.format 和 auditLog.path。如果要启用过滤器，还要把 auditLog.filter 一并写入。值得注意的是，Windows 环境下的路径必须保留反斜杠，例如 C:\MongoDB\log\audit.log，不能写成 C:/MongoDB/log/audit.log。

一份完整的配置文件示例如下：

systemLog:
  destination: file
  path: C:\MongoDB\log\mongod.log
  logAppend: true
storage:
  dbPath: C:\MongoDB\data
  journal:
    enabled: true
auditLog:
  destination: file
  format: JSON
  path: C:\MongoDB\log\audit.log
  filter: '{ atype: { $in: [ "createIndexes", "dropIndexes" ] } }'

配置完成后重启 mongod。如果在 Linux 下使用 systemd 管理，可以执行 systemctl restart mongod；如果是 Windows 服务，可以使用 net stop MongoDB 和 net start MongoDB。重启后不要再用 setParameter 测试审计是否启用，直接执行一条索引操作，然后查看审计日志文件。

db.inventory.createIndex({ user_id: 1 }, { name: "user_id_1" })

操作成功后，在审计日志路径中使用检索命令确认事件：

grep "createIndexes" /var/log/mongodb/audit.log

如果日志输出了包含 createIndexes 的 JSON 事件，说明审计已经正常启用，2860 问题也随之消失。如果路径下没有日志文件，要检查 auditLog.destination 取值是否合法，常见值有 file、syslog、console。另外还要确认运行 mongod 的用户对日志目录有写权限，否则审计日志可能因为权限不足而无法写入。

对于分片集群或副本集，审计配置需要在每个节点上分别完成，仅配置主节点不能覆盖从节点和配置服务器。2860 还可能只在某个从节点上出现，原因就是该节点没有加载 auditLog 配置。逐个节点检查并统一配置，是避免这类问题反复出现的关键。

审计开启后，索引 DDL 操作就具备了可追溯性。建议根据实际风险范围设置过滤器，只记录 createIndexes、dropIndexes、dropDatabase 等高风险事件，既能满足安全审计要求，又不会因为日志量过大影响磁盘和监控性能。

MongoDB故障码2860MongoDB审计MongoDB索引修改时间：2026-09-18 11:28:27