健康情況探查

重要

Azure Front Door (傳統) 將於 2027 年 3 月 31 日遭到淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前，將 Azure Front Door (傳統) 設定檔移轉至 Azure Front Door 標準或進階層。 如需詳細資訊，請參閱 Azure Front Door (傳統版) 淘汰。

注意

本文中的原點和原點群組是指 Azure Front Door (傳統) 設定的後端和後端集區。

為了判斷特定 Azure Front Door 環境的每個原點的健康情況和鄰近性，每個 Front Door 環境會定期將綜合 HTTP/HTTPS 要求傳送至您設定的所有原點。 Front Door 接著會使用這些來自健全狀態探查的回應，決定最佳原點來路由傳送用戶端要求。

警告

由於每個 Azure Front Door 邊緣位置都會將健康情況探查傳送至您的來源，因此來源的健康情況探查量可能很高。 探查數目取決於客戶的流量位置和健全狀態探查頻率。 如果 Azure Front Door 邊緣位置未收到來自用戶的實際流量，則邊緣位置的健康情況探查頻率會從設定的頻率降低。 如果有流量流向所有 Azure Front Door 邊緣位置，則健康情況探查量可能會根據您的健康情況探查頻率而很高。

舉例來說，使用預設探查頻率為 30 秒時，粗略估計對您原點的每分鐘健全狀態探查數量。 每個原點上的探查數量等於邊緣位置數目乘以每分鐘兩個要求。 如果沒有任何流量傳送到所有邊緣位置，探查要求會比較少。 如需邊緣位置清單，請參閱依區域的邊緣位置。

支援的通訊協定

Azure Front Door 支援透過 HTTP 或 HTTPS 通訊協定傳送探查。 這些探查透過設定用於路由傳送用戶端要求的相同 TCP 連接埠傳送，並且無法覆寫。 Front Door HTTP/HTTPS 探查會以具有以下值的 User-Agent 標頭集傳送：Edge Health Probe。

健全狀態探查支援的 HTTP 方法

Azure Front Door 支援下列 HTTP 方法來傳送健全狀態探查：

1. GET：GET 方法表示無論擷取任何資訊 (實體形式) 都會由要求-URI 識別。
2. HEAD：HEAD 方法等同於 GET，不同之處在於伺服器不得在回應中傳回訊息本文。 對於新的 Front Door 設定檔，探查方法會預設為 HEAD。

提示

為了降低原點的負載和成本，Front Door 建議針對健全狀態探查使用 HEAD 要求。

健全狀態探查回應

回覆	描述
判斷健康情況	200 OK 狀態碼表示原點狀況良好。 任何其他狀態碼都會被視為失敗。 如果基於任何原因未收到有效的 HTTP 探查回應，則探查將會視為失敗。
測量延遲	延遲是從目前傳送探查要求的那一刻起，到 Front Door 收到回應的最後一個位元組之前測量的時鐘時間。 Front Door 會針對每個要求使用新的 TCP 連線。 測量不會偏向具有現有暖連線的原點。

Front Door 如何判斷原點健康情況

Azure Front Door 在所有演算法之間使用三步驟程序來判斷健康情況。

1. 排除已停用原點。

2. 排除有健康情況探查錯誤的原點：

   • 藉由查看最後 n 個健全狀況探查回應來完成此選取。 如果至少 x 狀況良好，則原點會視為狀況良好。

   • 透過變更負載平衡設定中的 SampleSize 屬性來設定 n。

   • 透過變更負載平衡設定中的 SuccessfulSamplesRequired 屬性來設定 x。

3. 針對原點群組中狀況良好的原點集合，Front Door 會測量並維護每個原點的延遲。

注意

如果單一端點是多個原始群組的成員，Front Door 會將傳送至來源的健康情況探查數目優化，以減少來源上的負載。 健康情況探查要求會根據最低設定的取樣間隔來傳送。 來自相同健康狀態探查的回應會決定所有來源群組中端點的健康情況。

調整長時間啟動容器的探查設定

當您處理長時間啟動的容器時，調整探查設定可能會防止過早失敗。 增加 和 Interval 值可讓您的ProbeTimeout容器有更多時間在 Front Door 將容器標示為狀況不良之前啟動。

長時間啟動容器的值

• ProbeTimeout：將逾時期間增加到 10-30 秒。
• 間隔：在探查之間設定較長的間隔（例如 30-60 秒）。
• UnhealthyThreshold：在容器被視為狀況不良之前增加連續失敗的探查數目（例如 3-5 次重試）。

注意

提供給 ProbeTimeout、 Interval和 UnhealthyThreshold 的值是範例用途的範例範圍。 您可以根據特定容器的啟動行為和需求來調整這些值。

注意

這些變更可能會導致偵測實際失敗的延遲，因此請根據容器的啟動行為仔細平衡這些值。

在容器生命週期階段期間探查互動

1. 容器啟動階段：在此階段中，容器可能無法完全準備好提供流量。 健康情況探查可藉由檢查特定 HTTP 狀態代碼來協助偵測容器何時沒有回應（例如 ， 200 OK。 如果探查頻率太高或逾時太短，容器會在初始化之前標示為狀況不良。 在此階段增加探查逾時或間隔。

2. 執行階段：容器執行后，探查會繼續檢查健康情況回應。 如果健康情況檢查一致傳回 200 OK，Front Door 會保留流量的輪替原點。 如果探查持續失敗（例如，因為容器當機），Front Door 會將來源標示為狀況不良。

3. 失敗階段：如果已設定閾值的健康情況探查失敗（例如 UnhealthyThreshold），來源會被視為狀況不良，且流量會路由傳送至其他狀況良好的來源。

完整的健全狀況探查失敗

如果原點群組中每個原點的健全狀況探查失敗，那麼 Front Door 會將所有原點視為狀況不良，並在所有原點的循環配置資源散發中路由傳送流量。

一旦任何原點恢復狀況良好狀態，Front Door 就會繼續正常負載平衡演算法。

停用健全狀態探查

如果原點群組中有單一原點，您可以選擇停用健全狀態探查，以減少應用程式的負載。 如果原點群組中有多個原點，且有一個以上的原點處於啟用狀態，您無法停用健全狀態探查。

注意

如果原始群組中只有單一原始來源，則單一原始來源會取得一些健康情況探查。 這可能會導致原始健康情況計量下降，但您的流量不會受到影響。

下一步

• 了解如何建立 Azure Front Door 設定檔。
• 了解 Front Door 路由傳送結構。