在MongoDB的运维体系中，日志管理往往被忽视，直到磁盘被填满才引起重视。很多工程师听说过$logRotate，却不清楚它到底属于哪一层能力。实际上，$logRotate并不是聚合管道里的一个阶段运算符，而是MongoDB提供的数据库命令，用于通知mongod或mongos重新打开日志文件，从而实现日志轮换。理解这一点，是避免误用和构建稳定日志策略的前提。
厘清$logRotate的真实定位与调用方式
首先要明确，MongoDB的聚合管道由一系列阶段组成，例如$match、$group、$project等，这些阶段都写在aggregate方法的数组参数里。而$logRotate并不出现在这个数组中，它是通过db.runCommand({ logRotate: 1 })或者直接调用db.adminCommand({ logRotate: 1 })来执行的命令。如果在聚合语句里写{ $logRotate: 1 }作为阶段，MongoDB会抛出解析错误，因为管道阶段名必须以美元符号加已知算子开头，且命令与算子分属不同体系。
从底层原理看，当MongoDB以日志文件方式运行（如指定了--logpath）时，所有诊断日志都会追加写入该文件。执行logRotate命令后，进程会关闭当前文件描述符，并按照配置重新打开一个新的日志文件，旧文件通常保持不变或由外部工具重命名。这与Linux的logrotate不同：后者靠重命名加信号，MongoDB内建命令更轻量，且不需要向进程发SIGUSR1，适合脚本化调用。
下面是一段在mongo shell中正确触发日志轮换的代码，可以看到它和聚合管道毫无关系，只是单纯的管理命令：
// 使用管理员权限执行日志轮换
use admin;
db.runCommand({ logRotate: 1 });
// 如果是分片集群的mongos，同样适用
// db.adminCommand({ logRotate: 1 });
用管道化思维设计自动日志轮换方案
虽然$logRotate不是聚合阶段，但我们可以借用聚合管道“分步处理”的思想来设计轮换流程。第一步，利用聚合统计各个节点日志体量或借助getLog等命令筛选需要干预的目标；第二步，对目标调用logRotate；第三步，用系统命令归档旧日志。这种分段执行的逻辑，和写一条多阶段管道非常相似，只是每一步用了不同API。
举例来说，在单机部署中，我们可以写一个shell脚本，先检查日志大小，再决定是否轮换。相比直接删除日志文件，管道式方案保证了MongoDB始终有一个合法的文件句柄，不会因文件消失而报错。同时，旧日志在轮换后可以被压缩或移走，实现磁盘占用的闭环控制。下面的bash示例展示了如何结合mongo命令完成这一模拟管道：
#!/bin/bash
# 第一步：检查日志大小是否超过100M
LOG_FILE=/var/log/mongodb/mongod.log
if [ $(du -m $LOG_FILE | cut -f1) -gt 100 ]; then
# 第二步：触发MongoDB日志轮换
mongo --quiet admin --eval "db.runCommand({ logRotate: 1 })"
# 第三步：归档旧日志
mv $LOG_FILE.$(date +%Y%m%d) $LOG_FILE.old 2>/dev/null
gzip $LOG_FILE.old
fi
这种方案的优势在于可观测与可回滚。每一阶段失败都能被脚本捕获，而不会像kill -SIGUSR1那样难以确认执行结果。对于容器化部署，还可以把第三步换成向对象存储上传，从而把本地磁盘压力转嫁出去。值得注意的是，若MongoDB以标准输出方式运行而非文件，logRotate命令不会生效，此时应依赖容器平台的日志驱动。
常见误区与线上避坑实践
一个典型误区是试图在聚合管道里“顺带”做日志轮换，比如写出db.collection.aggregate([{ $logRotate: 1 }, { $match: {} }])。这种写法不仅语义错误，还会让排查者误以为轮换和数据集有关。实际上日志轮换是实例级行为，与具体集合或文档无关，它影响的是mongod进程的诊断输出，而不是业务数据。
另一个坑是混淆logRotate命令与--logRotate启动参数。后者仅在进程启动时决定轮换模式（如rename或reopen），前者是运行时触发。如果在配置文件中设置了logRotate: reopen，那么执行命令后原文件会被保留，新日志写入同名文件；若设为rename，旧文件会被加上时间戳后缀。理解这个差异，才能预判轮换后磁盘上会出现什么文件，避免备份脚本找错路径。
线上实践中，建议将轮换动作纳入监控系统的健康检查之后：只有当日志体量或写入速率异常时才主动轮换并告警，而不是盲目按固定时间执行。这样既能保留完整上下文，又能在故障前后拿到清晰日志边界。结合前文提到的管道化脚本，可以把“检测、轮换、归档”三步写入同一个定时任务，并输出结构化执行记录，方便后续用聚合分析运维指标。
// 错误示例：在聚合中使用logRotate会导致报错
// db.test.aggregate([
// { $logRotate: 1 },
// { $count: "total" }
// ]);
// 正确做法：分开执行
db.runCommand({ logRotate: 1 });
db.test.aggregate([{ $count: "total" }]);
MongoDB聚合管道$logRotate修改时间：2026-08-14 05:51:27