MongoDB系统操作日志不应存system.profile，而应建独立数据库（如monitoring）的普通集合，设TTL索引自动过期；分片时须用哈希或组合片键避免写热点；优先通过db.currentOp()和配置profiling捕获日志，批量insertMany写入并关闭冗余校验。
MongoDB 系统操作日志该存哪儿？别碰
系统操作日志（比如慢查询、命令执行、连接事件）默认不持久化，
是临时的 capped collection，重启或空间满就丢数据，且只对开启 profiling 的 db 生效，不能跨分片聚合。真要长期存，得自己建集合收日志。
推荐用独立数据库（如
）建普通集合（非 capped），带
自动过期，比如：
不用
命名空间——这些是 MongoDB 内部保留名，写入可能被拦截或忽略
避免用
当时间戳主键——容易因时钟回拨导致重复或乱序，改用显式
分片集群下，这个集合必须设为「按
哈希分片」或「范围分片」，否则写入会打到单个 chunk 上，成为瓶颈
分片集合上追加写入慢？检查 chunk 分布和片键选择
日志类集合写多读少，但一上分片就卡，大概率是片键没选对。用
默认 ObjectId 当片键，前 4 字节是秒级时间戳，会导致新写入全部落到同一个 chunk（即“末尾热点”），所有写请求压向一个 shard。
正确做法是让写入打散：
用哈希片键：
—— 写入均匀，但范围查询（如查某小时日志）变全表扫
用组合片键：
，其中
是离散值（如服务名、实例 ID），再加时间，兼顾写入分散和时间范围查询效率
千万别用纯递增字段（如自增整数、毫秒时间戳）做范围分片键——等于主动制造热点
从 oplog 或 mongos 日志里捞操作记录？优先走
+
想审计谁在什么时候执行了什么命令，直接读 oplog 不现实：它只存数据变更（
），不存
、
这类管理操作；mongos 日志又分散在各节点，难聚合。
更可控的方式是开启运行时操作捕获：
在 mongod 启动时加参数：
，再配合
记录命令详情
定期调用
抓长任务，结果 insert 到你的
集合
用
命令滚动日志，避免单文件过大；同时配置
，防止 mongod 意外退出丢失未刷盘的操作上下文
写入吞吐上不去？绕开文档校验和单条插入
每秒几千条日志写入时，逐条
会触发大量网络往返和 BSON 解析，CPU 和网络很快见顶。
两个硬优化点必须做：
批量写入：
每批 100–500 条，太大易 OOM，太小没收益；注意设置
，失败单条不影响其余
关掉写关注以外的开销：
（不等多数节点确认），
（日志文档结构固定，没必要每次校验）
如果用 Driver 是 Python PyMongo，别用
，改用
转
，减少时区转换开销
分片环境下，批量写入还依赖 mongos 的路由优化——确保每批文档的片键值足够离散，否则 mongos 仍会把整批发给同一个 shard。
system.profilesystem.profilemonitoringttlIndexdb.createCollection("oplog_events")
db.oplog_events.createIndex({ "timestamp": 1 }, { expireAfterSeconds: 2592000 }) // 30天system.*_idtimestamp: ISODate()timestamp_idsh.shardCollection("monitoring.oplog_events", { "timestamp": "hashed" }){ "shard_key": 1, "timestamp": 1 }shard_keydb.currentOp()logRotateinsert/update/deletefindcreateIndex--profile=2 --slowms=100 --logpath /data/log/mongo-profile.logdb.setLogLevel(1, "command")db.currentOp({ "secs_running": { "$gt": 2 } })oplog_eventslogRotatestorage.journal.enabled: trueinsertOne()insertMany()ordered: falsewriteConcern: { w: 1 }bypassDocumentValidation: truedatetime.now()time.time()ISODate