1. 课程导入与监控体系总览

在生产环境中，MongoDB 的稳定性往往不是被某一次“大故障”击垮的，而是被一系列被忽视的小信号逐步拖入深渊：副本集延迟从 0.2 秒缓慢爬升到 8 秒、连接数从 300 悄悄逼近 2000、WiredTiger 缓存脏页比例长期高于 20%、磁盘 IOPS 在业务高峰期反复触顶。这些问题在单次巡检中几乎看不出来，但一旦叠加，就会演变为主节点选举风暴、写入阻塞甚至数据不可用。因此，本课程的第一件事不是讲某个监控工具怎么装，而是先建立一套完整的认知框架：监控解决“现在是否健康”，容量规划解决“未来是否撑得住”，两者共同构成从指标采集到决策闭环的生产保障体系。

一、生产监控与容量规划的目标与边界

生产监控的核心目标可以归纳为三句话：及时发现异常、快速定位根因、为容量决策提供数据依据。它关注的不是“服务器是否开机”，而是“业务请求是否被正确、及时地处理”。因此监控的边界应当覆盖四个层面：

• 可用性：副本集是否有多数节点在线、主节点是否稳定、是否存在频繁选举。
• 性能：读写延迟、吞吐量、慢查询数量、锁等待与排队情况。
• 资源：CPU、内存、磁盘 IOPS/吞吐/使用率、网络带宽、连接数。
• 数据健康：复制延迟、oplog 窗口、缓存脏页比例、索引命中率、分片均衡状态。

容量规划则是在监控数据的基础上向前看一步：当前资源还能支撑多久？何时需要扩容？扩什么、扩多少？它需要回答的是趋势问题，而不是瞬时问题。两者的边界可以这样理解：监控回答“现在怎么样”，容量规划回答“未来会怎么样”，而两者共享同一套指标采集与存储底座。

二、核心指标体系：从信号到判断

MongoDB 的监控指标数量庞大，但真正决定生产稳定性的核心指标可以收敛为以下几类。下面这张图展示了从底层资源到上层业务信号的完整指标链路，以及每个环节最值得关注的判断依据。

这张图的核心价值在于：它把“指标”和“判断”绑定在一起。很多团队采集了几百个指标，却不知道哪个指标超过什么阈值该做什么动作。例如，WiredTiger 缓存脏页比例超过 20% 意味着后台 eviction 线程可能跟不上写入速度，需要检查写入突增或磁盘 IO 瓶颈；oplog 窗口小于 2 小时意味着一旦从节点宕机超过 2 小时就无法通过 oplog 追赶，必须全量同步，这在数据量大的生产库中可能耗时数小时甚至数天。

三、从采集到决策的闭环方法论

监控体系不是“装一个 Prometheus + Grafana”就结束了。一个真正能支撑生产决策的闭环应当包含六个环节：

1. 采集：确定采集频率与粒度。生产环境建议核心指标 15 秒采集一次，资源类指标 30 秒一次，容量趋势类指标 5 分钟一次。采集频率过高会加重数据库负担，过低则可能漏掉短时尖峰。
2. 存储与聚合：原始数据保留 15～30 天，聚合数据（如小时均值、日均值、P95/P99）保留 1 年以上，用于容量趋势分析。
3. 告警：告警规则必须分级。P0 级（如主节点不可用、复制延迟 > 30s）立即电话通知；P1 级（如磁盘使用率 > 85%、连接数 > 80%）企业微信/钉钉通知；P2 级（如慢查询增多、索引命中率下降）记录工单，次日处理。
4. 定位：告警触发后，需要有一套标准化的排查路径。例如“P99 延迟升高”应依次检查：慢查询日志 → 当前操作 db.currentOp() → 锁等待 → 磁盘 IO → 缓存脏页。
5. 处置与复盘：每次故障处理后必须记录根因、影响范围、处置动作和后续改进项。复盘不是为了追责，而是为了把个案转化为规则。
6. 容量评估与扩容：基于历史趋势，按“当前资源使用率 + 业务增长率 + 安全冗余”计算扩容时间点。例如磁盘使用率每月增长 5%，当前 60%，安全阈值 80%，则约 4 个月后需要扩容。

四、常见误区与边界意识

在建立监控体系时，有几个常见误区值得提前警惕：

• 只监控服务器，不监控数据库语义。CPU 和内存正常不代表 MongoDB 健康，复制延迟、oplog 窗口、缓存脏页这些数据库特有指标才是关键。
• 告警过多导致“狼来了”。如果每天收到几百条告警，团队会逐渐麻木。告警规则必须经过阈值调优，确保每条告警都值得处理。
• 把容量规划等同于“加磁盘”。容量规划还包括连接数上限、oplog 大小、分片键选择、索引增长等维度。磁盘够用但连接数打满，同样会导致服务不可用。
• 忽视业务侧信号。数据库指标正常但业务 P99 延迟升高，可能是应用连接池配置不当或网络抖动，需要联动排查。