複数のヘルスモニターをまとめて、アプリケーション向けの高度なヘルスチェックを作り、より的確で耐障害性の高いトラフィックステアリングにします。
複数のヘルスモニターをグループ化すると、アプリケーションの実際の健全性をより正確に反映するヘルスチェックを構築できます。Monitor Group では、独立した複数のモニターを組み合わせ、集約ロジックを定義し、その結果でオリジンプールの健全性を判定します。
複数のヘルスモニターをグループ化すると、より的確で耐障害性の高いフェイルオーバーが可能です。たとえば、一般的な API ゲートウェイのモニターと、特定のログインサービスのモニターの両方が健全なときだけ、そのプールにトラフィックを送る、といった要件を設定できます。
Monitor Groups は、Load Balancing サブスクリプション付きの Enterprise プランのお客様だけが利用できます。
設定は API のみです。
Monitor Group をプールに付けると、そのプールの健全性は、グループ内の有効な全モニターの結果を集約して決まります。
以降の節では、Monitor Group が健全性ステータス、レイテンシ、結果の扱いにどう影響するかを説明します。
Monitor Group は、クリティカルモニターによる上書きと、定足数（quorum）に基づく合意を組み合わせて、エンドポイントの健全性を判定します。
Critical Monitor Override（must_be_healthy）: "must_be_healthy": true を設定すると、そのモニターをクリティカルにできます。この設定のモニターがエンドポイントへのヘルスチェックに失敗すると、そのエンドポイントはすぐに unhealthy になります。同じエンドポイントについて、グループ内のほかのモニターが報告するステータスは問いません。必須サービスに対する確定的な上書きです。
定足数に基づく健全性: must_be_healthy モニターの失敗がない場合、エンドポイントの健全性は、ほかのアクティブなモニターの定足数で決まります。
- エンドポイントが unhealthy になるのは、割り当てられたモニターの 50% 超が unhealthy と報告した場合だけです。
"monitoring_only": trueのモニターは定足数の計算から除外されます。実行と通知のトリガーは行いますが、エンドポイントの健全性ステータスには投票しません。disabledのモニターは、関連するどのプールにも監視リクエストを送りません。定足数の計算からも除外されます。
この定足数の仕組みにより、クリティカルではない 1 つのモニターの一時的な失敗だけで、エンドポイントがすぐに unhealthy になるのを防ぎます。
Dynamic Steering を使うプールでは、プールのレイテンシは、有効かつ monitoring-only ではない全モニターのレイテンシの平均です。この集約した RTT（Round Trip Time）は、オリジン性能をより包括的に示し、ステアリングの判断に使われます。
グループ内のモニターのチェック間隔が異なる場合、グループは各モニターの最新結果を、更新されるまで使います。たとえば、あるモニターが 10 秒ごと、別のモニターが 30 秒ごとの場合、30 秒間隔のモニターの結果は、次の実行が完了するまでの 30 秒間、有効と見なされます。