将多个健康监视器组合在一起，为应用创建复杂的健康检查，确保更智能、更具弹性的流量导向。
您可以将多个健康监视器分组，构建更复杂地反映应用真实健康状态的健康检查。监视器组允许您组合多个独立的监视器，定义聚合逻辑，并使用集体结果来确定源站池的健康状态。
分组多个健康监视器可实现更智能、更具弹性的故障转移。例如，您可以要求通用 API 网关监视器和特定登录服务监视器都必须健康，池才能接收流量。
监视器组仅适用于拥有 Load Balancing 订阅的 Enterprise 套餐客户。
配置仅通过 API 提供。
当您将监视器组附加到池时，该池的健康状态由聚合组内所有已启用监视器的结果决定。
以下各节说明监视器组如何影响健康状态、延迟和结果处理。
监视器组使用关键监视器覆盖和基于法定人数（quorum）的共识组合来确定端点的健康状态。
关键监视器覆盖（must_be_healthy）：您可以通过设置 "must_be_healthy": true 将监视器指定为关键。如果具有此设置的监视器对端点的健康检查失败，该特定端点会立即被标记为不健康。无论组内其他监视器对同一端点报告的状态如何，都会发生这种情况。这为基本服务提供了明确的覆盖。
基于法定人数的健康状态：在没有 must_be_healthy 监视器失败的情况下，端点的健康状态由所有其他活动监视器的法定人数决定。
- 仅当超过 50% 的已分配监视器报告端点为不健康时，端点才被视为不健康。
- 标记为
"monitoring_only": true的监视器不包含在法定人数计算中。它们仍会运行并可以触发通知，但不参与端点健康状态的投票。 - 标记为
disabled的监视器不会向任何关联池发送监控请求。它们也不包含在法定人数计算中。
此法定人数系统可防止端点因单个非关键监视器的瞬时故障而过早被标记为不健康。
对于使用动态导向的池，池的延迟计算为其所有已启用、非仅监视（monitoring-only）监视器的平均延迟。此聚合 RTT（往返时间）值提供了源站性能的整体视图，并用于做出流量导向决策。
如果组内监视器具有不同的检查间隔，组会使用每个监视器的上次可用结果，直到其刷新。例如，如果一个监视器每 10 秒运行一次，另一个每 30 秒运行一次，30 秒监视器的结果在下次运行完成前的完整 30 秒内被视为有效。