本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
目標群組運作狀態檢查
Application Load Balancer 會定期將請求傳送到已註冊的目標來測試其狀態。這些測試稱為運作狀況檢查。
每個負載平衡器節點只會將請求路由至負載平衡器已啟用可用區域內運作狀態良好的目標。每個負載平衡器節點會使用各目標註冊所屬目標群組的運作狀態檢查設定,檢查該目標的運作狀態。目標註冊後,必須通過一次運作狀態檢查,才算運作狀態良好。每次運作狀態檢查完成後,負載平衡器節點即會關閉其為執行運作狀態檢查而建立的連線。
如果目標群組只包含運作狀態不佳的已註冊目標,負載平衡器會將請求路由至所有這些目標,而不論這些目標的運作狀態為何。這表示如果所有已啟用可用區域中的所有目標同時都未通過運作狀態檢查,則負載平衡器會故障開啟。故障開啟的結果是系統會根據負載平衡演算法,允許流量傳輸到所有已啟用可用區域中的所有目標,無論這些目標的運作狀態為何。
Health 狀態檢查不支援 WebSockets。
運作狀態檢查設定
您需要按下表中的描述為目標群組中的目標設定運作狀態檢查。表中使用的設定名稱是 API 中使用的名稱。負載平衡器會使用指定的連接埠、通訊協定和健全狀況檢查路徑,每HealthCheckIntervalSeconds秒傳送健康狀態檢查要求至每個已註冊的目標。每個運作狀態檢查請求是各自獨立,且在整個間隔內持續保持此結果。目標回應所花的時間不影響下次運作狀態檢查請求的間隔。如果健全狀況檢查超過UnhealthyThresholdCount連續的失敗,負載平衡器會將目標停止服務。當健全狀況檢查超過HealthyThresholdCount連續成功時,負載平衡器會將目標重新啟用。
設定 | 描述 |
---|---|
HealthCheckProtocol |
負載平衡器對目標執行運作狀態檢查時使用的通訊協定。可能的通訊協定是 HTTP 和 HTTPS。預設為 HTTP 通訊協定。 這些通訊協定會使用 HTTP GET 方法,來傳送運作狀態檢查請求。 |
HealthCheckPort |
負載平衡器對目標執行運作狀態檢查時使用的連接埠。預設為使用每個目標從負載平衡器接收流量的連接埠。 |
HealthCheckPath |
目標上運作狀態檢查的目的地。 如果通訊協定版本是 HTTP/1.1 或 HTTP/2,請指定有效的 URI (/path?query)。預設為 /. 如果通訊協定版本是 gRPC,則使用 |
HealthCheckTimeoutSeconds |
以秒為單位的時間量,若目標在此期間內毫無回應即表示運作狀態檢查失敗。範圍介於 2 到 120 秒之間。如果目標類型是 |
HealthCheckIntervalSeconds |
個別目標每次執行運作狀態檢查的大約間隔時間量,以秒為單位。範圍介於 5–300 秒之間。如果目標類型是 |
HealthyThresholdCount |
將運作狀態不佳的目標視為運作狀態良好之前,運作狀態檢查需連續成功的次數。範圍介於 2–10 之間。預設值為 5。 |
UnhealthyThresholdCount |
將目標視為運作狀態不佳之前,運作狀態檢查需連續失敗的次數。範圍介於 2–10 之間。預設為 2。 |
Matcher |
檢查是否收到來自目標的成功回應時所使用的代碼。這些在主控台中稱為成功代碼。 如果通訊協定版本是 HTTP/1.1 或 HTTP/2,則值範圍是 200 到 499。您可以指定多個值 (例如,"200,202") 或值範圍 (例如,"200-299")。預設值為 200。 如果通訊協定版本是 gRPC,則值範圍是 0 到 99。您可以指定多個值 (例如,"0,1") 或值範圍 (例如,"0-5")。預設值為 12。 |
目標運作狀態
在負載平衡器向目標傳送運作狀態檢查請求之前,您必須向目標群組註冊該目標,由接聽程式規則中指定其目標群組,並確保負載平衡器已啟用該目標的可用區域。目標必須通過初次運作狀態檢查,才能從負載平衡器收到請求。在目標通過初次運作狀態檢查後,它的狀態是 Healthy
。
下表說明已註冊目標的運作狀態可能的值。
值 | 描述 |
---|---|
|
負載平衡器正在註冊目標或對目標執行初始運作狀態檢查。 相關原因代碼: |
|
目標的運作狀態良好。 相關原因代碼:無 |
|
目標未回應運作狀態檢查或未通過運作狀態檢查。 相關原因碼: |
|
目標未向目標群組註冊、未在接聽程式規則中使用目標群組、目標位於未啟用的可用區域,或目標處於已停止或已終止狀態。 相關原因碼: |
|
目標正在取消註冊,連接耗盡作業進行中。 相關原因碼: |
|
目標群組的運作狀態檢查已停用。 相關原因碼: |
運作狀態檢查原因代碼
如果目標的狀態是 Healthy
以外的任何值,API 將傳回問題的原因代碼和描述,而且主控台會顯示同樣的描述。開頭為 Elb
的原因代碼源自負載平衡器端,而開頭為 Target
的原因代碼源自目標端。如需運作狀態檢查失敗可能原因的詳細資訊,請參閱 Troubleshooting。
原因代碼 | 描述 |
---|---|
|
初始運作狀態檢查正進行中 |
|
運作狀態檢查由於內部錯誤而失敗 |
|
目標註冊正進行中 |
|
目標取消註冊正進行中 |
|
運作狀態檢查失敗 |
|
運作狀態檢查已停用 |
|
目標處於停止狀態 目標處於終止狀態 目標處於終止或停止狀態 目標處於無效狀態 |
|
IP 地址不能做為目標,因為負載平衡器正在使用它 |
|
目標群組未設定為接收來自負載平衡器的流量 目標位於負載平衡器未啟用的可用區域 |
|
目標未向目標群組註冊 |
|
運作狀態檢查失敗,顯示以下代碼:[code] |
|
請求逾時 |
檢查目標的運作狀態
您可以檢查已向目標群組註冊的各個目標的運作狀態。
使用 AWS CLI 檢查目標的運作狀態
使用 describe-target-health 命令。此命令的輸出包含目標的運作狀態。如果狀態為 Healthy
以外的任何值,則輸出也會包含原因代碼。
接收有關狀態不良目標的電子郵件通知
使用 CloudWatch 警示觸發 Lambda 函數,以傳送有關健康狀態不良目標的詳細資訊。如需 step-by-step 指示,請參閱下列部落格文章:識別負載平衡器運作狀況不良的目標
修改目標群組的運作狀態檢查設定
您可以隨時修改目標群組的運作狀態檢查設定。
使用 AWS CLI 修改目標群組的運作狀態檢查設定
使用 modify-target-group 命令。