网络流量是衡量MongoDB实例健康状况的核心指标之一。当客户端请求量突增或出现大文档读写时，网络层面的统计数字往往最先发生变化。MongoDB的聚合框架不仅擅长数据加工，还能通过特殊阶段直接读取引擎内部的状态数据，本文将围绕聚合管道中的统计能力，介绍如何获取并利用网络相关指标。
一、聚合管道中的统计阶段：$collStats详解
MongoDB官方并没有一个名为$network的聚合阶段，很多初学者误以为可以直接在管道里写{$network: {}}拿到网络数据，实际上这会直接报错。聚合框架中真正承担统计职责的阶段是$collStats，它必须作为管道的第一个阶段出现，用于返回指定集合的统计信息，其中就包含与存储引擎交互相关的延迟和操作计数。
$collStats支持几个有用的子选项：latencyStats返回读写操作的延迟直方图，storageStats返回存储层面的详细数据，count返回快速计数值。虽然它统计的是集合级别的操作而非网卡字节数，但操作延迟与吞吐变化正是网络压力的间接体现。基本用法如下：
// 获取集合的延迟统计信息
db.orders.aggregate([
{
$collStats: {
latencyStats: { histograms: true }
}
}
])
返回结果中，latencyStats.reads.latency表示读操作累计延迟（微秒），ops表示操作次数，两者相除即可得到平均延迟。histograms字段则给出了延迟分布直方图，能帮你判断是否存在长尾请求。如果平均延迟正常但高位桶计数偏高，说明有少量请求消耗了大量时间，这类问题往往与跨节点网络传输或大结果集返回有关。
二、获取真正的网络字节数：serverStatus配合聚合分析
如果需要的是实实在在的网络收发字节数，就要借助db.serverStatus()命令。它的network与metrics.network部分包含bytesIn、bytesOut、numRequests等字段，这些都是实例启动以来的累计值。单看一次快照意义不大，关键在于周期性采集并做差值计算，而聚合管道正好可以承担这部分数据加工工作。
常见的做法是先把定时采集的快照写入一个监控集合，每条文档记录时间戳和当时的累计值，然后用管道按时序计算增量：
// 对监控快照按时间排序，用窗口函数计算每分钟的流量增量
db.net_monitor.aggregate([
{ $sort: { ts: 1 } },
{
$setWindowFields: {
partitionBy: "$host",
sortBy: { ts: 1 },
output: {
prevBytesOut: {
$shift: "$bytesOut",
by: -1,
output: 0
},
prevTs: {
$shift: "$ts",
by: -1,
output: "$$REMOVE"
}
}
}
},
{
$project: {
host: 1,
ts: 1,
bytesOutDelta: { $subtract: ["$bytesOut", "$prevBytesOut"] }
}
}
])
$setWindowFields配合$shift可以拿到上一条快照的值，相减后就是采样周期内的实际流量。这个思路同样适用于connections、opcounters等其他累计型指标。建议采样间隔不要低于10秒，间隔太短会产生大量小文档，间隔太长则可能错过瞬时流量尖峰。
三、分片集群场景下的统计汇总与避坑要点
在分片集群中，数据分布在多个分片上，单独在某个节点执行统计只能看到局部信息。此时可以借助$currentOp阶段观察活跃操作的网络相关属性，或者通过mongos路由对监控数据做全局聚合。一个实用技巧是让每个分片节点定时上报快照到同一个汇总集合，再统一用$group按时间片求和：
// 按分钟汇总所有节点的进出流量
db.net_monitor.aggregate([
{
$group: {
_id: {
minute: { $dateTrunc: { date: "$ts", unit: "minute" } }
},
totalIn: { $sum: "$bytesInDelta" },
totalOut: { $sum: "$bytesOutDelta" },
nodes: { $addToSet: "$host" }
}
},
{ $sort: { "_id.minute": -1 } },
{ $limit: 60 }
])
使用这套方案时有几个容易踩坑的地方需要注意。第一，bytesIn和bytesOut是累计值，节点重启后会归零，如果不处理会导致负数增量，可以在计算时加上$cond判断，当前值小于上一值时就跳过该采样点。第二，$collStats只能作为管道第一阶段，且不能在视图上执行，遇到报错时优先检查管道顺序。第三，监控集合本身也会产生写入流量，建议为其设置TTL索引自动清理过期数据，避免监控系统反过来拖慢数据库。
总体而言，聚合管道做网络统计的思路是：用serverStatus采集原始累计值，用$setWindowFields计算增量，用$group与$dateTrunc做多节点多时间片汇总。把这个流程封装成定时脚本或接入现有监控面板，就能以极低的成本获得一套贴近数据库内部视角的流量监控能力，为容量规划和慢查询排查提供可靠的数据支撑。
MongoDB聚合管道网络统计$collStats修改时间：2026-09-01 06:40:27