主从延迟需分三级设防并动态适配：提醒级（300ms）、警告级（1s）、紧急级（5s），联动Oplog时长、复制队列长度、从库CPU/IO等指标，结合STL时间序列建模实现动态阈值，告警覆盖实例、副本集、节点三层。
主从架构的监控告警不能只看延迟一个数字，得结合业务影响程度、数据一致性风险和系统承载能力来分层设防。固定阈值容易误报或漏报，动态适配才是关键。
主从延迟必须分级设定告警阈值
延迟本身不是故障，但不同延迟值代表不同风险等级。建议按三级响应机制配置：
- 提醒级（300ms）：业务无感知，仅需记录并观察趋势，适合日常巡检
- 警告级（1s）：读写分离场景下可能出现脏读，触发人工核查，检查网络、IO或慢Oplog应用
- 紧急级（5s）：存在数据不一致风险，自动触发告警并联动执行预案，如暂停从库读流量、拉取Oplog分析
金融类业务还需叠加TPS判断——当主库写入突增时，可临时放宽延迟容忍度，避免高并发下的误告。
配套指标必须同步监控与联动
单看延迟容易掩盖真实问题。以下指标应与延迟联合判断，构成告警触发条件：
- Oplog保存时长：低于2小时即预警，说明从库追赶能力不足或主库写入过载
- 复制队列长度（replSetGetStatus.members.n.optimeDurable）：持续增长说明复制卡顿，比延迟更早暴露问题
- 从库CPU/IO使用率：若延迟升高同时从库负载飙升，大概率是资源瓶颈而非网络问题
- 连接数与等待队列：Mongod节点连接堆积可能阻塞复制线程，需单独设阈值（如active connections > maxConnections × 0.8）
用动态基线替代固定阈值
业务有峰谷、节假日、大促，固定阈值会频繁误报。推荐采用时间序列建模方式：
- 用STL分解提取延迟指标的周期性（如每日规律）、趋势项和残差项
- 对残差项计算滚动窗口（如7天）的均值与标准差，设告警阈值为 mean ± 2.5σ
- Prometheus中可用`prometheus_alerts_total{alertname=~"MongoReplicaDelay.*"}`配合`stddev_over_time()`函数实现
这样既能识别真实异常，又不会在凌晨低峰期把正常波动当故障。
告警维度要覆盖实例、副本集、节点三层
MongoDB的架构分层决定了告警必须分粒度配置：
- 实例维度：关注整体健康，如磁盘使用率≥90%持续3个采集点，直接触发P0告警
- 副本集维度：聚焦数据同步，重点配Oplog时长、主从延迟、请求命中率（
- 节点维度：定位具体故障点，如某Mongod节点CPU持续>90%或内存OOM，需隔离处理
同一指标在不同层级设不同阈值，避免“一人生病全家吃药”。
