分片集群必须盯紧chunk distribution、balancer status、mongos query routing latency、chunk migration rate四个硬指标；它们分别反映负载均衡状态、均衡器运行情况、请求路由性能及数据迁移健康度。

分片集群必须盯紧的四个硬指标

分片集群不是单机 MongoDB 的简单放大，监控重点得从“单点健康”转向“全局协同”。不看清楚这四个指标，很容易在数据迁移、请求路由、负载倾斜时完全失察。

• chunk distribution：每个分片上 chunk 数量是否均衡。差值超过 10% 就该警惕——这不是“稍有不均”，而是负载均衡器可能已失效或被禁用的信号
• balancer status：直接查 sh.getBalancerState() 和 sh.isBalancerRunning()。状态为 false 却没主动停过，说明配置服务器主节点异常或 balancer 进程崩溃
• mongos query routing latency：mongos 层的平均请求转发延迟（非数据库执行时间）。持续 >50ms 通常意味着 mongos 资源不足，或 config server 响应变慢
• chunk migration rate：单位时间内完成的迁移次数。突然归零或骤降，大概率是迁移被阻塞（如目标分片磁盘满、网络分区、WiredTiger cache 不足）

为什么 connections 在分片集群里更危险

单机 MongoDB 的连接数超限顶多影响自身，分片集群里它会连锁恶化：

在SEO发布前，从路由清单生成XML网站地图和robots.txt

当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。

下载

• mongos 连接数打满 → 新请求排队 → 整个集群吞吐断崖下跌
• 某个分片 connections 异常飙升 → 很可能是该分片成为查询热点（如缺失索引、shard key 选择不当），但监控面板默认不告警
• config server 连接数持续上涨 → 表明 balancer 或客户端频繁刷新元数据，可能触发元数据锁争用

query targeting 指标在分片场景下的真实含义

这个指标在副本集里反映“有没有走索引”，在分片集群里它还额外暴露路由效率问题：

• 值
• 值在 0.95–1.0 之间但 mongos CPU 高：说明路由逻辑没问题，但 mongos 正在做大量文档合并/排序，需检查聚合管道是否下推失败
• 该指标在 Ops Manager 中只统计 mongos 层，不反映单个 mongod 实例的扫描效率——想看后者得进具体分片查 db.currentOp()

容易被忽略的硬件级陷阱：disk IOPS 和 normalized system CPU 的分片特异性

单机部署看磁盘 IOPS 是看吞吐瓶颈，分片集群里它必须拆开看：

• 所有分片的 disk IOPS 都高 → 全局写入压力过大，或 WiredTiger 日志刷盘配置不合理
• 仅 1–2 个分片 disk IOPS 突增 + normalized system CPU 同步飙高 → 典型 chunk 迁移中目标分片正在密集写入，此时迁移窗口若未限制，会拖垮整个集群响应
• config server 的 normalized system CPU >70% → 元数据读写争用，sh.status() 变慢、balancer 心跳延迟，甚至导致 chunk 分配卡住

分片集群的监控难点不在数据采集，而在指标之间的因果关系——比如 chunk distribution 失衡，可能是 balancer 停了，也可能是 config server 不可用，还可能是某分片 disk IOPS 长期超限导致迁移反复失败。不把这几个指标交叉对照，光看单图等于蒙眼开车。