告警需按实例/副本集/节点三级拆分：实例维度只放磁盘使用率等全局指标；副本集关注oplog时长；节点盯cpu、内存等资源；所有阈值告警须设持续条件；通知按严重等级分流；收敛规则需手动配置并文档化。
告警维度必须按实例/副本集/节点三级拆分
直接在“实例”维度堆所有指标，会导致关键问题被淹没。比如磁盘使用率超 90% 是实例级硬性风险，但主从延迟 5 秒只发生在某个副本集的 secondary 节点上——后者在实例维度根本不可见。
实操建议：
- 实例维度只放全局性命脉指标：
磁盘使用率、连接数使用率、写入请求失败率 - 副本集维度专注数据一致性与缓存健康：
Oplog 保存时长（建议阈值 Cache 命中率（低于 85% 触发警告）、主从延迟（>5s 警告，>30s 严重） - 节点维度盯住资源瓶颈：
CPU 使用率（>90% 持续 3 分钟）、内存使用率（>92%）、mongos 队列等待数（>100 表示路由层积压）
抖动过滤必须显式配置持续时间与数据点数
默认告警规则常忽略“瞬时毛刺”和“真实恶化”的区别。比如 单位时间延迟次数(100ms以上) 突然跳到 120 次，但 20 秒后回落——这大概率是单次慢聚合，不值得触发通知。
实操建议：
- 所有阈值类告警必须设置「持续条件」：例如
统计周期=1分钟，且异常持续≥3个数据点（即连续 3 分钟达标才告警） - 避免用“单点超限即告警”，尤其对
读取请求次数、更新请求次数这类天然波动大的指标 - 对
Oplog 主从延迟这类敏感指标，可放宽为“>30s 持续 2 分钟”，防止网络抖动误报
通知渠道要绑定严重等级而非统一推送
把所有告警都扔进企业微信群，等于没有告警。真正的问题不是“没收到”，而是“收到太多而忽略关键信号”。
实操建议：
- 轻微异常（如
Cache 使用率 > 85%）：仅写入监控平台 + 每日汇总邮件 - 严重异常（如
磁盘使用率 >= 90%或副本集无主）：企业微信 @值班人 + 邮件，要求 15 分钟内确认 - 致命异常（如
实例被锁定、mongos 进程退出）：立即电话呼出 + 短信双通道，且未确认自动升级至 on-call 组长 - 禁用“全部告警发短信”——运营商限制、费用高、易被拦截，只留给 P0 级别
告警收敛规则不能依赖平台默认配置
云厂商控制台里勾选“自动聚合相同类型告警”，实际效果很弱。比如同一副本集连续触发 主从延迟 和 Oplog 保存时长不足，系统不会自动合并——它认为这是两个独立指标。
实操建议：
- 手动建立抑制关系：当
副本集无主告警激活时，自动屏蔽该副本集下所有主从延迟、Oplog 保存时长告警 - 对分片集群，设置“某分片
磁盘使用率 >= 95%”时，抑制该分片所有节点的CPU、内存告警（因磁盘满会导致进程卡死，CPU/内存异常是结果而非原因） - 所有收敛规则必须写进文档，并标注触发条件与失效时间（如“抑制规则在无主状态恢复后 5 分钟自动解除”）
count 请求次数 突增 300%，可能是大促，也可能是误配的全表扫描；这时候需要关联 Profiler configured to capture all operations 是否开启，而不是单纯看数字。这类上下文判断没法自动化，必须靠文档明确写死。
