503 Dienst nicht verfügbar – NoActiveTargets – HealthCheckFailures

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

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 Nicht verfügbar und dem Fehlercode NoActiveTargets für die API-Proxy-Anfragen.

Fehlermeldung

Sie erhalten die folgende Fehlerantwort:

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 Nicht verfügbar mit dem Fehlercode NoActiveTargets wird in der Regel beobachtet, wenn Sie einen oder mehrere Zielserver in der Zielendpunktkonfiguration in Ihrem API-Proxy verwenden.

Dieses Playbook behandelt 503 Service Nicht verfügbar mit dem Fehlercode NoActiveTargets, der durch fehlgeschlagene Systemdiagnosen verursacht wird. Informationen zu anderen Ursachen für diesen Fehler finden Sie in diesem Playbook.

Fehler bei Systemdiagnosen

Fehler bei der Systemdiagnose werden nur beobachtet, wenn Sie eine Systemdiagnose 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 die Fehleranzahl dieses Servers. Wenn die Anzahl der Fehler bei der Systemdiagnose für diesen Server den vordefinierten Grenzwert (<MaxFailures>) erreicht, protokolliert der Message Processor die Warnmeldung wie unten gezeigt in der Protokolldatei:

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 besser nachvollziehen, welcher Zielserver die Anzahl von MaxFailure erreicht hat:

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

Danach stoppt Edge das Senden weiterer Anfragen an diesen bestimmten Server. Sobald alle in der LoadBalancer-Konfiguration konfigurierten Zielserver die Anzahl von MaxFailure erreicht haben, werden die nachfolgenden API-Anfragen mit 503 Service Nicht verfügbar mit dem Fehlercode NoActiveTargets.

Mithilfe von Health Monitor kann Apigee Edge automatisch einen Zielserver wieder in die Rotation aufnehmen, wenn er fehlerfrei ist, ohne den API-Proxy noch einmal bereitstellen zu müssen.

Dies sind die möglichen Ursachen für das Fehlschlagen der Systemdiagnose:

Allgemeine Diagnoseschritte

Nachrichten-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 Back-End-Server herzustellen, werden in den Message Processor-Protokollen einige häufige Fehlermeldungen angezeigt. Diese Fehler werden nach der tatsächlichen Ausnahme/Fehlermeldung protokolliert, die zum Fehler geführt hat.

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

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 zeigen an, dass die Anfrage aufgrund eines Fehlers nicht an den Back-End-Server gesendet werden konnte. Infolgedessen sendet der Message Processor den Fehler 503 Service Nicht verfügbar mit dem Fehlercode NoActiveTargets als Antwort an den Client.

Ursache: Zeitüberschreitung bei Verbindung

Diagnose

1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Ihnen werden die häufigen Fehlermeldungen entsprechend der Nachrichten-ID angezeigt. Wenn Sie jedoch die tatsächliche Ursache für die Fehler bei der Systemdiagnose ermitteln möchten, scrollen Sie über diesen häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler vorliegen.

   Die folgende HEALTH MONITOR-Fehlermeldung besagt beispielsweise, dass beim Senden der API-Anfrage für die Systemdiagnose ein Verbindungsfehler aufgrund eines Zeitüberschreitungsfehlers vom Message Processor aufgetreten 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 in der Gesundheitsüberwachung konfiguriert ist, wird eine Warnmeldung wie die folgende 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 sich die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der in dem spezifischen API-Proxy verwendet wird, bei dem der 503-Antwortcode mit dem Fehlercode NoActiveTargets auftritt.

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

telnet <BackendServer-HostName> 443
      

5. Wenn Sie eine Verbindung zum Back-End-Server herstellen können, wird möglicherweise eine Meldung wie Mit Back-End-Server verbunden angezeigt. Dann kann es sich um ein vorübergehendes Problem handeln, das entweder behoben oder nur zeitweise auftritt. Wiederholen Sie Schritt 4 mehrmals (mehr als zehnmal) und prüfen Sie die Ausgabe.
1. Wenn beim Befehl telnet immer wieder Fehler auftreten, ist das Problem behoben. Prüfen Sie noch einmal, ob die Fehler bei der Systemdiagnose nicht mehr auftreten. Wenn ja, müssen Sie nichts weiter tun.
2. Wenn Sie ab und zu mit dem Befehl telnet keine Verbindung zum Back-End-Server herstellen können, liegt möglicherweise ein Netzwerkproblem vor oder Ihr Back-End-Server ist überlastet.
6. Wenn Sie mit dem Befehl telnet keine konsistente Verbindung zum Back-End-Server herstellen können, liegt dies möglicherweise daran, dass der Datenverkehr von den Message Processorn auf dem spezifischen Back-End-Server nicht zugelassen wird.

Auflösung

Wenn der Fehler connection timed out regelmäßig beobachtet wird, sorgen Sie dafür, dass der Back-End-Server keine Firewalleinschränkungen hat und den Traffic von den Apigee Edge-Nachrichtenprozessoren zulässt. Unter Linux könnten Sie beispielsweise iptables verwenden, um den Traffic von den IP-Adressen des Message Processor auf dem Back-End-Server zuzulassen.

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

Ursache: Sichere Anfrage an nicht sicherem Port

Diagnose

1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Ihnen werden die häufigen Fehlermeldungen für die jeweilige Nachrichten-ID angezeigt. Wenn Sie jedoch die tatsächliche Ursache der Fehler bei der Systemdiagnose ermitteln möchten, scrollen Sie über diesen häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler vorliegen.

   Es kann beispielsweise ein HEALTH MONITOR-Fehler angezeigt werden:

   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 in der Gesundheitsüberwachung konfiguriert ist, wird eine Warnmeldung wie die folgende 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 sich die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der in dem spezifischen API-Proxy verwendet wird, bei dem der 503-Antwortcode mit dem Fehlercode NoActiveTargets auftritt.

4. Die Systemdiagnose ist mit folgendem 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 weisen darauf hin, dass das Problem darauf zurückzuführen ist, dass ein sicherer Aufruf (HTTPS) auf dem nicht sicheren Port 80 ausgeführt wurde.

   Dieser Fehler kann in den folgenden beiden Szenarien auftreten:

   • Sicherer Zielserver mit nicht sicherem Port definiert
   • Sicherer Zielserver definiert, aber Health Monitor wurde mit einem nicht sicheren Port konfiguriert

   Sicherer nicht sicherer Zielport

   Szenario 1: Sicherer Zielserver mit nicht sicherem Port definiert

   Wenn Sie einen sicheren Zielserver mit einem nicht sicheren Port wie 80 definiert haben, wird dieser Fehler angezeigt. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache für das Problem ist:

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

   Verwenden Sie Get TargetServer API, um die Zielserverdefinition abzurufen.

   Ausgabe der Zielserverdefinition

   <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 Block SSLInfo angegeben. Er ist jedoch mit einem nicht sicheren Port 80 konfiguriert.

   2. Prüfen Sie jetzt die Health Monitor-Konfiguration für den Zielserver in der Konfiguration des Zielendpunkts:

      Konfiguration der Gesundheitsüberwachung

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

      In der obigen Konfiguration der Gesundheitsüberwachung ist kein <Port>-Element angegeben. In diesem Fall verwendet der Message Processor von Edge den in der Zielserverdefinition angegebenen Port (80) für API-Aufrufe der Systemdiagnose.

   3. Basierend auf den obigen Informationen besteht die Ursache für diesen Fehler darin, dass der Zielserver als sicherer Server definiert ist, da der SSLInfo-Block aktiviert ist, aber mit einem nicht sicheren Port 80.

   Sicherer nicht sicherer Zielport

   Szenario 2: Sicherer Zielserver definiert, aber Health Monitor ist mit einem nicht sicheren Port konfiguriert

   Wenn Sie einen sicheren Zielserver definiert haben, die Gesundheitsüberwachung jedoch mit einem nicht sicheren Port wie 80 konfiguriert ist, erhalten Sie diesen Fehler. Prüfen Sie anhand der folgenden Schritte, ob das Problem dadurch verursacht wurde:

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

      Verwenden Sie Get TargetServer API, um die Zielserverdefinition abzurufen.

      Ausgabe der Zielserverdefinition

      <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 Block SSLInfo angegeben.

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

      Konfiguration der Gesundheitsüberwachung

      <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 die Gesundheitsüberwachung mit einem nicht sicheren Port 80 konfiguriert, wie durch das Element <Port> angegeben.

   3. Basierend auf den obigen Informationen besteht die Ursache für diesen Fehler darin, dass der Zielserver als sicherer Server definiert ist (wenn der Block SSLInfo aktiviert ist) und den sicheren Port 443 verwendet. Die Systemdiagnose ist jedoch so konfiguriert, dass Systemdiagnosen mit dem nicht sicheren Port 80 (angegeben im Element <Port>) durchgeführt werden.

      Das heißt, in diesem Fall macht Edge die Systemdiagnose APIs als sicheren Aufruf mit dem nicht sicheren Port 80 und schlägt mit dem oben genannten Fehler fehl.

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 an einem sicheren Port

Diagnose

1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Ihnen werden die häufigen Fehlermeldungen entsprechend der Nachrichten-ID angezeigt. Wenn Sie jedoch die tatsächliche Ursache der Fehler bei der Systemdiagnose ermitteln möchten, scrollen Sie über diesen häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler vorliegen.

   Es kann beispielsweise ein HEALTH MONITOR-Fehler angezeigt werden:

   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 in der Gesundheitsüberwachung konfiguriert ist, wird eine Warnmeldung wie die folgende 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 sich die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der in dem spezifischen API-Proxy verwendet wird, bei dem der 503-Antwortcode mit dem Fehlercode NoActiveTargets auftritt.

4. Die Systemdiagnose ist mit folgendem 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 dadurch verursacht wird, dass ein nicht sicherer Aufruf (HTTP) über den sicheren Port 443 ausgeführt wurde.

   Dieser Fehler kann in den folgenden beiden Szenarien auftreten:

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

   Nicht sicherer Zielport

   Szenario 1: Nicht sicherer Zielserver mit sicherem Port definiert

   Wenn Sie einen nicht sicheren Zielserver, aber mit einem sicheren Port wie 443 definiert haben, wird dieser Fehler angezeigt. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache für das Problem ist:

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

      Verwenden Sie Get TargetServer API, um die Zielserverdefinition abzurufen.

      Ausgabe der Zielserverdefinition

      <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. Es ist jedoch falsch konfiguriert mit einem sicheren Port 443.

   2. Prüfen Sie jetzt die Health Monitor-Konfiguration für den Zielserver in der Konfiguration des Zielendpunkts:

      Konfiguration der Gesundheitsüberwachung

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

      In der obigen Konfiguration der Gesundheitsüberwachung ist kein <Port>-Element angegeben. In diesem Fall verwendet der Message Processor von Edge den in der Zielserverdefinition angegebenen Port, nämlich 443.

   3. Basierend auf den obigen Informationen besteht die Ursache für diesen Fehler darin, dass der Zielserver als nicht sicherer Server definiert ist, da der SSLInfo-Block nicht definiert ist, sondern als sicherer Port 443.

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

   Nicht sicherer Zielport für sicheren HM-Port

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

   Wenn Sie einen nicht sicheren Zielserver definiert haben, die Gesundheitsüberwachung aber mit einem sicheren Port wie 443 konfiguriert ist, wird dieser Fehler angezeigt. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache für das Problem ist:

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

      Verwenden Sie Get TargetServer API, um die Zielserverdefinition abzurufen.

      Ausgabe der Zielserverdefinition

      <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 es keinen SSLInfo-Block gibt), der mit einem nicht sicheren Port 80 richtig konfiguriert ist.

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

      Konfiguration der Gesundheitsüberwachung

      <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 die Gesundheitsüberwachung mit einem sicheren Port 443 konfiguriert, wie durch das Element <Port> angegeben.

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

      Das heißt, in diesem Fall führt Edge die Systemdiagnosen als nicht sicherer 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. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Ihnen werden die häufigen Fehlermeldungen für die jeweilige Nachrichten-ID angezeigt. Wenn Sie jedoch die tatsächliche Ursache für die Fehler bei der Systemdiagnose ermitteln möchten, scrollen Sie über diesen häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler/-Warnungen vorliegen.

   Es kann beispielsweise eine GESUNDHEITSMONITOR-Warnung angezeigt werden, 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 in der Gesundheitsüberwachung konfiguriert ist, wird eine Warnmeldung wie die folgende 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 sich die Informationen in der Warnmeldung sorgfältig durch. Prüfen Sie, ob die Anzahl von MaxFailure für einen Zielserver erreicht wurde, der in dem spezifischen API-Proxy verwendet wird, bei dem der 503-Antwortcode mit dem Fehlercode NoActiveTargets auftritt.

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
         

   Die obige Warnmeldung besagt, dass der erwartete Antwortcode für die Health Check API 200 war, aber die tatsächliche Antwort 404 lautet. Dies wird als Fehler behandelt.

5. Bevor Sie die Ursache für die Fehlerantwort von der Systemdiagnose-API untersuchen, ermitteln Sie, warum Edge für die Systemdiagnose-API den Antwortcode 200 erwartet. Prüfen Sie dazu die Health Monitor-Konfiguration für den Zielserver in der Zielendpunktkonfiguration:

   Konfiguration der Gesundheitsüberwachung

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

   Die Health Monitor-Konfiguration ist mit dem Antwortcode 200 unter dem Element <SuccessResponse> konfiguriert. Wenn Edge also einen anderen Antwortcode (z. B. 400, 401, 404, 500) als 200 von der API für die Systemdiagnose abruft, wird dies als Fehler behandelt und die Fehleranzahl erhöht.

6. Führen Sie nun die folgenden Schritte aus, um die Ursache für die Fehlerantwort von der Systemdiagnose-API zu untersuchen:
1. Sehen Sie sich die Nachricht vor der Warnmeldung im Message Processor-Protokoll 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 Systemdiagnose-URL aus dieser Nachricht.

2. Sie können diese URL vom Message Processor direkt aufrufen und die tatsächliche Antwort prüfen.

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

   Die Antwort auf den obigen Aufruf gibt den 404-Fehler zurück, wie in den Message Processor-Protokollen zu sehen:

   < HTTP/2 404
             

3. Dies zeigt, dass auch der direkte Aufruf der Systemdiagnose-URL mit demselben Antwortcode 404 fehlschlägt. Das bedeutet, dass die URL für die Systemdiagnose möglicherweise falsch ist oder die Ressource, auf die als Teil der URL zugegriffen wird, nicht mehr verfügbar ist.
4. In der oben genannten Beispiel-API für die Systemdiagnose tritt das Problem auf, weil in der Health Monitor-Konfiguration eine falsche URL verwendet wurde. Die richtige URL war https://mocktarget.apigee.net:443/statuscode/200 von der Mock Target API.
7. Wenn Sie eine andere Fehlerantwort erhalten, ermitteln Sie die Ursache. Gehen Sie dazu wie oben beschrieben vor. Wenden Sie sich bei Bedarf an Ihr Back-End-Team.

Auflösung

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

   <Path>/statuscode/200</Path>
           

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

Wenn das Problem weiterhin besteht, lesen Sie den Abschnitt Diagnoseinformationen müssen erfasst werden.

Probleme mithilfe des API-Monitoring diagnostizieren

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

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

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem nach Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen. Kontaktieren Sie sie und geben Sie sie für den Apigee-Support frei:

1. Wenn Sie die öffentliche Cloud nutzen, geben Sie die folgenden Informationen an:
1. Name der Organisation
2. Name der Umgebung
3. API-Proxy-Name
4. Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren
5. Ablaufverfolgungsdatei mit den Anfragen, bei denen der Fehler 503 „Dienst nicht verfügbar“ mit dem Fehlercode „NoActiveTargets“ ausgegeben wird
2. Wenn Sie die private Cloud nutzen, geben Sie die folgenden Informationen an:
   1. Vollständige Fehlermeldung angezeigt
   2. Name der Umgebung
   3. API-Proxy-Bundle
   4. Ablaufverfolgungsdatei mit den Anfragen, bei denen der Fehler 503 „Dienst nicht verfügbar“ mit dem Fehlercode „NoActiveTargets“ ausgegeben wird
   5. NGINX-Zugriffslogs

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

   6. Message Processor-Protokolle

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