應用程式閘道健全狀態探查概觀
Azure 應用程式閘道會監視其後端集區中所有伺服器的健全狀況，並自動停止將流量傳送至它視為狀況不良的任何伺服器。 探查會繼續監視這類狀況不良的伺服器，應用程式閘道會在探查偵測到流量狀況良好時再次開始將流量路由傳送至該伺服器。
預設探查會使用來自相關聯後端設定和其他預設組態的連接埠號碼。 您可以使用自訂探查來設定方式。
探查行為
來源 IP 位址
探查的來源 IP 位址取決於後端伺服器類型：
- 如果後端集區中的伺服器是公用端點，來源位址是應用程式閘道前端公用 IP 位址。
- 如果後端集區的伺服器是私人端點，來源 IP 位址來自應用程式閘道子網路的位址空間。
探查作業
應用程式閘道會在您設定規則後立即啟動探查，方法是與後端設定和後端集區產生關聯 (當然還有接聽程式)。 此圖顯示閘道會獨立探查所有後端集區伺服器。 開始抵達的傳入要求只會傳送到狀況良好的伺服器。 後端伺服器預設會標示為狀況不良，直到收到成功的探查回應為止。
必要的探查是根據後端伺服器和後端設定的唯一組合來決定。 例如，請考慮具有具有兩部伺服器和兩個後端設定之單一後端集區的閘道，每個應用程式閘道都有不同的連接埠號碼。 當這些不同的後端設定使用各自的規則與相同的後端集區相關聯時，應用程式閘道會為每個伺服器建立探查，以及後端設定的組合。 您可以在 [後端健康情況頁面] 上檢視此項目。
而且，所有應用程式閘道執行個體會彼此獨立地探查後端伺服器。
探查間隔
您每個應用程式閘道的執行個體都會套用相同的探查組態。 例如，如果應用程式閘道有兩個執行個體，且探查間隔設定為 20 秒，則這兩個執行個體都會每隔 20 秒傳送健康情況探查一次。
一旦探查偵測到失敗的回應，「狀況不良閾值」的計數器就會設定為關閉，如果連續失敗計數符合設定的臨界值，則會將伺服器標示為狀況不良。 因此，如果您將此狀況不良閾值設定為 2，後續探查會先偵測到此失敗。 然後，應用程式閘道會在連續 2 次失敗探查 [第一次偵測 20 秒 + (2 個連續失敗探查 * 20 秒) 之後，將伺服器標示為狀況不良]。
注意
後端健康情況報告會根據個別探查的重新整理間隔進行更新，且不取決於使用者的要求時間。
預設的健全狀況探查
如果您沒有設定任何自訂探查組態，應用程式閘道就會自動設定預設健全狀況探查。 監視行為是對後端集區中設定的 IP 位址或 FQDN，提出 HTTP GET 要求。 關於預設探查，如果後端 http 設定設為使用 HTTPS，則探查會使用 HTTPS 來測試後端伺服器的健康情況。
例如：您將應用程式閘道設定為使用 A、B 和 C 後端伺服器來接收連接埠 80 上的 HTTP 網路流量。 預設健全狀況監視每 30 秒就會對三部伺服器進行一次測試，每個回應搭配具有 30 秒逾時，以取得狀況良好的 HTTP 回應。 狀況良好的 HTTP 回應具有 200 到 399 之間的 狀態碼 。 在此情況下，健全狀態探查的 HTTP GET 要求看起來像 http://127.0.0.1/。 同時請參閱應用程式閘道中的 HTTP 回應碼。
如果伺服器 A 的預設探查檢查失敗，應用程式閘道會停止將要求轉送到此伺服器。 預設探查仍會繼續每 30 秒檢查一次伺服器 A。 當伺服器 A 成功回應預設健全狀態探查的一個要求時，應用程式閘道會再次開始將要求轉送至伺服器。
預設的健全狀況探查設定
| 探查屬性 | 值 | Description |
|---|---|---|
| 探查 URL | <protocol>://127.0.0.1:<port>/ | 通訊協定和連接埠會繼承探查相關聯的後端 HTTP 設定 |
| 間隔 | 30 | 在傳送下一個健康情況探查之前的等候時間，以秒為單位。 |
| 逾時 | 30 | 應用程式閘道在將探查標示為狀況不良之前等待探查回應的時間，以秒為單位。 如果傳回狀況良好的探查，則對應的後端會立即標示為狀況良好。 |
| 狀況不良臨界值 | 3 | 控管在定期健康情況探查失敗時，應該傳送的探查數目。 在 v1 SKU 中，將會快速連續傳送這些額外的健全狀態探查，以快速判斷後端的健康情況，而不會等待探查間隔。 對於 v2 SKU，健全狀態探查會等待間隔。 連續探查失敗計數到達狀況不良臨界值後，就會將後端伺服器標示為故障。 |
預設探查只會查看 <protocol>://127.0.0.1:<port> 來判斷健全狀態。 如果您需要設定健康情況探查，使其移至自訂 URL 或修改任何其他設定，則必須使用自訂探查。 如需 HTTPS 探查的詳細資訊，請參閱應用程式閘道的 TLS 終止和端對端 TLS 概觀。
自訂的健全狀況探查
自訂探查可讓您更細微地控制健全狀況監視。 使用自訂探查時，您可以設定自訂主機名稱、URL 路徑、探查間隔，以及將後端集區執行個體標示為狀況不良之前可接受的失敗回應次數等。
自訂的健全狀況探查設定
下表提供自訂健全狀況探查的屬性定義。
| 探查屬性 | 描述 |
|---|---|
| Name | 探查的名稱。 此名稱用來識別並參考後端 HTTP 設定中的探查。 |
| 通訊協定 | 用來傳送探查的通訊協定。 這必須符合相關聯後端 HTTP 設定中定義的通訊協定 |
| Host | 伴隨傳送探查的主機名稱。 在 v1 SKU 中，此值只用於探查要求的主機標頭。 在 v2 SKU 中，它會同時作為主機標頭和 SNI 使用 |
| 路徑 | 探查的相對路徑。 有效路徑的開頭為 '/' |
| 連接埠 | 如果已定義，這會當作目的地連接埠。 否則，會使用與其相關聯的 HTTP 設定相同的連接埠。 僅 v2 SKU 中有此屬性 |
| 間隔 | 探查間隔 (秒)。 此值是兩個連續探查之間的時間間隔 |
| 逾時 | 探查逾時 (秒)。 如果在這個逾時期間內未收到有效的回應，則會將探查標示為失敗 |
| 狀況不良臨界值 | 探查重試計數。 連續探查失敗計數到達狀況不良臨界值後，就會將後端伺服器標示為故障 |
探查比對
根據預設，狀態碼介於 200 和 399 之間的 HTTP(S) 回應視為良好。 自訂的健全狀況探查額外支援兩個比對準則。 比對準則可用來選擇性修改何謂良好回應的預設解讀。
以下為比對準則：
- HTTP 回應狀態碼比對：探查比對準則，以接受使用者指定的 HTTP 回應碼或回應碼範圍。 支援以逗號分隔的個別回應狀態碼或一個狀態碼範圍。
- HTTP 回應主體比對：探查比對準則，其會查看 HTTP 回應主體並與使用者指定的字串進行比對。 這項比對只在回應本文中尋找有無使用者指定的字串，並不是完整的規則運算式比對。 指定比對長度必須等於或小於 4090 個字元。
比對準則是使用 New-AzApplicationGatewayProbeHealthResponseMatch Cmdlet 來指定的。
例如：
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
比對比對準則就可使用 PowerShell 中的 -Match 運算子，將它附加至探查設定。
部分自訂探查的使用案例
- 如果後端伺服器只允許存取已驗證的使用者，則應用程式閘道探查會收到 403 回應碼，而不是 200。 當用戶端 (使用者) 繫為即時流量進行驗證時，您可以將探查流量設定為接受 403 作為預期的回應。
- 當後端伺服器已安裝通配符憑證 (*.contoso.com) 來提供不同的子網域時，您可以使用自訂探查搭配特定主機名 (SNI 的必要名稱)，以建立成功的 TLS 探查，並將該伺服器報告為狀況良好。 在 [後端設定] 中將 [覆寫主機名] 設定為 [否] 時，會將不同的傳入主機名 (子網域) 傳遞至後端。
NSG 考量
在公開預覽中，可以透過 NSG 規則對應用程式應用程式閘道子網路進行更細微的控制。 在 這裡可以找到更多詳細資訊。
使用目前的功能有一些限制：
針對應用程式閘道 v1 SKU 的 TCP 通訊埠 65503-65534，以及 v2 SKU 的 TCP 通訊埠 65200-65535，您必須允許目的地子網路為 Any 且來源為 GatewayManager 服務標記的連入網際網路流量。 Azure 基礎結構通訊需要此連接埠範圍。
此外，不可封鎖輸出網際網路連線，且必須允許來自 AzureLoadBalancer 標記的輸入流量。
如需詳細資訊，請參閱應用程式閘道設定概觀。
下一步
在了解應用程式閘道的健全狀態監視之後，您可以在 Azure 入口網站中自訂健全狀態探查，或使用 PowerShell 和 Azure Resource Manager 部署模型設定自訂健全狀態探查。