503 Service Unavailable - NoActiveTargets - HealthCheckFailures

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊

影片

如要進一步瞭解 503 錯誤，請觀看以下影片：

影片 說明
疑難排解並解決 503 服務無法使用 - NoActiveTargets 瞭解下列資訊：
  • 目標伺服器和狀態監控器的重要性
  • 即時疑難排解並解決即時 503 Service Unavailable - 健康狀態檢查失敗導致的 NoActiveTargets 錯誤

問題

用戶端應用程式收到 HTTP 回應狀態碼 503，訊息中會顯示「Service Unavailable」訊息，以及 API Proxy 要求的錯誤代碼 NoActiveTargets。

錯誤訊息

系統會顯示以下錯誤回應：

HTTP/1.1 503 Service Unavailable

HTTP 回應中會顯示以下錯誤訊息：

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}

可能原因

當您在 API Proxy 的目標端點設定中使用一或多個目標伺服器時，系統通常會觀察到 HTTP 回應 503 Service Unavailable 和錯誤代碼 NoActiveTargets。

本教戰手冊涵蓋因健康狀態檢查失敗而造成的 503 Service Unavailable 錯誤代碼 NoActiveTargets。如要瞭解這個錯誤的其他原因，請參閱這份教戰手冊。

健康狀態檢查失敗

您必須在 API Proxy 的目標端點中將 健康狀態檢查設為目標伺服器負載平衡設定，系統才會觀察健康狀態檢查失敗的情況。

當目標伺服器未通過健康狀態檢查時，Edge 就會增加該伺服器的失敗次數。如果該伺服器的健康狀態檢查失敗次數達到預先定義的門檻 (<MaxFailures>)，訊息處理器就會將警告訊息記錄在記錄檔中，如下所示：

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

警告訊息會提供以下資訊。這有助您瞭解已達 MaxFailure 數量的目標伺服器：

  • 目標伺服器名稱
  • 機構和環境名稱
  • API Proxy 名稱
  • 目標端點名稱

之後，Edge 會停止將其他要求傳送至該特定伺服器。在 LoadBalancer 設定中設定的所有目標伺服器達到 MaxFailure 數量後，後續的 API 要求就會以 503 Service Unavailable 回應，並傳回錯誤代碼 NoActiveTargets.。

使用健康監控工具可讓 Apigee Edge 在健康狀態良好的時，自動將目標伺服器納入輪替作業，而不需重新部署 API Proxy。

以下是健康狀態檢查失敗的可能原因：

原因 說明 誰可以執行疑難排解步驟
連線逾時錯誤 訊息處理器無法在 LoadBalancer 設定中的指定逾時期間內，連線至目標伺服器。 Edge Private Cloud 使用者
透過非安全通訊埠傳送安全要求
  1. 如果目標伺服器定義為安全的伺服器，但未採用不安全的通訊埠設定。
  2. 如果目標伺服器定義為安全的伺服器，但健康狀態監控器設為對不安全的通訊埠執行健康狀態檢查，
 Edge Private Cloud 使用者
安全通訊埠的不安全要求
  1. 如果目標伺服器定義為不安全的伺服器，但採用安全通訊埠的錯誤設定，
  2. 如果目標伺服器定義為不安全的伺服器，但健康狀態監控器已設為在安全的通訊埠執行健康狀態檢查，
 Edge Private Cloud 使用者
Health Check API 回應並顯示錯誤 如果健康狀態檢查 API 回應包含錯誤或回應代碼，則除了 Health Monitor 的 SuccessResponse 元素中指定的其他任何內容， Edge Private Cloud 使用者

常見診斷步驟

判斷失敗要求的郵件 ID

追蹤工具

如何使用追蹤工具判斷失敗要求的郵件 ID：

  1. 啟用追蹤工作階段，發出 API 呼叫並重現問題：503 Service Unavailable 並傳回錯誤代碼 NoActiveTargets。
  2. 請選取其中一個失敗的要求。
  3. 前往 AX 階段，在「階段詳細資料」部分向下捲動，判斷要求的訊息 ID (X-Apigee.Message-ID)，如下圖所示。

    「階段詳細資料」部分中的郵件 ID

NGINX 存取記錄檔

如何使用 NGINX 存取記錄判斷失敗要求的郵件 ID：

您也可以參閱 NGINX 存取記錄，判斷 503 錯誤的郵件 ID。如果問題過去發生，或是問題間歇發生，而且您無法在 UI 中擷取追蹤記錄，這個方法就特別實用。請按照下列步驟，從 NGINX 存取記錄確認這項資訊：

  1. 查看 NGINX 存取記錄檔：(/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. 搜尋特定 API Proxy 是否在特定時間範圍內 (如果問題在過去) 出現 503 錯誤，或是是否有任何要求仍失敗並顯示 503 錯誤。
  3. 如果 X-Apigee-fault-codeMessaging.adaptors.http.flow.NoActiveTargets 出現任何 503 錯誤，請注意一或多個這類要求的訊息 ID，如以下範例所示：

    顯示 503 錯誤的範例項目

    顯示狀態碼、訊息 ID、錯誤來源和故障代碼的示例項目

常見錯誤訊息

如果使用目標伺服器，且訊息處理器嘗試與後端伺服器連線時發生錯誤，您會在訊息處理器記錄檔中看到一些常見的錯誤訊息。在實際導致失敗的例外狀況/錯誤訊息結束後，系統會記錄這類錯誤。

在 503 Service Unavailable 中，出現錯誤代碼 NoActiveTargets 的訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中常見的錯誤訊息如下：

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

這些錯誤訊息表示要求因失敗而無法傳送至後端伺服器。因此，訊息處理器會傳送 503 Service Unavailable，以及錯誤代碼 NoActiveTargets 做為回應用戶端。

原因：連線逾時

診斷

  1. 判斷失敗要求的訊息 ID。
  2. 在郵件處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 ID。
  3. 您會看到與訊息 ID 相對應的常見錯誤訊息。不過，如要取得健康狀態檢查失敗的實際原因，請捲動至這些常見錯誤訊息上方，並檢查是否有任何健康監控錯誤。

    舉例來說，下列 HEALTH MONITOR 錯誤訊息指出「訊息處理器」在提出健康狀態檢查 API 要求時，發生連線逾時錯誤：

    Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
java.net.ConnectException: Connection timed out (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
…<snipped>

    如果這項錯誤在狀態監控器中設定的 MaxFailure 次數重複，您會看到如下的警告訊息：

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

    請詳閱警告訊息中提供的資訊。確認您在收到 503 回應代碼 (錯誤代碼為 NoActiveTargets) 時，在特定 API Proxy 中使用的目標伺服器已達 MaxFailure 數量。

  4. 在上述範例中，健康狀態檢查失敗，並出現 connection timed out 錯誤。使用 telnet 指令確認是否能從各個訊息處理器直接連線至特定後端伺服器：
    5. telnet <BackendServer-HostName> 443
  5. 如果您可以連線至後端伺服器，您可能會看到類似「已連線至後端伺服器」的訊息。那麼，這可能是暫時性問題，也可能是已解決或間歇性問題。重複步驟 4 數次 (10 次以上)，並驗證輸出結果。
    1. 如果 telnet 指令沒有持續發生錯誤，就表示問題已解決。重新檢查失敗的健康狀態檢查是否已停止。如果是，就不必採取進一步行動。
    2. 如果無法使用 telnet 指令連線至後端伺服器，可能是網路問題或後端伺服器忙碌中。
  6. 如果您無法持續使用 telnet 指令連線至後端伺服器，可能是因為特定後端伺服器上的訊息處理器不允許流量。

解析度

如果持續觀察到 connection timed out 錯誤，請確認後端伺服器沒有任何防火牆限制，並允許來自 Apigee Edge 訊息處理器的流量。例如在 Linux 上，您可以使用 iptables，允許來自訊息處理器在後端伺服器上 IP 位址的流量。

如果問題持續發生，請與網路管理員聯絡，找出並修正問題。 如需 Apigee 的進一步協助，請與 Apigee 支援團隊聯絡。

原因：透過不安全的通訊埠確保要求安全

診斷

  1. 判斷失敗要求的訊息 ID。
  2. 在郵件處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 ID。
  3. 您會看到與郵件 ID 相對應的常見錯誤訊息。 不過，如要取得健康狀態檢查失敗的實際原因，請捲動至這些常見錯誤訊息上方，並檢查是否有任何「健康監控錯誤」。

    例如，您可能會看到以下「HEALTH MONITOR」錯誤：

    Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
        at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
        at sun.security.ssl.InputRecord.read(InputRecord.java:527)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
…<snipped>

    如果這項錯誤在狀態監控器中設定的 MaxFailure 次重複，您會看到以下警告訊息：

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

    請詳閱警告訊息中提供的資訊。確認您在收到 503 回應代碼 (錯誤代碼為 NoActiveTargets) 時，在特定 API Proxy 中使用的目標伺服器已達 MaxFailure 數量。

  4. 健康狀態檢查失敗，並出現以下錯誤： 
    Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

    錯誤訊息和網址指出造成這個問題的原因，是您已透過不安全的通訊埠 80 發出安全呼叫 (HTTPS)。

    以下兩種情況可能會發生這個錯誤：

    • 以不安全的通訊埠定義的安全目標伺服器
    • 已定義安全目標伺服器，但狀態監控器設定了不安全的通訊埠

    安全目標非安全通訊埠

    情境 1：以不安全的通訊埠定義的安全目標伺服器

    如果您已定義安全目標伺服器，但使用不安全的通訊埠 (例如 80)，就會收到這個錯誤。請按照下列步驟確認這個問題是否為原因：

    1. 檢查目標端點設定所用目標伺服器的定義。

      2. 使用 取得 TargetServer API 取得目標伺服器定義。

      目標伺服器定義輸出內容

      <TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>

      在上述範例中，定義顯示目標伺服器 mocktarget 是 SSLInfo 區塊指出的安全伺服器。但是設定為使用不安全的通訊埠 80。

    2. 現在，檢查目標端點設定中目標伺服器的 Health Monitor 設定：

      健康監控功能設定

      <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

      請注意，上述的 Health Monitor 設定並未指定任何 <Port> 元素。在此情況下，邊緣的訊息處理器會使用目標伺服器定義 (即 80) 中指定的通訊埠執行健康狀態檢查 API 呼叫。

    3. 根據上述資訊，這個錯誤的原因是目標伺服器已定義為安全伺服器 (如已啟用 SSLInfo 區塊)，但卻使用不安全的通訊埠 80。

    安全目標不安全的 HM 通訊埠

    情境 2：已定義安全目標伺服器，但狀態監控器設定了不安全的通訊埠

    如果您已定義安全目標伺服器，但狀態監控器設為使用不安全的通訊埠 (例如 80)，您會收到這個錯誤。請按照下列步驟確認這個問題是否為原因：

    1. 檢查目標端點設定中使用的目標伺服器定義。

      使用 Get TargetServer API 取得目標伺服器定義。

      目標伺服器定義輸出內容

      <TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>

      在上述範例中，根據「SSLInfo」SSLInfo區塊指示，目標伺服器 mocktarget 是安全伺服器。

    2. 接著，檢查目標端點設定中目標伺服器的 Health Monitor 設定：

      健康監控功能設定

      <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>80</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>

      在上述範例中，健康狀態監控器設定了不安全的通訊埠 80，如 <Port> 元素所示。

    3. 根據上述資訊，這項錯誤是因為目標伺服器已定義為安全伺服器 (如已啟用 SSLInfo 區塊)，並使用安全通訊埠 443，但健康監控器已設為使用不安全的通訊埠 80 (在 <Port> 元素中指定) 執行健康狀態檢查。

      也就是說，在本範例中，Edge 會將健康狀態檢查 API 當做含有不安全通訊埠 80 的安全呼叫，且會失敗，並顯示上述錯誤。

解析度

安全目標非安全通訊埠

情境 1：以不安全的通訊埠定義的安全目標伺服器

如要修正這個錯誤，請更新目標伺服器定義，改用合適的安全通訊埠。

使用 更新 TargetServer API 更新目標伺服器定義，並確保使用安全通訊埠 (例如 443) ，如以下範例所示：

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>

安全目標不安全的 HM 通訊埠

情境 2：已定義安全目標伺服器，但狀態監控器設定了不安全的通訊埠

如要修正這項錯誤，請按照下列說明操作：

  1. 將 Health Monitor 設定修改為使用安全通訊埠 (例如：443)，在失敗 API Proxy 的目標端點設定中執行目標伺服器健康狀態檢查，如下所示： 
    <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
    <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
  2. 儲存對 API Proxy 所做的變更。

原因：透過安全通訊埠進行不安全的要求

診斷

  1. 判斷失敗要求的訊息 ID。
  2. 在訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋訊息 ID。
  3. 您會看到與訊息 ID 相對應的常見錯誤訊息。不過，如要取得健康狀態檢查失敗的實際原因，請捲動至這些常見錯誤訊息上方，並檢查是否有任何「健康監控錯誤」。

    例如，您可能會看到以下「HEALTH MONITOR」錯誤：

    Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
…<snipped>

    如果這項錯誤在狀態監控器中設定的 MaxFailure 次重複，您會看到以下警告訊息：

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

    請詳閱警告訊息中提供的資訊。確認您在收到 503 回應代碼 (錯誤代碼為 NoActiveTargets) 時，在特定 API Proxy 中使用的目標伺服器已達 MaxFailure 數量。

  4. 健康狀態檢查失敗，並出現以下錯誤： 
    Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server

    錯誤訊息和網址指出造成這個問題的原因，可能是透過安全通訊埠 443 發出不安全的呼叫 (HTTP)。

    這個錯誤可能發生在以下兩種情況中：

    • 以安全通訊埠定義的不安全目標伺服器
    • 已定義不安全的目標伺服器，但狀態監控器已設定安全通訊埠

    不安全的目標安全通訊埠

    情境 1：使用安全通訊埠定義的不安全目標伺服器

    如果您已定義不安全的目標伺服器，但使用安全通訊埠 (例如 443)，就會收到這個錯誤。請按照下列步驟確認這個問題是否為原因：

    1. 檢查目標端點設定中使用的目標伺服器定義。

      使用 Get TargetServer API 取得目標伺服器定義。

      目標伺服器定義輸出內容

      <TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

      在上述範例中，定義顯示目標伺服器 mocktarget 是不安全的伺服器，因為沒有 SSLInfo 區塊。但使用安全通訊埠 443 未正確設定。

    2. 現在，檢查目標端點設定中目標伺服器的 Health Monitor 設定：

      健康監控功能設定

      <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

      請注意，上述的 Health Monitor 設定並未指定任何 <Port> 元素。在這種情況下，邊緣的訊息處理器將使用目標伺服器定義中指定的通訊埠，也就是 443。

    3. 根據上述資訊，這項錯誤是因為目標伺服器已定義為不安全的伺服器 (未定義 SSLInfo 區塊)，而是使用安全通訊埠 443。

      也就是說，Edge 會將健康狀態檢查視為含有安全通訊埠 443 的非安全呼叫，並因上述錯誤而失敗。

    不安全的目標安全 HM 通訊埠

    情境 2：已定義不安全的目標伺服器，但狀態監控器已設定安全通訊埠

    如果您已定義不安全的目標伺服器，但狀態監控器設為使用安全通訊埠 (例如 443)，您會收到這個錯誤。請按照下列步驟確認這個問題是否為原因：

    1. 檢查目標端點設定中使用的目標伺服器定義。

      使用 Get TargetServer API 取得目標伺服器定義。

      目標伺服器定義輸出內容

      <TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

      在上述範例中，定義顯示目標伺服器 mocktarget 是不安全的伺服器 (因為沒有 SSLInfo 區塊)，並且使用非安全通訊埠 80 設定「正確」。

    2. 接著，檢查目標端點設定中目標伺服器的 Health Monitor 設定：

      健康監控功能設定

      <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

      在上述範例中，根據 <Port> 元素的說明，健康狀態監控器設定了安全通訊埠 443。

    3. 根據上述資訊，這項錯誤是因為目標伺服器已正確定義為不安全的伺服器 (未定義 SSLInfo 區塊)，但健康監控器已設為使用安全通訊埠 443 (在 <Port> 元素指定) 執行健康狀態檢查。

      在這種情況下，Edge 會將健康狀態檢查視為使用安全通訊埠 443 的不安全呼叫，並失敗，並顯示上述錯誤。

解析度

不安全的目標安全通訊埠

情境 1：使用安全通訊埠定義的不安全目標伺服器

如要修正這個錯誤，請更新目標伺服器定義，改用合適的安全通訊埠。

使用 更新目標伺服器 API 更新目標伺服器定義，並確保使用的是不安全的通訊埠 (例如：80)，如以下範例所示： 

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

不安全的目標安全 HM 通訊埠

情境 2：已定義不安全的目標伺服器，但狀態監控器已設定安全通訊埠

如要修正這項錯誤，請按照下列說明操作：

  1. 請從 Health Monitor 設定中移除 <Port> 元素，或修改 Health Monitor 設定，藉此使用非安全通訊埠 (例如：80) ，在失敗 API Proxy 的目標端點設定中執行目標伺服器健康狀態檢查，如下所示： 
    <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>80</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
  2. 儲存對 API Proxy 所做的變更。

原因：Health check API 傳回錯誤

診斷

  1. 判斷失敗要求的訊息 ID。
  2. 在郵件處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 ID。
  3. 您會看到與郵件 ID 相對應的常見錯誤訊息。 不過，如要取得健康狀態檢查失敗的實際原因，請捲動至這些常見錯誤訊息上方，並檢查是否有任何健康監控錯誤/警告。

    例如，您可能會看見如下所示的健康監控警告：

    Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404

    如果這項錯誤在狀態監控器中設定的 MaxFailure 次重複，您會看到以下警告訊息：

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

    請詳閱警告訊息中提供的資訊。確認您在收到 503 回應代碼 (錯誤代碼為 NoActiveTargets) 時，在特定 API Proxy 中使用的目標伺服器已達 MaxFailure 數量。

  4. 健康狀態檢查傳回警告訊息： 
    HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404

    上方的警告訊息指出健康狀態檢查 API 的預期回應代碼為 200，但實際收到的回應為 404。因此，系統會將此視為失敗。

  5. 調查健康狀態檢查 API 的錯誤回應原因前，請先瞭解 Edge 是否預期健康狀態檢查 API 的回應代碼為 200。如要這麼做，請檢查目標端點設定中目標伺服器的 Health Monitor 設定：

    健康監控功能設定

    <HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/status/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

    請注意，Health Monitor 設定在 <SuccessResponse> 元素下方設有 200 回應代碼。這表示，如果 Edge 從健康狀態檢查 API 收到 200 以外的任何回應代碼 (例如 400、401、404、500)，就會視為錯誤並遞增失敗數量。

  6. 現在，如要調查健康狀態檢查 API 傳回錯誤回應的原因，請按照下列步驟操作：
    1. 在「訊息處理器」記錄中查看警告訊息之前的訊息。 
      Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200

      請記下這則訊息中的健康狀態檢查網址。

    2. 您可以透過訊息處理器直接呼叫這個網址，並查看實際的回應 
      curl -i https://mocktarget.apigee.net:443/status/200

      上述呼叫的回應會提供 404，如「訊息處理器」記錄所示：

      < HTTP/2 404
    3. 這表示即使直接呼叫健康狀態檢查網址，也會以相同的回應代碼 404 失敗。這表示健康狀態檢查網址可能不正確，或是該網址中存取的資源已無法使用。
    4. 在上述提供的健康狀態檢查 API 範例中，之所以會發生這個問題，是因為 Health Monitor 設定中使用的網址不正確。系統發現 Mock Target API 為 https://mocktarget.apigee.net:443/statuscode/200 的正確網址。
  7. 如果收到任何其他錯誤回應，請按照上述步驟找出造成相同原因的原因。如有必要，請與後端團隊合作。

解析度

  1. 修正後端伺服器上的健康狀態檢查 API 問題。
  2. 如何修正上述範例中的問題：
    1. 將 Health Monitor 設定中的 <Path> 元素修改為 /statuscode/200，如下所示： 
      <Path>/statuscode/200</Path>
    2. 將變更儲存至 API Proxy。

如果問題仍未解決，請參閱「收集診斷資訊」一節。

使用 API 監控功能診斷問題

API 監控功能可讓您快速隔離問題區域，以診斷錯誤、效能與延遲問題及其來源 (例如開發人員應用程式、API Proxy、後端目標或 API 平台)。

逐步操作範例情境，示範如何使用 API Monitoring 排解 API 的 5xx 問題。例如，您可以設定快訊，讓系統在 messaging.adaptors.http.flow.NoActiveTargets 錯誤數量超過特定門檻時收到通知。

必須收集診斷資訊

按照上述操作說明操作後，如果問題仍未解決，請收集下列診斷資訊。請與 Apigee 支援團隊聯絡並分享資料：

  1. 如果您是公有雲使用者，請提供下列資訊：
    1. 機構名稱
    2. 環境名稱
    3. API Proxy 名稱
    4. 完成 curl 指令即可重現錯誤
    5. 包含 503 Service Unavailable 與錯誤代碼 NoActiveTargets 相關要求的追蹤檔
  2. 如果您是私有雲使用者，請提供下列資訊：
    1. 發現完整錯誤訊息
    2. 環境名稱
    3. API Proxy 套裝組合
    4. 包含 503 Service Unavailable 與錯誤代碼 NoActiveTargets 相關要求的追蹤檔
    5. NGINX 存取記錄檔

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

    6. 訊息處理器記錄

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)