如何對運作狀態檢查失敗的 Application Load Balancer 進行疑難排解？

解決方法

若要對運作狀態檢查失敗的 Application Load Balancer 進行疑難排解，請找到問題的原因代碼和說明。然後，完成下列任務以解決您的問題。

找到問題的原因代碼和描述

使用資源映射而不是目標群組的主控台來檢視負載平衡器的資源並識別運作狀態不佳的目標。資源映射會在單一頁面上顯示 Application Load Balancer 的所有資源。

**注意：**如果 Application Load Balancer 的目標 HTTP 回應不是預期的回應，請檢查應用程式的回應。確定應用程式傳送正確的回應給負載平衡器。

根據原因代碼解決問題

根據您找到的運作狀態檢查原因代碼，完成下列任務以解決問題。

Elb.InitialHealthChecking

目標必須通過初始運作狀態檢查，才可從負載平衡器收到請求。等待目標通過初始運作狀態檢查，然後重新檢查其運作狀態。

Elb.RegistrationInProgress

一旦完成註冊程序且目標通過初始運作狀態檢查後，負載平衡器就會立即開始將請求路由至目標。

Target.DeregistrationInProgress

在取消註冊目標後，負載平衡器不再將請求傳送給目標。Elastic Load Balancing 會在完成取消註冊前等待 300 秒。不過，您可以使用 Amazon EC2 主控台或 AWS Command Line Interface (AWS CLI) 來更新延遲值。如需詳細資訊，請參閱取消註冊延遲。

**注意：**如果您在執行 AWS CLI 命令時收到錯誤，請參閱對 AWS CLI 錯誤進行疑難排解。此外，請確定您使用的是最新的 AWS CLI 版本。

Target.FailedHealthChecks

若要解決此問題，請完成下列任務：

• 確認您的應用程式正在執行。執行 service 命令以檢查 Linux 目標上的服務狀態。對於 Windows 目標，檢查 Windows 工作管理員的服務索引標籤。如果服務已停止，則啟動服務。如果無法辨識服務，請檢查是否已安裝該服務。

• 確認目標正在偵聽運作狀態檢查連接埠上的流量。您可以在 Linux 目標上執行 ss 命令，以驗證伺服器正在偵聽的連接埠。對於 Windows 目標，可以執行 netstat 命令。

• 在與目標執行個體相同的 Amazon 虛擬私有雲端 (VPC) 中啟動或使用現有執行個體。請確定您可以存取此執行個體。或者，如果目標可公開存取，請將運作狀態檢查請求直接傳送到目標的公用 IP 位址。

  使用下列 CURL 命令：

  $curl -vkso /dev/null <HealthCheck_protocol>://<Target_IP>:<HealthCheck_port>/<HealthCheck_path>

  **注意：**使用此方法可繞過 Application Load Balancer，並驗證目標是否正確回應負載平衡器的運作狀態檢查要求。

• 驗證應用程式是否回應負載平衡器的運作狀態檢查要求。以下範例顯示來自 Application Load Balancer 的典型運作狀態檢查請求，您的目標必須以有效的 HTTP 回應對其做出回應：

  GET / HTTP/1.1Host: 10.0.0.1:80
  Connection: close
  User-Agent: ELB-HealthChecker/2.0
  Accept-Encoding: gzip, compressed

  **注意：**在上面的範例中，主機標頭值包含目標的私有 IP 地址，後面接著運作狀態檢查連接埠。User-agent 設定為 ELB-HealthChecker/2.0。訊息標頭字段的行結束字元為序列 CRLF，標頭在第一個空行後接 CRLF 終止。若要接收運作狀態檢查請求，可能需要將預設虛擬主機新增至您的 Web 伺服器組態。

• 如果您的目標已連接多個介面，請確認您的應用程式正在偵聽正確的網路介面。如需詳細資訊，請參閱目標類型。

• 確認目標以 Elastic Load Balancing 安全政策中指定的格式提供伺服器憑證和金鑰。此外，請檢查目標是否支援符合的密碼和負載平衡器提供的通訊協定來建立 TLS 握手。

Target.InvalidState

如果目標是 Amazon EC2 執行個體，請使用 Amazon EC2 主控台驗證執行個體是否正在執行。如果執行個體未執行，則手動啟動執行個體。

Target.IpUnusable

如果您的目標類型是 ip，則不要選擇負載平衡器已使用的 IP 位址。

Target.NotInUse

若要解決此問題，請完成下列任務：

• 檢查目標群組，以驗證是否設定為接收來自負載平衡器的流量。
• 確定目標的可用區域已針對負載平衡器開啟。

Target.NotRegistered

確定目標已註冊至目標群組。

Target.ResponseCodeMismatch

若要解決此問題，請完成下列任務：

• 檢閱運作狀態檢查組態，以驗證負載平衡器預期接收的成功代碼。依預設，成功代碼為 200，但您可以指定介於 200 到 499 之間的值。檢閱您的 Web 伺服器存取日誌，以查看是否傳回預期的成功代碼。
• 確認 Ping 路徑有效。請務必指定有效的 URI。預設值為 /。

若要變更成功代碼值或 Ping 路徑，請參閱修改目標群組的運作狀態檢查設定。

Target.Timeout

如果可以連線，則在運作狀態檢查逾時之前，目標頁面可能沒有回應。大多數 Web 伺服器 (例如 NGINX 和 IIS) 支援日誌伺服器回應所需的時間。如需詳細資訊，請參閱 NGINX 網站上的設定日誌記錄和 Microsoft 網站上的在 IIS 中設定日誌記錄。

如果您的運作狀態檢查要求的時間超過設定的逾時，請完成下列任務：

• 為運作狀態檢查選擇較簡單的目標頁面。
• 修改運作狀態檢查設定。

如果無法連線，請完成下列任務：

• 使用運作狀態檢查連接埠和運作狀態檢查通訊協定確認與目標相關聯的安全群組允許來自負載平衡器的流量。您可以將規則新增至安全群組，以允許來自負載平衡器安全群組的所有流量。此外，負載平衡器的安全群組必須允許傳入目標的流量。
• 確認與目標子網路關聯的網路存取控制清單 (network ACL) 允許運作狀態檢查連接埠上的傳入流量。網路 ACL 還必須允許暫時性連接埠 (1024-65535) 上的傳出流量。
• 驗證與節點子網路相關聯的網路 ACL 是否允許暫時性連接埠上的傳入流量。網路 ACL 還必須允許運作狀態檢查和暫時性連接埠上的傳出流量。
• 檢查目標上的作業系統級防火牆是否允許運作狀態檢查流量傳入和傳出。
• 驗證與目標子網路的路由表是否包含允許運作狀態檢查流量傳回負載平衡器的項目。
• 確認目標的記憶體和 CPU 使用率在可接受的容量範圍內。如果您的記憶體或 CPU 使用率過高，請新增目標或增加 Auto Scaling 群組的容量。如果您的目標是 EC2 執行個體，則將執行個體變更為較大的執行個體類型。

相關資訊

對 Application Load Balancer 進行疑難排解