mongostat 是最快暴露 MongoDB 瓶颈节点的工具，重点关注 conn（连接数）、qr/qw（读写队列）和 faults/s（页错误率）：conn 持续偏高说明流量不均或直连单点，qr/qw 持续增长表明请求堆积，faults/s > 50 提示内存不足。
直接看 mongostat 的 conn 和 qr/qw，再交叉验证 netstat 和 sniffnet，基本能锁定是客户端狂建连、某 shard 磁盘卡死，还是后台有异常流量在偷带宽。
为什么 mongostat 是第一排查入口
它不依赖登录每台机器，也不需要查日志，10 秒内就能暴露异常节点。在任意能连到 mongos 的终端执行：mongostat --host <mongos_host>:27017 1
重点关注三列：
-
conn：持续高于其他 mongos（比如 800+ vs 其他 200）→ 客户端直连单点或流量没打散 -
qr/qw：非零且缓慢爬升 → 请求在排队，不是瞬时抖动，而是后端处理不过来 -
faults/s > 50：WiredTiger 缓存撑不住，开始疯狂换页，本质是内存不足，IO 压力会同步放大
连接数高 ≠ mongos 扛不住，先用 netstat 看真实 TCP 连接
mongos 本身不维护连接池，所有客户端连接都是透传的，所以高 conn 很可能只是客户端没复用连接。执行：
netstat -an | grep :27017 | wc -l
对比 mongostat 显示的 conn 值：
- 两者接近且持续高位 → 检查客户端是否禁用了连接池，或设置了过短的
maxIdleTimeMS -
netstat远大于mongostat.conn→ 说明大量连接已断开但 TCP 状态还卡在TIME_WAIT，需调优系统net.ipv4.tcp_fin_timeout -
mongostat.conn高但netstat正常 → 可能是 mongos 到 shard 的内部连接异常堆积，要进对应 shard 查db.serverStatus().connections
怀疑后台有未知进程偷跑流量？用 sniffnet 实时抓包
比起 tcpdump + wireshark 手动过滤，sniffnet 能直接按应用、域名、国家聚合流量，一眼识别异常：
- 启动后看「连接列表」，筛选协议为
MongoDB或目标端口27017，确认是不是预期客户端 IP 在通信 - 如果看到大量来自内网非业务 IP 的
TCP连接，且目标端口是27017，立刻查该 IP 对应机器是否被植入恶意脚本 - 启用「地理定位」视图，发现境外 IP 频繁建立短连接 → 可能是暴力扫描或未授权访问尝试
定位到某 shard 流量异常后，用 mongotop 锁定热点集合
mongostat 告诉你“哪台机器忙”，mongotop 才告诉你“忙在哪张表”。在疑似异常的 shard primary 上执行：
mongotop 1
重点关注：
- 某个集合的
total时间占整机 70% 以上 → 立即查该集合的索引和查询模式，尤其是find是否漏了分片键 -
system.keys或system.profile耗时突增 → 检查是否误开了 profiling，或密钥轮换触发高频写入 - 所有集合都均匀耗时，但
write占比极高 → 可能是应用层在做大量小文档写入，考虑批量合并或调整写关注
真正容易被忽略的是：分片键设计缺陷导致数据全落在一个 chunk，此时网络流量异常其实是假象——背后是数据分布失衡，sh.status() 和 db.collection.stats() 中的 nchunks 和 shards 字段才是根因证据。
