外观
MongoDB 副本集监控指标
副本集健康状态指标
rs.status() 核心指标
- ok：副本集状态是否正常（1=正常，0=异常）
- set：副本集名称
- date：当前时间戳
- myState：当前节点状态
- 0：启动中
- 1：主节点
- 2：从节点
- 3：恢复中
- 5：仲裁节点
- members：副本集成员列表及状态
成员状态指标
- name：节点名称和端口
- health：节点健康状态（1=正常，0=异常）
- state：节点状态码
- stateStr：节点状态描述
- uptime：节点运行时间（秒）
- optime：节点最后一次操作时间戳
- optimeDate：节点最后一次操作日期
- syncingTo：从节点同步的源节点
复制延迟指标
复制延迟核心指标
- replicationLag：从节点与主节点的时间差（秒）
- oplogTimeDiff：oplog时间差，反映数据同步延迟
- heartbeatIntervalMillis：心跳间隔（默认2秒）
- heartbeatTimeoutSecs：心跳超时时间（默认10秒）
监控复制延迟的方法
- 使用
rs.printSlaveReplicationInfo()查看复制延迟 - 监控
replSetGetStatus命令输出 - 使用MongoDB Atlas或Ops Manager的复制延迟图表
- 配置Prometheus + Grafana监控
mongodb_replica_set_member_optime_date指标
选举相关指标
选举指标
- electionCount：副本集选举次数
- electionTimeoutMillis：选举超时时间（默认10秒）
- electionCandidateMetrics：选举候选者指标
- electionParticipantMetrics：选举参与者指标
选举事件监控
- 监控MongoDB日志中的选举事件
- 使用
db.adminCommand({ getLog: "rs" })查看副本集日志 - 配置选举事件告警
Oplog相关指标
Oplog大小和利用率
- oplogSizeMB：Oplog大小（MB）
- oplogWindowHours：Oplog可回溯的时间窗口（小时）
- oplog利用率：已使用的Oplog百分比
Oplog监控方法
- 使用
db.getReplicationInfo()查看Oplog信息 - 监控
local.oplog.rs集合大小 - 配置Oplog利用率告警
连接和流量指标
连接指标
- connections.current：当前连接数
- connections.available：可用连接数
- connections.totalCreated：总创建连接数
网络流量指标
- network.bytesIn：入站流量（字节）
- network.bytesOut：出站流量（字节）
- network.numRequests：请求数量
监控工具和策略
监控工具
- mongostat：实时监控副本集状态
- mongotop：监控集合级别的读写操作
- MongoDB Atlas：云服务内置监控
- Ops Manager：企业级监控解决方案
- Prometheus + Grafana：开源监控组合
- Datadog：第三方监控服务
监控策略
- 实时监控：1秒间隔（mongostat）
- 长期监控：60秒间隔
- 关键指标：5-10秒间隔
- 日志监控：24小时实时分析
告警设置
关键告警阈值
| 指标 | 警告阈值 | 严重阈值 |
|---|---|---|
| 复制延迟 | 10秒 | 30秒 |
| Oplog利用率 | 70% | 90% |
| 节点健康状态 | 节点不可达 | 主节点不可达 |
| 连接数 | 80%最大连接数 | 95%最大连接数 |
| 选举次数 | 1次/天 | 3次/天 |
告警渠道
- 邮件告警
- 短信告警
- 企业微信/钉钉告警
- PagerDuty等专业告警工具
性能优化建议
降低复制延迟
- 优化网络连接，使用低延迟网络
- 增加Oplog大小，延长Oplog窗口
- 确保从节点硬件性能与主节点匹配
- 减少主节点的写操作压力
- 配置适当的索引，加速从节点应用操作
提高副本集可用性
- 使用奇数个节点（3、5、7个）
- 分布节点到不同可用区或数据中心
- 配置适当的选举超时时间
- 定期进行故障恢复演练
- 监控Oplog大小和利用率
优化连接管理
- 配置适当的
maxConns参数 - 使用连接池管理客户端连接
- 监控连接泄漏
- 限制单个客户端的连接数
版本差异
MongoDB 3.6 vs 4.0
- 4.0版本增强了副本集监控指标
- 4.0版本引入了更详细的选举指标
- 4.0版本优化了Oplog管理
MongoDB 4.0 vs 4.2
- 4.2版本引入了
replSetResizeOplog命令 - 4.2版本增强了复制延迟监控
- 4.2版本改进了选举算法
MongoDB 4.2 vs 5.0
- 5.0版本引入了实时性能分析
- 5.0版本增强了副本集健康检查
- 5.0版本优化了复制协议
MongoDB 5.0 vs 6.0
- 6.0版本增强了Oplog可见性
- 6.0版本改进了复制延迟计算
- 6.0版本引入了更多副本集监控指标
常见问题（FAQ）
Q1: 复制延迟高怎么办？
A1: 首先检查网络连接，然后查看Oplog大小是否足够，从节点硬件性能是否匹配主节点，是否有慢查询或大事务导致复制延迟。
Q2: 如何查看副本集成员的详细状态？
A2: 使用rs.status()命令查看副本集状态，或使用db.adminCommand({ replSetGetStatus: 1 })获取更详细的信息。
Q3: 如何监控Oplog大小和利用率？
A3: 使用db.getReplicationInfo()命令查看Oplog信息，或监控local.oplog.rs集合大小和oplogWindowHours指标。
Q4: 副本集选举频繁是什么原因？
A4: 可能是网络不稳定、主节点负载过高、选举超时时间设置过短或节点配置不当导致的。
Q5: 如何配置副本集监控告警？
A5: 可以使用MongoDB Atlas、Ops Manager或Prometheus + Grafana配置告警，设置适当的阈值和告警渠道。
Q6: 从节点同步状态显示"RECOVERING"是什么意思？
A6: 从节点正在恢复中，可能是因为重启、网络中断或数据不一致导致的。等待恢复完成或检查日志获取更多信息。
Q7: 如何提高副本集的可用性？
A7: 使用奇数个节点，分布节点到不同可用区，配置适当的选举超时时间，定期进行故障恢复演练，监控Oplog大小和利用率。
Q8: 如何调整Oplog大小？
A8: 在MongoDB 4.2及以上版本，可以使用replSetResizeOplog命令在线调整Oplog大小。在早期版本，需要重启节点并修改配置文件。