connections.current仅反映本节点逻辑连接数，不区分读写类型、不体现请求量或耗时，易误判真实负载；需结合serverStatus.metrics.operation、mongostat队列与吞吐、mongotop热点分析三类指标交叉验证。
connections.current 只反映本节点的连接数，不能直接代表请求负载——它不区分读/写、不体现操作类型、也不包含请求耗时或分流效果。真要看“每个节点实际承担了多少请求”，得组合多个指标+跨层验证。
为什么只看 connections.current 会误判负载
副本集里主节点 connections.current 高，可能是客户端连上了但没发请求；从节点该值低，也不代表没干活——比如用 readPreference=secondaryPreferred 时，大量短连接只在读时建立、执行完立刻断开，current 峰值极短，监控采样容易漏掉。更关键的是：连接数 ≠ 请求量，一个连接可发 100 次查询，另一个连接可能 idle 5 分钟。
常见误判场景：
- 主节点
connections.current是从节点 3 倍，但mongostat显示主节点qr（read queue）为 0、从节点qr长期 ≥8 → 实际读请求全压在从节点 - 从节点
connections.current稳定在 20，但mongotop发现其collectionX的 read time 占比超 70% → 小连接大负载，current完全掩盖真实压力 - 客户端启用了连接池（如 Node.js 的
maxPoolSize: 10），所有读写都复用这 10 个连接 →current恒定，但 ops/sec 差异可达 10 倍
真正有用的节点级请求负载指标组合
必须同时查三项，缺一不可：
-
db.serverStatus().metrics.operation中的read和write计数器（注意是累计值，需做差分计算 QPS） -
mongostat实时输出里的qr（read queue）、qw（write queue）和netIn/netOut字节量（反映实际数据吞吐） -
mongotop --host按集合维度看毫秒级读写耗时，确认热点是否集中在某节点的特定集合:27017
示例：对比主从节点的 read 操作增量（10 秒内）
db.serverStatus().metrics.operation.read
若主节点增量为 120、从节点为 890 → 读请求明显分流成功；若从节点仅 5 → 不是负载低，而是根本没收到读请求，该查 readPreference 配置或驱动版本兼容性。
如何安全地批量采集多节点 connections.current 并关联上下文
别手动逐个 mongosh 登录。用脚本统一拉取，但必须带上节点角色和时间戳：
- 先通过
rs.status()获取各成员的name和stateStr（如PRIMARY、SECONDARY） - 对每个
name执行：mongosh "mongodb://$NODE?connectTimeoutMS=2000" --eval "db.serverStatus().connections.current + ' ' + db.isMaster().ismaster" - 结果示例：
42 true（主节点）、18 false（从节点）→ 至少能排除“连接数高但角色错乱”的低级错误 - 避免在
hidden或slaveDelay> 0 的节点上依赖current做读负载判断，这类节点通常被客户端路由策略主动规避
最容易被忽略的底层干扰：OS 层连接状态不一致
Linux 的 ss -s 或 netstat -an | grep :27017 | wc -l 统计的 ESTABLISHED 连接数，常和 db.serverStatus().connections.current 对不上。原因包括：
- MongoDB 内部连接池复用，
current统计的是逻辑连接，OS 层看到的是 TCP 连接，一个逻辑连接可能对应多个 TCP 连接（尤其开启 TLS 后） - 客户端异常断连未触发 MongoDB 连接清理（如 kill -9 进程），
current仍计数，但 OS 层已消失 → 此时current虚高 - 云环境 NAT 网关或 LB 的连接空闲超时（如 AWS ALB 默认 3600 秒），TCP 连接被中间设备断开，但 MongoDB 还未感知 →
current滞后下降
所以只要发现 current 和 OS 层连接数偏差持续 >15%，第一反应不是查应用，而是检查网络路径中是否存在中间设备干预连接生命周期。
