本頁面由 Cloud Translation API 翻譯而成。

503 Service Unavailable - NoActiveTargets - HealthCheckFailures

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。資訊

影片

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

影片	說明
疑難排解並解決 503 Service Unavailable - NoActiveTargets	請參閱下列文章：目標伺服器和健康監控器的重要性即時疑難排解並解決即時 503 Service Unavailable - NoActiveTargets 健康狀態檢查失敗導致的錯誤

問題

用戶端應用程式收到 HTTP 回應狀態碼 503， Service Unavailable 訊息和錯誤代碼 NoActiveTargets API Proxy 要求

錯誤訊息

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

HTTP/1.1 503 Service Unavailable

您會在 HTTP 回應中看到下列錯誤訊息：

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

可能原因

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

本教戰手冊涵蓋 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。

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

原因	說明	誰可以執行疑難排解步驟
連線逾時錯誤	訊息處理器無法在指定的逾時時間內連線到目標伺服器設定期間。	Edge Private Cloud 使用者
對不安全的通訊埠提交安全要求	如果目標伺服器已定義為安全伺服器，但與使用不安全的通訊埠如果目標伺服器已定義為安全伺服器，但健康狀態監控器以便對不安全的通訊埠執行健康狀態檢查。	Edge Private Cloud 使用者
對安全通訊埠提出的不安全要求	如果目標伺服器定義為不安全的伺服器，但設定不正確以及安全連接埠如果目標伺服器已定義為不安全的伺服器，但健康狀態監控器是執行健康狀態檢查，以對安全通訊埠執行健康狀態檢查	Edge Private Cloud 使用者
Health Check API 傳回錯誤	如果健康狀態檢查 API 傳回錯誤或回應代碼，會在健康狀態檢查的 SuccessResponse 元素中指定。	Edge Private Cloud 使用者

常見的診斷步驟

找出失敗要求的訊息 ID

追蹤工具

如要使用追蹤工具找出失敗要求的訊息 ID，請按照下列步驟操作：

啟用追蹤工作階段。發出 API 呼叫，並重現問題 - 503 Service Unavailable 與錯誤代碼 NoActiveTargets。
請選取其中一個失敗的要求。
前往 AX 階段，找出郵件 ID (X-Apigee.Message-ID) 該要求的資訊，方法是在「Phase Details」部分向下捲動，如下圖所示。

NGINX 存取記錄

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

您也可以參閱 NGINX 存取記錄，找出 503 錯誤的郵件 ID。如果過去曾經發生問題或問題持續發生，這項功能就特別實用，您也無法在 UI 中擷取追蹤記錄。請按照下列步驟，根據 NGINX 存取記錄判斷這項資訊：

查看 NGINX 存取記錄：(/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
搜尋特定 API Proxy 在指定期間內是否有 503 錯誤 (如果問題是過去發生)，或是仍有 503 要求還是失敗。
如果 X-Apigee-fault-code message.adaptors.http.flow.NoActiveTargets 中有任何 503 錯誤，記下一或多個這類要求的郵件 ID，如以下範例所示：
顯示 503 錯誤的範例項目

常見錯誤訊息

使用目標伺服器時，訊息處理器嘗試存取目標伺服器時發生錯誤連至後端伺服器後，您會在訊息處理器記錄。這些錯誤會在實際例外狀況/錯誤訊息之後記錄以免發生故障

在訊息處理器記錄中觀察到的常見錯誤訊息 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 針對傳回 503 Service Unavailable 錯誤 (錯誤代碼為 NoActiveTargets) 如下：

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 做為用戶端的回應。

原因：連線逾時

診斷

找出失敗要求的訊息 ID。
在訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 ID。

您會看到常見錯誤訊息。不過如要取得健康狀態檢查失敗的實際原因，請捲動至這些常見的錯誤訊息，並檢查是否有任何 HEALTH MONITOR 錯誤。

舉例來說，如果出現下列 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}

請仔細閱讀警告訊息中提供的資訊。確認 MaxFailure 特定 API Proxy 中所用目標伺服器的數量已達上限會收到 503 回應代碼及錯誤代碼 NoActiveTargets。

在上述範例中，健康狀態檢查失敗，並發生 connection timed out 錯誤。檢查您能否直接從各個後端伺服器使用 telnet 指令的訊息處理器：

telnet <BackendServer-HostName> 443

如果您能連上後端伺服器，可能會看到類似以下內容的訊息： 已連線至後端伺服器。那麼問題也許只是暫時性問題，也許已解決，或者是間歇性問題重複執行步驟 4 數次，然後驗證輸出內容。

如果 telnet 指令持續沒有錯誤，則問題為均已解決。重新檢查健康狀態檢查失敗是否已停止。如果支援，您就不必這麼做它會有什麼影響
如果無法使用 telnet 指令連線至後端伺服器，也有可能是網路發生問題，或是後端伺服器處於忙碌狀態。

如果無法持續使用 telnet 指令連線至後端伺服器，這可能是因為系統不允許來自特定後端伺服器的訊息處理器流量。

解析度

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

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

原因：對不安全的通訊埠提出安全要求

診斷

找出失敗要求的訊息 ID。
在訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 ID。

您會看見與郵件 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}

請仔細閱讀警告訊息中提供的資訊。確認 MaxFailure 特定 API Proxy 中所用目標伺服器的數量已達上限會收到 503 回應代碼及錯誤代碼 NoActiveTargets。

健康狀態檢查失敗，錯誤訊息如下：
```
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
      
```
錯誤訊息和網址會指出造成這個問題的可能原因： 安全呼叫 (HTTPS) 是向不安全的通訊埠 80 發出。

此錯誤可能會在下列兩種情況中發生：
- 以不安全的通訊埠定義安全目標伺服器
- 已定義安全目標伺服器，但健康監控器設定了不安全的通訊埠
安全目標不安全通訊埠

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

如果您已定義安全的目標伺服器，但使用了不安全的通訊埠 (例如 80)，。請按照下列步驟操作，確認這是否為這個問題的原因：
1. 檢查目標端點設定中使用的目標伺服器定義。
2. 現在，檢查目標端點設定中目標伺服器的健康狀態檢查設定：
  健康監控器設定
```
<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>
          
```
  請注意，<Port> 上方的健康監控器設定。在這種情況下，Edge 的郵件處理器會使用通訊埠。
3. 根據上述資訊，發生這項錯誤的原因是目標伺服器定義為安全伺服器 (如啟用 SSLInfo 區塊)，但使用的是不安全的通訊埠 80。
安全目標不安全的 HM 通訊埠

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

如果您已定義安全的目標伺服器，但健康監控器設定了如果不是安全通訊埠 (例如 80)，就會出現這個錯誤訊息。請按照以下步驟進行驗證造成這個問題的原因：
1. 檢查目標端點設定中使用的目標伺服器定義。
  使用取得 TargetServer API 以取得目標伺服器定義。
  
  目標伺服器定義輸出內容
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
        
```
  在上述範例中，定義顯示目標伺服器 mocktarget 是 SSLInfo 區塊所示的安全伺服器。
2. 接著，請檢查目標端點設定中目標伺服器的健康狀態檢查設定：
  健康監控器設定
```
<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>
        
```
  在上述範例中，健康監控器設定了 <Port> 元素所示的不安全通訊埠 80。
3. 根據上述資訊，發生這項錯誤的原因在於目標伺服器已定義視為安全伺服器 (啟用 SSLInfo 區塊)，並使用安全通訊埠 443，但健康監測器已設為透過不安全的通訊埠 80 (在 <Port> 元素中指定) 執行健康狀態檢查。
  在這個情況下，Edge 會將健康狀態檢查 API 視為含有不安全呼叫的安全呼叫通訊埠 80 執行失敗，發生上述錯誤。
  
  注意：在健康監控器中設定的 <Port> 元素，優先順序高於目標伺服器定義中使用的通訊埠。

解析度

安全目標不安全通訊埠

情境 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：已定義安全目標伺服器，但健康監控器設定了不安全的通訊埠

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

修改健康監控器設定，使用安全通訊埠 (例如 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>

儲存 API Proxy 變更。

原因：對安全連接埠提出的不安全要求

診斷

找出失敗要求的訊息 ID。
在訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 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}

請仔細閱讀警告訊息中提供的資訊。確認 MaxFailure 特定 API Proxy 中所用目標伺服器的數量已達上限會收到 503 回應代碼及錯誤代碼 NoActiveTargets。

健康狀態檢查失敗，錯誤訊息如下：
```
Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
      
```
錯誤訊息和網址會指出造成這個問題的可能原因： 非安全呼叫 (HTTP) 則是透過安全通訊埠 443 進行。

此錯誤可能會在下列兩種情況中發生：
- 使用安全通訊埠定義的不安全目標伺服器
- 已定義不安全的目標伺服器，但健康監控器已設為使用安全通訊埠
不安全的目標安全通訊埠

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

如果您定義了不安全的目標伺服器，但使用了安全通訊埠 (例如 443)，就會顯示這則錯誤訊息請按照下列步驟操作，確認這是否為這個問題的原因：
1. 檢查目標端點設定中使用的目標伺服器定義。
  使用取得 TargetServer API 以取得目標伺服器定義。
  
  目標伺服器定義輸出內容
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              
```
  在上述範例中，定義顯示目標伺服器 mocktarget 是不安全的伺服器，因為沒有 SSLInfo 封鎖。但是，此做法有誤使用安全的通訊埠 443。
2. 現在，檢查目標端點設定中目標伺服器的健康狀態檢查設定：
  健康監控器設定
```
<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>
                
```
  請注意，健康監控器中並未指定 <Port> 元素上述設定。在這種情況下，Edge 的郵件處理器將使用也就是 443
3. 根據上述資訊，發生這項錯誤的原因在於目標伺服器已定義視為不安全的伺服器 (未定義 SSLInfo 區塊)，但使用的是安全通訊埠 443。
  也就是說，Edge 會將健康狀態檢查視為安全通訊埠 443 的非安全呼叫，但失敗時失敗。
不安全的目標安全 HM 通訊埠

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

如果您已定義不安全的目標伺服器，但 Health Monitor 設定了安全通訊埠，例如 443，就會顯示這則錯誤訊息請按照下列步驟操作，確認這是否為這個問題的原因：
1. 檢查目標端點設定中使用的目標伺服器定義。
  使用取得 TargetServer API 以取得目標伺服器定義。
  
  目標伺服器定義輸出內容
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
        
```
  在上述範例中，定義顯示目標伺服器 mocktarget 為不安全伺服器 (因為沒有 SSLInfo 區塊)，使用不安全的通訊埠 80 正確設定。
2. 接著，請檢查目標端點設定中目標伺服器的健康狀態檢查設定：
  健康監控器設定
```
<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>
      
```
  在上述範例中，健康監控器設定了安全的通訊埠 443，如 <Port> 元素所示。
3. 根據上述資訊，發生這項錯誤的原因可能是目標伺服器定義為 不安全的伺服器 (如未定義 SSLInfo 區塊) 使用不安全的通訊埠 80。但健康監控器已設為使用安全通訊埠 443 (在 <Port> 元素中指定) 執行健康狀態檢查。
  在這個情況下，Edge 會將健康狀態檢查視為含有安全通訊埠 443 的非安全呼叫，並因上述錯誤失敗而失敗。

解析度

不安全的目標安全通訊埠

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

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

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

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

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

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

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

從健康監控器設定中移除 <Port> 元素或修改健康監控器設定，改為使用不安全的通訊埠 (例如：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>

儲存 API Proxy 變更。

原因：Health check API 傳回錯誤

診斷

找出失敗要求的訊息 ID。
在訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 中搜尋郵件 ID。
您會看見與郵件 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}
        
```
請仔細閱讀警告訊息中提供的資訊。確認 MaxFailure 特定 API Proxy 中所用目標伺服器的數量已達上限會收到 503 回應代碼及錯誤代碼 NoActiveTargets。
健康狀態檢查傳回警告訊息：
```
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
      
```
以上警告訊息指出 Health check API 的預期回應代碼為 200。但實際回應數為 404。因此，系統會將此視為失敗。
在調查健康狀態檢查 API 錯誤回應的原因之前，請先判斷 Edge 原因健康狀態檢查 API 的回應代碼為 200。如需此資訊，請檢查健康監控器為目標伺服器設定
健康監控器設定
```
<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>
        
```
請注意，健康監控器設定在 <SuccessResponse> 元素下方設有 200 回應代碼。也就是說，如果 Edge 從健康狀態檢查 API 收到任何 200 以外的回應代碼 (例如 400、401、404、500)，就會視為錯誤並遞增
現在，如要透過健康狀態檢查 API 調查錯誤回應的原因，請按照下列步驟操作：

在「訊息處理器」記錄中查看警告訊息之前的訊息。

Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200

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

您可以直接透過訊息處理程式呼叫這個網址，並查看實際回應
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
上述呼叫的回應會提供 404，如訊息處理器記錄所示：
```
< HTTP/2 404
          
```
這表示即使直接呼叫健康狀態檢查網址，也會失敗並傳回相同的回應代碼 404。這可能表示健康狀態檢查網址可能不正確，或是您無法再透過網址存取資源。
在上方提供的健康狀態檢查 API 範例中，之所以發生問題，是因為 Health Monitor 設定中使用的網址不正確。找到的 https://mocktarget.apigee.net:443/statuscode/200 網址正確無誤模擬目標 API。

如果收到其他錯誤回應，請按照步驟。如有必要，請與後端團隊合作。

解析度

修正後端伺服器上健康狀態檢查 API 的問題。
如要修正上述範例中的問題：

將健康監控器設定中的 <Path> 元素修改為 /statuscode/200，如下所示：
```
<Path>/statuscode/200</Path>
        
```
在 API Proxy 中儲存變更。

如果問題仍未解決，請前往 Must Gather Diagnostic Information，

使用 API 監控功能診斷問題

API Monitoring 可讓您找出問題所在迅速診斷錯誤、效能和延遲問題及其來源，例如開發人員應用程式、API Proxy、後端目標或 API 平台

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

必須收集診斷資訊

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

如果您是公用雲端的使用者，請提供下列資訊：

機構名稱
環境名稱
API Proxy 名稱
完成 curl 指令即可重現錯誤
追蹤檔含有 503 Service Unavailable 要求 (錯誤代碼為 NoActiveTargets) 的要求

如果您是 Private Cloud 使用者，請提供以下資訊：
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)