503 Dienst nicht verfügbar – NoActiveTargets – HealthCheckFailures

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Videos

Weitere Informationen zu 503‑Fehlern finden Sie in den folgenden Videos:

Symptom

Die Clientanwendung empfängt den HTTP-Antwortstatuscode 503 mit der Meldung Service Unavailable (Dienst nicht verfügbar) und dem Fehlercode NoActiveTargets für die API-Proxy-Anfragen.

Fehlermeldung

Sie erhalten die folgende Fehlermeldung:

HTTP/1.1 503 Service Unavailable
  

In der HTTP-Antwort wird die folgende Fehlermeldung angezeigt:

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

Mögliche Ursachen

Die HTTP-Antwort 503 Service Unavailable mit dem Fehlercode NoActiveTargets wird in der Regel angezeigt, wenn Sie einen oder mehrere Zielserver in der Zielendpunktkonfiguration Ihres API-Proxys verwenden.

In diesem Playbook geht es um den Fehler 503 Service Unavailable mit dem Fehlercode NoActiveTargets, der durch Fehler bei der Systemdiagnose verursacht wird. In diesem Playbook finden Sie weitere mögliche Ursachen für diesen Fehler.

Fehler bei Systemdiagnosen

Die Fehler bei der Systemdiagnose werden nur beobachtet, wenn Sie einen Systemdiagnosemonitor als Teil der Load-Balancing-Konfiguration des Zielservers im Zielendpunkt Ihres API-Proxys konfiguriert haben.

Wenn ein Zielserver eine Systemdiagnose nicht besteht, erhöht Edge den Fehlerzähler dieses Servers. Wenn die Anzahl der Fehler bei der Systemdiagnose für diesen Server den vordefinierten Schwellenwert (<MaxFailures>) erreicht, protokolliert der Message Processor die Warnmeldung wie unten dargestellt in seiner Logdatei:

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}
    

Die Warnmeldung enthält die folgenden Informationen. So können Sie nachvollziehen, welcher Zielserver die Anzahl von MaxFailure erreicht hat:

• Name des Zielservers
• Organisations- und Umgebungsnamen
• Name des API-Proxys
• Name des Zielendpunkts

Danach sendet Edge keine weiteren Anfragen mehr an diesen Server. Sobald alle in der LoadBalancer-Konfiguration konfigurierten Zielserver die Anzahl MaxFailure erreicht haben, wird auf die nachfolgenden API-Anfragen mit 503 Service Unavailable und dem Fehlercode NoActiveTargets geantwortet.

Mit Health Monitor kann Apigee Edge einen Zielserver automatisch wieder in die Rotation aufnehmen, wenn er wieder fehlerfrei funktioniert, ohne dass der API-Proxy neu bereitgestellt werden muss.

Mögliche Ursachen für Fehler bei der Systemdiagnose:

Allgemeine Diagnoseschritte

Nachricht-ID der fehlgeschlagenen Anfrage ermitteln

Häufige Fehlermeldungen

Wenn Zielserver verwendet werden und ein Fehler auftritt, während der Message Processor versucht, eine Verbindung zum Backend-Server herzustellen, werden in den Message Processor-Logs einige häufige Fehlermeldungen angezeigt. Diese Fehler werden nach der eigentlichen Ausnahme-/Fehlermeldung protokolliert, die zum Fehler geführt hat.

Die häufigsten Fehlermeldungen, die in den Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) für den Fehler 503 Service Unavailable mit dem Fehlercode NoActiveTargets angezeigt werden, sind:

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>

Diese Fehlermeldungen weisen darauf hin, dass die Anfrage aufgrund eines Fehlers nicht an den Backend-Server gesendet werden konnte. Daher sendet der Message Processor 503 Service Unavailable mit dem Fehlercode NoActiveTargets als Antwort an den Client.

Ursache: Zeitüberschreitung der Verbindung

Diagnose

1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Log des Message Processors (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der Nachrichten-ID.
3. Sie sehen die gängigen Fehlermeldungen, die der Nachrichten-ID entsprechen. Die tatsächliche Ursache für die Systemdiagnosefehler finden Sie jedoch, wenn Sie über diese häufigen Fehlermeldungen nach HEALTH MONITOR-Fehlern suchen.

   Die folgende HEALTH MONITOR-Fehlermeldung gibt beispielsweise an, dass der Message Processor bei der API-Anfrage für die Systemdiagnose mit einem Zeitüberschreitungsfehler fehlgeschlagen ist:

   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>
           

   Wenn dieser Fehler MaxFailure Mal wiederholt auftritt, wie im Health Monitor konfiguriert, wird eine Warnmeldung wie diese angezeigt:

   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}
           

   Lesen Sie die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der im jeweiligen API-Proxy verwendet wird, für den Sie den Antwortcode 503 mit dem Fehlercode NoActiveTargets erhalten.

4. Im obigen Beispiel ist die Systemdiagnose mit dem Fehler connection timed out fehlgeschlagen. Prüfen Sie, ob Sie von jedem der Message Processors aus mit dem Befehl telnet eine direkte Verbindung zum jeweiligen Backend-Server herstellen können:

telnet <BackendServer-HostName> 443
      

5. Wenn Sie eine Verbindung zum Backend-Server herstellen können, wird möglicherweise eine Meldung wie Connected to backend-server (Mit Backend-Server verbunden) angezeigt. Dann handelt es sich möglicherweise um ein vorübergehendes Problem, das entweder behoben wurde oder nur zeitweise auftritt. Wiederholen Sie Schritt 4 einige Male (mindestens 10 Mal) und prüfen Sie die Ausgabe.
1. Wenn der Befehl telnet immer ohne Fehler ausgeführt wird, ist das Problem behoben. Prüfen Sie noch einmal, ob die Fehler bei der Systemdiagnose behoben wurden. Falls ja, müssen Sie nichts weiter tun.
2. Wenn Sie mit dem Befehl telnet zeitweise keine Verbindung zum Backend-Server herstellen können, liegt möglicherweise ein Netzwerkproblem vor oder Ihr Backend-Server ist ausgelastet.
6. Wenn Sie mit dem Befehl telnet keine Verbindung zum Backend-Server herstellen können, liegt das möglicherweise daran, dass der Traffic von den Message Processors auf dem jeweiligen Backend-Server nicht zulässig ist.

Auflösung

Wenn der connection timed out-Fehler immer wieder auftritt, prüfen Sie, ob für den Backend-Server Firewalleinschränkungen gelten und ob der Traffic von den Apigee Edge-Nachrichtenprozessoren zugelassen wird. Unter Linux können Sie beispielsweise iptables verwenden, um den Traffic von den IP-Adressen des Nachrichtenprozessors auf dem Backend-Server zuzulassen.

Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Netzwerkadministrator, um das Problem zu ermitteln und zu beheben. Wenn Sie weitere Unterstützung von Apigee benötigen, wenden Sie sich an den Apigee-Support.

Ursache: Sichere Anfrage an nicht sicheren Port

Diagnose

1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Log des Message Processors (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der Nachrichten-ID.
3. Sie sehen die häufigen Fehlermeldungen, die der Nachrichten-ID entsprechen. Die tatsächliche Ursache für die Fehler bei der Systemdiagnose finden Sie jedoch, wenn Sie über diese häufigen Fehlermeldungen nach HEALTH MONITOR-Fehlern suchen.

   Möglicherweise wird ein HEALTH MONITOR-Fehler wie unten dargestellt angezeigt:

   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>
           

   Wenn dieser Fehler MaxFailure Mal wiederholt auftritt, wie im Health Monitor konfiguriert, wird eine Warnmeldung wie diese angezeigt:

   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}
           

   Lesen Sie die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der im jeweiligen API-Proxy verwendet wird, für den Sie den Antwortcode 503 mit dem Fehlercode NoActiveTargets erhalten.

4. Die Systemdiagnose ist mit dem folgenden Fehler fehlgeschlagen:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   Die Fehlermeldung und die URL deuten darauf hin, dass das Problem dadurch verursacht wird, dass ein sicherer Aufruf (HTTPS) über den nicht sicheren Port 80 erfolgt ist.

   Dieser Fehler kann in den folgenden zwei Szenarien auftreten:

   • Sicheren Zielserver mit nicht sicherem Port definiert
   • Sicherer Zielserver definiert, aber Systemdiagnose mit einem nicht sicheren Port konfiguriert

   Sicheres Ziel – nicht sicherer Port

   Szenario 1: Sicherer Zielserver, der mit einem nicht sicheren Port definiert ist

   Wenn Sie einen sicheren Zielserver, aber einen nicht sicheren Port wie 80 definiert haben, erhalten Sie diesen Fehler. Gehen Sie so vor, um zu prüfen, ob dies die Ursache des Problems ist:

   1. Prüfen Sie die Definition des Zielservers, der in der Zielendpunktkonfiguration verwendet wird.

   Verwenden Sie die Get TargetServer API, um die TargetServer-Definition abzurufen.

   Ausgabe der TargetServer-Definition

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

   Im obigen Beispiel zeigt die Definition, dass der Zielserver mocktarget ein sicherer Server ist, wie durch den SSLInfo-Block angegeben. Sie ist jedoch mit einem unsicheren Port 80 konfiguriert.

   2. Sehen Sie sich nun die Health Monitor-Konfiguration für den Zielserver in der Zielendpunktkonfiguration an:

      Konfiguration von 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>
                

      Beachten Sie, dass in der oben genannten Konfiguration des Health Monitors kein <Port>-Element angegeben ist. In diesem Fall verwendet der Message Processor von Edge den in der Zielserverdefinition angegebenen Port (80) für Systemdiagnose-API-Aufrufe.

   3. Anhand der obigen Informationen lässt sich erkennen, dass die Ursache für diesen Fehler darin liegt, dass der Zielserver als sicherer Server definiert ist (da der SSLInfo-Block aktiviert ist), aber mit einem nicht sicheren Port 80.

   Sicheres Ziel – nicht sicherer HM-Port

   Szenario 2: Sicherer Zielserver definiert, aber Systemdiagnose mit einem nicht sicheren Port konfiguriert

   Dieser Fehler tritt auf, wenn Sie einen sicheren Zielserver definiert haben, der HealthMonitor aber mit einem nicht sicheren Port wie 80 konfiguriert ist. So kannst du überprüfen, ob dies die Ursache für das Problem ist:

   1. Prüfen Sie die Definition des Zielservers, der in der Zielendpunktkonfiguration verwendet wird.

      Verwenden Sie die Get TargetServer API, um die TargetServer-Definition abzurufen.

      Ausgabe der TargetServer-Definition

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

      Im obigen Beispiel zeigt die Definition, dass der Zielserver mocktarget ein sicherer Server ist, wie durch den SSLInfo-Block angegeben.

   2. Prüfen Sie als Nächstes die Health Monitor-Konfiguration für den Zielserver in der Zielendpunktkonfiguration:

      Konfiguration von 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>
              

      Im obigen Beispiel ist der Health Monitor mit einem nicht sicheren Port 80 konfiguriert, wie durch das Element <Port> angegeben.

   3. Anhand der obigen Informationen lässt sich feststellen, dass die Ursache für diesen Fehler darin liegt, dass der Zielserver als sicherer Server definiert ist (da der SSLInfo-Block aktiviert ist) und den sicheren Port 443 verwendet, der Health Monitor jedoch so konfiguriert ist, dass er Systemdiagnosen mit einem nicht sicheren Port 80 durchführt (angegeben im <Port>-Element).

      In diesem Fall führt Edge die Systemdiagnose-APIs als sicheren Aufruf mit dem nicht sicheren Port 80 aus und gibt den oben genannten Fehler zurück.

Auflösung

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

Ursache: Nicht sichere Anfrage auf einem sicheren Port

Diagnose

1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Log des Message Processors (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der Nachrichten-ID.
3. Sie sehen die gängigen Fehlermeldungen, die der Nachrichten-ID entsprechen. Die tatsächliche Ursache für die Fehler bei der Systemdiagnose finden Sie jedoch, wenn Sie über diese häufigen Fehlermeldungen nach HEALTH MONITOR-Fehlern suchen.

   Möglicherweise wird ein HEALTH MONITOR-Fehler wie unten dargestellt angezeigt:

   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>
             

   Wenn dieser Fehler MaxFailure Mal wiederholt auftritt, wie im Health Monitor konfiguriert, wird eine Warnmeldung wie diese angezeigt:

   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}
             

   Lesen Sie die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der im jeweiligen API-Proxy verwendet wird, für den Sie den Antwortcode 503 mit dem Fehlercode NoActiveTargets erhalten.

4. Die Systemdiagnose ist mit dem folgenden Fehler fehlgeschlagen:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   Die Fehlermeldung und die URL weisen darauf hin, dass das Problem durch einen nicht sicheren Aufruf (HTTP) über den sicheren Port 443 verursacht wurde.

   Dieser Fehler kann in den folgenden zwei Szenarien auftreten:

   • Nicht sicherer Zielserver mit sicherem Port definiert
   • Nicht sicherer Zielserver definiert, aber Health Monitor mit einem sicheren Port konfiguriert

   Nicht sicherer Zielport

   Szenario 1: Nicht sicherer Zielserver mit sicherem Port

   Dieser Fehler tritt auf, wenn Sie einen nicht sicheren Zielserver mit einem sicheren Port wie 443 definiert haben. Gehen Sie so vor, um zu prüfen, ob dies die Ursache des Problems ist:

   1. Prüfen Sie die Definition des Zielservers, der in der Zielendpunktkonfiguration verwendet wird.

      Verwenden Sie die Get TargetServer API, um die TargetServer-Definition abzurufen.

      Ausgabe der TargetServer-Definition

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

      Im obigen Beispiel zeigt die Definition, dass der Zielserver mocktarget ein nicht sicherer Server ist, da kein SSLInfo-Block vorhanden ist. Sie ist jedoch falsch konfiguriert mit einem sicheren Port 443.

   2. Sehen Sie sich nun die Health Monitor-Konfiguration für den Zielserver in der Zielendpunktkonfiguration an:

      Konfiguration von 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>
                      

      Beachten Sie, dass in der oben stehenden Health Monitor-Konfiguration kein <Port>-Element angegeben ist. In diesem Fall verwendet der Message Processor von Edge den in der Zielserverdefinition angegebenen Port 443.

   3. Anhand der obigen Informationen lässt sich erkennen, dass die Ursache für diesen Fehler darin liegt, dass der Zielserver als nicht sicherer Server definiert ist (da der SSLInfo-Block nicht definiert ist), aber mit einem sicheren Port 443.

      Das heißt, Edge führt die Systemdiagnosen als nicht sicheren Aufruf mit dem sicheren Port 443 aus und schlägt mit dem oben genannten Fehler fehl.

   Nicht sicherer Zielport für sicheren gehosteten Eintrag in Match-Table

   Szenario 2: Nicht sicherer Zielserver definiert, aber Health Monitor mit einem sicheren Port konfiguriert

   Dieser Fehler tritt auf, wenn Sie einen nicht sicheren Zielserver definiert haben, der Health Monitor aber mit einem sicheren Port wie 443 konfiguriert ist. Gehen Sie so vor, um zu prüfen, ob dies die Ursache des Problems ist:

   1. Prüfen Sie die Definition des Zielservers, der in der Zielendpunktkonfiguration verwendet wird.

      Verwenden Sie die Get TargetServer API, um die TargetServer-Definition abzurufen.

      Ausgabe der TargetServer-Definition

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

      Im obigen Beispiel zeigt die Definition, dass der Zielserver mocktarget ein nicht sicherer Server ist (da kein SSLInfo-Block vorhanden ist), der mit einem nicht sicheren Port 80 korrekt konfiguriert ist.

   2. Prüfen Sie als Nächstes die Health Monitor-Konfiguration für den Zielserver in der Zielendpunktkonfiguration:

      Konfiguration von 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>
            

      Im obigen Beispiel ist der Health Monitor mit einem sicheren Port 443 konfiguriert, wie durch das Element <Port> angegeben.

   3. Anhand der obigen Informationen lässt sich erkennen, dass die Ursache für diesen Fehler darin liegt, dass der Zielserver als nicht sicherer Server (da der SSLInfo-Block nicht definiert ist) mit dem nicht sicheren Port 80 korrekt definiert ist, der Health Monitor jedoch so konfiguriert ist, dass Systemdiagnosen mit einem sicheren Port 443 (im <Port>-Element angegeben) durchgeführt werden.

      In diesem Fall führt Edge die Systemdiagnosen als nicht sicheren Aufruf mit dem sicheren Port 443 aus und schlägt mit dem oben genannten Fehler fehl.

Auflösung

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

Ursache: Die Health Check API antwortet mit einem Fehler.

Diagnose

1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Log des Message Processors (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der Nachrichten-ID.
3. Sie sehen die häufigen Fehlermeldungen, die der Nachrichten-ID entsprechen. Die tatsächliche Ursache für die Systemdiagnosefehler finden Sie jedoch, wenn Sie über diese häufigen Fehlermeldungen scrollen und nach HEALTH MONITOR-Fehlern oder -Warnungen suchen.

   Möglicherweise wird eine Warnung zur Statusüberwachung angezeigt, wie unten dargestellt:

   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
           

   Wenn dieser Fehler MaxFailure Mal wiederholt auftritt, wie im Health Monitor konfiguriert, wird eine Warnmeldung wie diese angezeigt:

   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}
           

   Lesen Sie die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der im jeweiligen API-Proxy verwendet wird, für den Sie den Antwortcode 503 mit dem Fehlercode NoActiveTargets erhalten.

4. Die Systemdiagnose hat die folgende Warnmeldung zurückgegeben:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   In der Warnmeldung oben wird angegeben, dass der erwartete Antwortcode für die Health Check API 200 war, aber der tatsächlich empfangene Antwortcode 404 ist. Daher wird dies als Fehler behandelt.

5. Bevor Sie die Ursache für die Fehlerantwort der Health Check API untersuchen, müssen Sie herausfinden, warum Edge für die Health Check API den Antwortcode 200 erwartet. Prüfen Sie dazu die Konfiguration des Health Monitors für den Zielserver in der Zielendpunktkonfiguration:

   Konfiguration von 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>
           

   Beachten Sie, dass die HealthMonitor-Konfiguration mit dem Antwortcode 200 unter dem Element <SuccessResponse> konfiguriert ist. Wenn Edge also einen anderen Antwortcode als 200 von der Health Check API erhält (z. B. 400, 401, 404, 500), wird dies als Fehler behandelt und die Anzahl der Fehler wird erhöht.

6. Führen Sie die folgenden Schritte aus, um die Ursache für die Fehlerantwort der Health Check API zu ermitteln:
1. Sehen Sie sich die Nachricht vor der Warnmeldung im Message Processor-Log an.

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

   Notieren Sie sich die URL der Systemdiagnose aus dieser Meldung.

2. Sie können einen direkten Aufruf an diese URL vom Message Processor aus starten und die tatsächliche Antwort prüfen.

   curl -i https://mocktarget.apigee.net:443/status/200
             

   Die Antwort des obigen Aufrufs gibt 404 zurück, wie in den Message Processor-Logs zu sehen ist:

   < HTTP/2 404
             

3. Das zeigt, dass auch der direkte Aufruf der Systemdiagnose-URL mit demselben Antwortcode 404 fehlschlägt. Das bedeutet, dass die Systemdiagnose-URL möglicherweise falsch ist oder die Ressource, auf die im Rahmen der URL zugegriffen wird, nicht mehr verfügbar ist.
4. Im oben gezeigten Beispiel für die Systemdiagnose-API tritt das Problem auf, weil in der Health Monitor-Konfiguration eine falsche URL verwendet wurde. Die richtige URL ist https://mocktarget.apigee.net:443/statuscode/200 aus der Mock Target API.
7. Wenn Sie eine andere Fehlermeldung erhalten, ermitteln Sie die Ursache anhand der Schritte oben. Arbeiten Sie bei Bedarf mit Ihrem Backend-Team zusammen.

Auflösung

1. Beheben Sie das Problem mit der Systemdiagnose-API auf Ihrem Back-End-Server.
2. So beheben Sie das Problem im oben genannten Beispiel:
1. Ändern Sie das Element <Path> in der Health Monitor-Konfiguration in /statuscode/200, wie unten gezeigt:

   <Path>/statuscode/200</Path>
           

2. Speichern Sie die Änderungen im API-Proxy.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Fehlerdiagnose mit API-Monitoring

Mit API-Monitoring können Sie Problembereiche schnell isolieren, um Fehler-, Leistungs- und Latenzprobleme sowie deren Quelle zu diagnostizieren, z. B. Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform.

Beispielszenario durchgehen, in dem gezeigt wird, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API Monitoring beheben. Sie können beispielsweise eine Benachrichtigung einrichten, um benachrichtigt zu werden, wenn die Anzahl der messaging.adaptors.http.flow.NoActiveTargets-Fehler einen bestimmten Grenzwert überschreitet.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anleitung weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee-Support und geben Sie ihm folgende Informationen:

1. Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
1. Name der Organisation
2. Umgebungsname
3. Name des API-Proxys
4. Vollständiger curl-Befehl zum Reproduzieren des Fehlers
5. Trace-Datei mit den Anfragen mit dem Fehlercode „NoActiveTargets“ und der Fehlermeldung „503 Service Unavailable“
2. Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
   1. Vollständige Fehlermeldung
   2. Umgebungsname
   3. API-Proxy-Bundle
   4. Trace-Datei mit den Anfragen mit dem Fehlercode „NoActiveTargets“ und der Fehlermeldung „503 Service Unavailable“
   5. NGINX-Zugriffslogs

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

   6. Logs des Message Processors

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