503 Dienst nicht verfügbar – NoActiveTargets – HealthCheckFailures

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie 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 dem Parameter Service Nicht verfügbar und der Fehlercode NoActiveTargets für die API-Proxy-Anfragen.

Fehlermeldung

Sie sehen die folgende Fehlermeldung:

HTTP/1.1 503 Service Unavailable
  

Die HTTP-Antwort enthält die folgende Fehlermeldung:

{
   "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 normalerweise beobachtet wenn Sie einen oder mehrere Zielserver in der Zielendpunktkonfiguration in Ihrem API-Proxy verwenden.

In diesem Playbook wird 503 Service Unavailable mit dem Fehlercode behandelt. NoActiveTargets , die durch fehlgeschlagene Systemdiagnosen verursacht wurden. In diesem Playbook finden Sie Informationen zu anderen Ursachen dieses Fehlers.

Fehler bei Systemdiagnosen

Die fehlgeschlagenen Systemdiagnosen werden nur beobachtet, wenn Sie eine <ph type="x-smartling-placeholder"></ph> Health Monitor als Teil der Load-Balancing-Konfiguration des Zielservers im Zielendpunkt Ihres API-Proxys.

Wenn ein Zielserver eine Systemdiagnose nicht besteht, erhöht Edge die Fehleranzahl dieses Servers. Wenn die Anzahl der fehlgeschlagenen Systemdiagnosen für diesen Server den vordefinierten Schwellenwert (<MaxFailures>) erreicht, Der Message Processor protokolliert die Warnmeldung wie unten dargestellt in seiner 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 beendet Edge das Senden weiterer Anfragen an diesen spezifischen Server. Sobald alle Ziel-CPA-Gebote Server, die in der LoadBalancer-Konfiguration konfiguriert sind, erreichen die Anzahl MaxFailure, die nachfolgende API-Anfragen werden mit 503 Service Unavailable und Fehlercode NoActiveTargets beantwortet.

Mit Health Monitor kann Apigee Edge automatisch einen Zielserver wieder in den eine Rotation, wenn sie fehlerfrei ist, ohne den API-Proxy noch einmal bereitstellen zu müssen.

Mögliche Ursachen für fehlgeschlagene Systemdiagnosen:

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 herstellen, werden in der Datei Message Processor-Logs. Diese Fehler werden nach der eigentlichen Ausnahme-/Fehlermeldung protokolliert. die zum Scheitern geführt hat.

Die häufigsten Fehlermeldungen in Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) für den 503 Service Unavailable mit dem Fehlercode NoActiveTargets 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 Fehler. Infolgedessen sendet der Message Processor die Meldung 503 Service Nicht verfügbar. 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 Message Processor-Protokoll nach der Nachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Sie sehen die häufigen Fehlermeldungen für die entsprechende Nachrichten-ID. Sie können jedoch Um die tatsächliche Ursache für das Fehlschlagen der Systemdiagnose zu sehen, scrollen Sie über diese häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler vorliegen.

   Die folgende HEALTH MONITOR-Fehlermeldung zeigt beispielsweise an, dass der Message Processor fehlgeschlagen ist mit dem Fehler "Verbindungszeitüberschreitung" beim Ausführen der API-Anfrage zur Systemdiagnose:

   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 sich dieser Fehler MaxFailure-mal wiederholt in der Gesundheitsüberwachung konfiguriert hat, sehen Sie eine Warnmeldung wie die folgende:

   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. Achten Sie darauf, dass die MaxFailure Die Anzahl wurde für einen Zielserver erreicht, der in dem spezifischen API-Proxy verwendet wird, für den Sie arbeiten. Der Antwortcode 503 mit dem Fehlercode NoActiveTargets wird angezeigt.

4. Im obigen Beispiel ist die Systemdiagnose mit dem Fehler connection timed out fehlgeschlagen. Prüfen Sie, ob Sie von jedem der beiden Message Processor mit dem Befehl telnet:

telnet <BackendServer-HostName> 443
      

5. Wenn Sie eine Verbindung zum Backend-Server herstellen können, wird möglicherweise eine Meldung wie diese angezeigt: Mit einem Back-End-Server verbunden Dann könnte es sich um ein vorübergehendes Problem ist das Problem möglicherweise behoben oder es handelt sich um ein zeitweise auftretendes Problem. Wiederholen Sie Schritt 4 einige Male. (mehr als zehnmal) und überprüfen Sie die Ausgabe.
1. Wenn beim Befehl telnet immer keine Fehler auftreten, liegt das Problem behoben. Prüfen Sie noch einmal, ob die fehlgeschlagenen Systemdiagnosen gestoppt wurden. Wenn ja, müssen Sie nichts weiter tun noch etwas weiter.
2. Wenn Sie nicht ab und zu mit dem Befehl telnet eine Verbindung zum Backend-Server herstellen können: liegt möglicherweise ein Netzwerkproblem vor oder dein Backend-Server ist ausgelastet.
6. Wenn Sie mit dem Befehl telnet nicht konsistent eine Verbindung zum Backend-Server herstellen können, liegt das möglicherweise daran, dass der Datenverkehr von den Message Processors auf dem jeweiligen Back-End-Server nicht zugelassen ist.

Auflösung

Wenn der Fehler connection timed out immer wieder auftritt, achten Sie darauf, dass das Back-End keine Firewall-Einschränkungen hat und den Traffic von den Apigee Edge-Nachrichtenprozessoren zulässt. Unter Linux könnten Sie iptables verwenden, um den Traffic vom IP-Adressen des Message Processor auf dem Backend-Server.

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 an den Apigee-Support.

Ursache: Sichere Anfrage über nicht sicheren Port

Diagnose

1. Ermitteln 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. Sie sehen die häufigen Fehlermeldungen, die der Nachrichten-ID entsprechen. Wenn Sie die tatsächliche Ursache für das Fehlschlagen der Systemdiagnose sehen möchten, scrollen Sie über diese häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler vorliegen.

   Es kann beispielsweise der folgende 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 sich dieser Fehler MaxFailure-mal wiederholt in der Gesundheitsüberwachung konfiguriert hat, 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. Achten Sie darauf, dass die MaxFailure Die Anzahl wurde für einen Zielserver erreicht, der in dem spezifischen API-Proxy verwendet wird, für den Sie arbeiten. Der Antwortcode 503 mit dem Fehlercode NoActiveTargets wird angezeigt.

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 auf die Ursache dieses Problems hin, sicherer Aufruf (HTTPS) über den nicht sicheren Port 80 gesendet

   Dieser Fehler kann in den folgenden beiden Szenarien auftreten:

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

   Sicherer nicht sicherer Zielport

   Szenario 1: Sicherer Zielserver mit nicht sicherem Port definiert

   Wenn Sie einen sicheren Zielserver definiert haben, jedoch mit einem nicht sicheren Port wie 80, erhalten Sie Fehler. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Problem dadurch verursacht wurde:

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

   Verwenden Sie die Methode TargetServer API abrufen um die Zielserverdefinition zu erhalten.

   Ausgabe der Zielserverdefinition

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

   Im Beispiel oben zeigt die Definition, dass der Zielserver mocktarget ein sicherer ist. wie durch den Block SSLInfo angegeben. Er ist jedoch mit einem nicht sicheren Port 80 konfiguriert.

   2. Prüfen Sie nun 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>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      Beachten Sie, dass kein <Port>-Element in der Health Monitor-Konfiguration oben. In diesem Fall verwendet der Message Processor des Edges den Port in der Zielserverdefinition (80) zum Ausführen von API-Aufrufen zur Systemdiagnose angegeben.

   3. Die Ursache für diesen Fehler ist, dass der Zielserver als sicherer Server definiert (wenn der SSLInfo-Block aktiviert ist), aber mit einem nicht sicheren Port 80.

   Sicherer nicht sicherer HM-Port als Ziel

   Szenario 2: Sicherer Zielserver definiert, aber Zustandsüberwachung ist mit einem nicht sicheren Port konfiguriert

   Wenn Sie einen sicheren Zielserver definiert haben, aber die Zustandsüberwachung mit einem nicht sicheren Port 80 ist, erhalten Sie diese Fehlermeldung. Führen Sie zur Bestätigung die folgenden Schritte aus: Wenn das die Ursache des Problems ist:

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

      Verwenden Sie die Methode Rufen Sie die TargetServer API ab, um die Zielserverdefinition zu erhalten.

      Ausgabe der Zielserverdefinition

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

      Im Beispiel oben 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. Gemäß den obigen Informationen ist die Ursache für diesen Fehler, dass der Zielserver definiert wurde, als sicherer Server (bei aktiviertem SSLInfo-Block) und verwendet den sicheren Port 443, aber die Health Monitor-Funktion ist so konfiguriert, dass Systemdiagnosen mit einem nicht sicheren Port 80 durchgeführt werden (angegeben im <Port>-Element).

      Das heißt, in diesem Fall führt Edge die Systemdiagnose-APIs als sicheren Aufruf mit 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. Ermitteln 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. Sie sehen die häufigen Fehlermeldungen für die entsprechende Nachrichten-ID. Wenn Sie die tatsächliche Ursache für das Fehlschlagen der Systemdiagnose sehen möchten, scrollen Sie über diese häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler vorliegen.

   Es kann beispielsweise der folgende 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 sich dieser Fehler MaxFailure-mal wiederholt in der Gesundheitsüberwachung konfiguriert hat, 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. Achten Sie darauf, dass die MaxFailure Die Anzahl wurde für einen Zielserver erreicht, der in dem spezifischen API-Proxy verwendet wird, für den Sie arbeiten. Der Antwortcode 503 mit dem Fehlercode NoActiveTargets wird angezeigt.

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 auf die Ursache dieses Problems hin, Nicht sicherer Aufruf (HTTP) über den sicheren Port 443 ausgeführt.

   Dieser Fehler kann in den folgenden beiden Szenarien auftreten:

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

   Nicht sicherer sicherer Zielport

   Szenario 1: Nicht sicherer Zielserver mit sicherem Port definiert

   Wenn Sie einen nicht sicheren Zielserver definiert haben, aber mit einem sicheren Port wie 443, erhalten Sie diesen Fehler. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Problem dadurch verursacht wurde:

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

      Verwenden Sie die Methode Rufen Sie die TargetServer API ab, um die Zielserverdefinition zu erhalten.

      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 ist ein nicht sicherer Server, da kein SSLInfo-Block vorhanden ist. Allerdings ist es fälschlicherweise konfiguriert mit dem sicheren Port 443.

   2. Prüfen Sie nun 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>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      Beachte, dass in der Gesundheitsüberwachung kein <Port>-Element angegeben ist. Konfiguration oben. In diesem Fall verwendet der Message Processor des Edges den Port, der in Zielserverdefinition, nämlich 443.

   3. Gemäß den obigen Informationen ist die Ursache für diesen Fehler, dass der Zielserver definiert wurde, als nicht sicherer Server (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 durch und schlägt fehl mit dem oben genannten Fehler.

   Nicht sicherer sicherer HM-Zielport

   Szenario 2: Ein nicht sicherer Zielserver ist definiert, aber die Zustandsüberwachung ist mit einem sicheren Port konfiguriert

   Wenn Sie einen nicht sicheren Zielserver definiert haben, aber die Zustandsüberwachung mit einem sicheren Port wie 443 konfiguriert ist, erhalten Sie diesen Fehler. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Problem dadurch verursacht wurde:

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

      Verwenden Sie die Methode Rufen Sie die TargetServer API ab, um die Zielserverdefinition zu erhalten.

      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 ist (da kein SSLInfo-Block vorhanden ist), der richtig mit einem nicht sicheren Port 80 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 Beispiel oben ist die Gesundheitsüberwachung mit einem sicheren Port 443 konfiguriert, wie durch das Element <Port> angegeben.

   3. Nach den obigen Informationen besteht die Ursache für diesen Fehler darin, dass der Zielserver als einen nicht sicheren Server mit dem nicht sicheren Port 80, da der SSLInfo-Block nicht definiert ist, Die Gesundheitsüberwachung ist jedoch so konfiguriert, dass Systemdiagnosen über den sicheren Port 443 (angegeben im Element <Port>) durchgeführt werden.

      Das heißt, in diesem Fall führt Edge die Systemdiagnosen als nicht sicheren Aufruf mit dem sicheren Port 443 durch 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 Message Processor-Protokoll nach der Nachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Daraufhin werden häufige Fehlermeldungen für die jeweilige Meldungs-ID angezeigt. Wenn Sie die tatsächliche Ursache für das Fehlschlagen der Systemdiagnose sehen möchten, scrollen Sie über diese häufigen Fehlermeldungen und prüfen Sie, ob HEALTH MONITOR-Fehler/-Warnungen zurückgegeben werden.

   Es kann beispielsweise eine HEALTH MONITOR-Warnung angezeigt werden:

   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 sich dieser Fehler MaxFailure-mal wiederholt in der Gesundheitsüberwachung konfiguriert hat, 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. Achten Sie darauf, dass die MaxFailure Die Anzahl wurde für einen Zielserver erreicht, der in dem spezifischen API-Proxy verwendet wird, für den Sie arbeiten. Der Antwortcode 503 mit dem Fehlercode NoActiveTargets wird angezeigt.

4. Die Systemdiagnose hat 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 Systemdiagnose-API 200 war, aber die tatsächliche Antwort lautet 404. Daher wird dies als Fehler behandelt.

5. Bevor Sie die Ursache für die Fehlerantwort der Systemdiagnose-API untersuchen, ermitteln Sie, warum Edge erwartet als Antwortcode für die Systemdiagnose-API 200. Sehen Sie dazu in der 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 <SuccessResponse>-Element konfiguriert. Wenn Edge also einen anderen Antwortcode (z. B. 400, 401, 404, 500) als 200 von der Systemdiagnose-API erhält, behandelt er sie als Fehler und erhöht die Fehleranzahl.

6. Gehen Sie nun so vor, um die Ursache für die Fehlerantwort 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 direkt vom Message Processor aus aufrufen und die tatsächliche Antwort überprüfen.

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

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

   < HTTP/2 404
             

3. Das zeigt, dass selbst 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 als Teil der URL zugegriffen wird, nicht mehr verfügbar ist.
4. In der oben bereitgestellten Beispiel-Systemdiagnose-API tritt das Problem auf, weil in der Health Monitor-Konfiguration eine falsche URL verwendet wurde. Die richtige URL lautet https://mocktarget.apigee.net:443/statuscode/200 von Mock Target API.
7. Wenn Sie eine andere Fehlerantwort erhalten, ermitteln Sie die Ursache dafür, indem Sie den oben beschrieben. Wenden Sie sich bei Bedarf an Ihr Backend-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 erläuterten Beispiel:
1. Ändern Sie das Element <Path> in der Health Monitor-Konfiguration zu /statuscode/200, wie unten gezeigt:

   <Path>/statuscode/200</Path>
           

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

Wenn das Problem weiterhin besteht, gehe zu Es müssen Diagnoseinformationen erfasst werden.

Probleme mithilfe von API-Monitoring diagnostizieren

Mit der API-Überwachung können Sie Probleme Fehler-, Leistungs- und Latenzprobleme sowie deren Quelle schnell diagnostizieren, z. B. Entwickler Anwendungen, API-Proxys, Back-End-Zielen oder die API-Plattform.

Schritt durch ein Beispielszenario zeigt, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API-Monitoring beheben können. Beispiel: können Sie eine Benachrichtigung einrichten, damit Sie informiert werden, sobald die Anzahl der messaging.adaptors.http.flow.NoActiveTargets Fehler einen bestimmten Schwellenwert überschreiten.

Erfassen von Diagnoseinformationen erforderlich

Falls das Problem auch nach Ausführung der obigen Anleitung weiterhin besteht, stellen Sie folgende Daten zusammen: Diagnosedaten. Teilen Sie sie dem Apigee-Support mit:

1. Wenn Sie ein Nutzer der öffentlichen Cloud sind, 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 an den Dienst "503 Service Unavailable" mit Fehlercode "NoActiveTargets"
2. Wenn Sie ein Nutzer der Private Cloud sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
   </ph>
   1. Vollständige Fehlermeldung beobachtet
   2. Name der Umgebung
   3. API-Proxy-Bundle
   4. Ablaufverfolgungsdatei mit den Anfragen an den Dienst "503 Service Unavailable" mit Fehlercode "NoActiveTargets"
   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)