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