异地多活心跳监控核心是判断链路能否支撑业务连续接管，需融合网络层（icmp/udp探针）、应用层（/health端点带同步位点）和存储层（仲裁盘或跨kafka写marker）三模态探测，并绑定source_unit_id与target_unit_id实现单元级精准判定，结合动态基线模型与数据同步状态深度耦合，触发rto＜15秒的智能流量切换。

异地多活机房之间的心跳链路监控，核心目标不是简单“通不通”，而是判断“能否支撑业务连续接管”——即链路是否具备低延迟、高可靠、可区分故障类型的能力。它必须和容灾决策联动，不能只报“断了”，而要回答“断到什么程度、影响哪些单元、要不要切流量”。

多模态心跳链路并行探测

单一通道易误判，需组合使用三种物理/逻辑路径，彼此验证：

• 网络层心跳：基于专线或 SD-WAN 隧道，用 ICMP 或定制 UDP 探针（带时间戳与序列号），每 500ms 发一次，连续 3 次超时（阈值设为 200ms）才触发弱告警；超时达 5 次且伴随丢包率＞30%，升级为“链路劣化”事件
• 应用层心跳：调用各机房网关暴露的轻量健康端点（如 /health?scope=sync），携带本单元当前数据同步位点（GTID 或 binlog position），验证不仅连通，还能感知数据追平状态
• 存储层心跳：通过共享存储仲裁盘（如 DRBD 仲裁节点）或跨机房写入最小日志块（如向两地 Kafka 同时发 marker 消息），检测存储面连通性与写入能力

心跳结果需绑定单元上下文

异地多活是按单元（Unit）运作的，心跳不能只看“机房A ↔ 机房B”，而要细化到“北京单元U1 ↔ 上海单元U2”“北京单元U1 ↔ 深圳单元U3”。每个心跳探针都应携带 source_unit_id 和 target_unit_id 标签，并在监控系统中构建单元拓扑图。当某条单元间链路异常时，调度系统可精准屏蔽该对单元间的跨域调用，而非粗暴切走整个机房流量。

智能判定代替阈值硬切换

传统“3次失败就切”的策略在异地场景下极易误切。建议引入动态基线模型：

• 持续采集历史 RTT 分布（P50/P90/P99），自动学习正常波动区间
• 当当前延迟超过 P99 + 2×标准差，且持续 30 秒，标记为“延迟突增”
• 若同时出现应用层心跳返回 503（同步组件不可用）+ 存储层写入超时，则触发 RTO＜15 秒的自动流量切换流程
• 所有判定过程留痕，生成可追溯的决策日志（含原始探针数据、计算依据、关联单元状态）

与数据同步状态深度耦合

心跳本身不解决数据一致性，但必须反映一致性风险。例如：

• MySQL MGR 场景下，心跳探针应附带查询 SELECT MEMBER_STATE FROM performance_schema.replication_group_members，若某节点状态非 ONLINE，则即使网络通畅，也视为该单元不可用
• Canal 同步场景中，心跳服务主动读取 Canal server 的 lag 指标（如 canal_client_lag_seconds），若 lag ＞ 5 秒且持续 1 分钟，同步链路心跳降级为“警告”
• ES 跨集群复制（CCR）中，心跳需调用 _ccr/stats API，检查 auto_follow_patterns 是否生效、follower indices 是否处于 syncing 状态