MongoDB故障码1220是什么？审计日志写入失败的排查与解决方案

MongoDB的审计功能是企业版提供的一项重要能力，它会把认证、授权、CRUD等操作记录到指定的审计日志文件中，用于满足安全合规要求。当审计日志无法正常写入时，MongoDB会抛出故障码1220（Invariant failure相关错误中针对审计写入失败的场景），此时实例可能拒绝启动，或者在运行中持续报错。这个问题的表象简单，但成因往往分布在文件系统、配置文件、磁盘容量等多个层面，需要系统性地排查。

故障码1220的产生机制与常见触发场景

要理解这个故障码，首先要明白审计日志的写入链路。MongoDB在启用审计后，每产生一条审计事件，审计模块会将格式化后的日志内容追加写入到目标文件。这个目标文件由配置文件中的auditLog.destination参数决定，常见的取值有file和syslog。当写入目的地是文件时，MongoDB进程需要对目标路径拥有写权限；当日志文件按时间或大小轮转时，还需要对目录有创建文件的权限。

触发1220错误的高频场景主要有这么几类。第一类是权限问题：运维人员用普通用户手工创建过审计文件，随后改用mongod服务账户启动，服务账户没有读写该文件的权限，写入直接失败。第二类是磁盘问题：审计日志所在分区写满，或者文件系统变为只读，追加写入操作返回错误。第三类是配置问题：auditLog.path指定的目录不存在，或者配置中同时出现了相互冲突的参数组合，例如社区版误配了auditLog相关参数（社区版不支持审计功能），或者格式参数写错导致初始化阶段就失败。

还有一类容易被忽视的场景：路径中包含特殊字符或者使用了相对路径。相对路径依赖mongod进程的启动时工作目录，通过systemd启动和手工在某个目录下启动，实际解析出的路径可能完全不同，导致权限判断出现偏差。建议审计日志路径始终使用绝对路径，并且目录层级不要过深，避免踩到路径长度的边界问题。

系统性排查步骤

第一步看报错日志的完整内容。不要只盯着1220这个数字，报错信息前后通常包含具体的errno描述，比如Permission denied表示权限问题，No space left on device表示磁盘满，Read-only file system表示文件系统被挂载为只读。这些信息能把排查范围直接缩小到某一层。

第二步检查文件和目录权限。确认mongod进程的运行用户，然后切换到该用户验证写入能力：

# 查看mongod进程的运行用户
ps -eo user,pid,cmd | grep mongod

# 假设运行用户是mongodb，检查审计目录权限
ls -ld /var/log/mongodb/audit/

# 用mongodb用户测试写入（注意目录必须允许该用户写入）
sudo -u mongodb touch /var/log/mongodb/audit/test.write

第三步检查磁盘状态，包括剩余空间和inode。磁盘空间充足但inode耗尽同样会导致文件创建失败，这一点经常被忽略：

# 查看分区空间使用情况
df -h /var/log/mongodb

# 查看inode使用情况
df -i /var/log/mongodb

# 检查文件系统是否只读
mount | grep /var/log

第四步核对配置文件。确认auditLog.destination、auditLog.format、auditLog.path三个参数的取值互相匹配。当日标值为file时，path必须提供且必须是绝对路径；format只接受JSON和BSON两个值，大小写敏感，写成小写会直接报错。

正确的审计日志配置示例与修复方案

一份典型且经过验证的审计配置如下，放在mongod的配置文件中（通常是/etc/mongod.conf）：

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

针对不同成因的修复方式各不相同。如果是权限问题，执行chown和chmod将目录归属交给mongodb用户：

sudo chown -R mongodb:mongodb /var/log/mongodb/audit
sudo chmod 750 /var/log/mongodb/audit
sudo systemctl restart mongod

如果是磁盘空间不足，除了清理旧日志外，更稳妥的做法是给审计日志单独配置轮转策略，比如借助logrotate按天切割并保留固定天数，避免审计文件无限膨胀拖垮整个分区。如果文件系统被挂载为只读，需要先排查底层磁盘或存储阵列是否有硬件故障，修复后重新以读写方式挂载，再启动MongoDB。

配置修复后，建议先用配置校验确认无误再启动：

mongod --config /etc/mongod.conf --outputConfig

预防措施与运维建议

故障处理完毕不代表事情结束，更重要的是建立预防机制。首先是监控层面，对审计日志所在分区配置磁盘使用率告警，阈值建议设在80%左右，给运维留出响应时间。同时监控mongod日志中出现的审计相关错误关键字，一旦出现写入失败的苗头立即介入。

其次是配置管理层面，把mongod配置文件纳入版本管理，任何审计参数的变更都走评审流程。审计路径变更时，记得同步调整logrotate配置和SELinux策略（如果启用了SELinux，需要用semanage fcontext为新的审计目录设置正确的安全上下文，否则即使Linux权限看起来正确，写入依然会失败）：

# 为新审计目录设置SELinux上下文并应用
sudo semanage fcontext -a -t mongod_log_t "/var/log/mongodb/audit(/.*)?"
sudo restorecon -Rv /var/log/mongodb/audit

最后是容量规划层面，审计日志的增长速度与写入流量正相关，建议先在测试环境压测一轮，估算出峰值时段的日志产生量，再据此规划磁盘容量和轮转周期。对于合规要求严格的场景，可以把审计日志输出到syslog再集中收集到日志平台，这样既减轻了本地磁盘压力，也便于长期留存和检索。做好这几层防护，故障码1220基本可以在萌芽阶段就被拦住。

MongoDB故障码1220审计日志MongoDB配置修改时间：2026-09-13 01:42:30