504 Gateway-Zeitüberschreitung

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

Symptom

Die Clientanwendung erhält als Antwort auf die API-Aufrufe den HTTP-Statuscode 504 mit der Meldung Gateway Timeout.

Der HTTP-Statuscode – 504 Gateway Timeout-Fehler gibt an, dass der Client während der Ausführung einer API keine zeitnahe Antwort vom Edge-Gateway oder Backend-Server erhalten hat.

Fehlermeldungen

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 504 Gateway Timeout

In einigen Fällen kann auch die folgende Fehlermeldung angezeigt werden:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Was verursacht Gateway-Timeouts?

Der typische Pfad für eine API-Anfrage über die Edge-Plattform ist Client -> Router -> Message Processor -> Backend-Server, wie in der Abbildung unten dargestellt:

Die Clientanwendung, Router und Message Processor in der Edge-Plattform sind mit geeigneten Zeitlimitwerten eingerichtet. Die Edge-Plattform erwartet, dass für jede API-Anfrage innerhalb eines bestimmten Zeitraums eine Antwort gesendet wird, die auf den Zeitüberschreitungswerten basiert. Wenn Sie die Antwort nicht innerhalb des angegebenen Zeitraums erhalten, wird 504 Gateway Timeout Error zurückgegeben.

In der folgenden Tabelle finden Sie weitere Informationen dazu, wann in Edge Zeitüberschreitungen auftreten können:

Mögliche Ursachen

In Edge sind die typischen Ursachen für den Fehler 504 Gateway Timeout:

Langsamer Backend-Server

Wenn der Backend-Server sehr langsam ist oder die Verarbeitung der API-Anfrage lange dauert, erhalten Sie den Fehler 504 Gateway Timeout. Wie oben beschrieben, kann das Zeitlimit in einem der folgenden Szenarien überschritten werden:

1. Das Zeitlimit für den Message Processor wird überschritten, bevor der Backend-Server antwortet.
2. Das Zeitlimit des Routers wird überschritten, bevor der Message Processor oder der Backend-Server antwortet.
3. Die Clientanwendung hat ein Zeitlimit überschritten, bevor der Router, der Message Processor oder der Backend-Server geantwortet hat.

In den folgenden Abschnitten wird beschrieben, wie Sie das Problem in den einzelnen Szenarien diagnostizieren und beheben.

Szenario 1 Zeitüberschreitung des Message Processors, bevor der Backend-Server antwortet

Diagnose

Mit den folgenden Verfahren können Sie feststellen, ob der 504 Gateway Timeout-Fehler aufgrund des langsamen Backend-Servers aufgetreten ist.

Verfahren 1: Trace verwenden

Wenn das Problem weiterhin besteht (504-Fehler treten weiterhin auf), führen Sie die folgenden Schritte aus:

1. Verfolgen Sie die betroffene API in der Edge-UI. Warten Sie, bis der Fehler auftritt, oder führen Sie einige API-Aufrufe aus, um den Fehler 504 Gateway Timeout zu reproduzieren.
2. Sehen Sie sich nach dem Auftreten des Fehlers die spezifische Anfrage an, für die der Antwortcode 504 angezeigt wird.
3. Prüfen Sie die verstrichene Zeit in jeder Phase und notieren Sie sich die Phase, in der die meiste Zeit verbracht wird.
4. Wenn der Fehler mit der längsten verstrichenen Zeit unmittelbar nach einer der folgenden Phasen auftritt, deutet dies darauf hin, dass der Backend-Server langsam ist oder lange braucht, um die Anfrage zu verarbeiten:
   • Anfrage an Zielserver gesendet
   • ServiceCallout-Richtlinie

Das folgende Beispiel zeigt einen Trace, aus dem hervorgeht, dass der Back-End-Server auch nach 55 Sekunden nicht geantwortet hat, was zu einem 504 Gateway Timeout-Fehler geführt hat:

Im obigen Trace tritt nach 55.002 ms ein Zeitüberschreitungsfehler auf dem Message Processor auf, da der Backend-Server nicht antwortet.

Verfahren 2: Logs des Message Processors verwenden

1. Log des Nachrichtenprozessors prüfen (/opt/apigee/var/log/edge-message-processor/logs/system.log)

2. Wenn Sie für die jeweilige API-Proxy-Anfrage zur entsprechenden Zeit Gateway Timeout- und onTimeoutRead-Fehler finden, deutet dies darauf hin, dass das Zeitlimit für den Message Processor überschritten wurde.

   Beispiel für Message Processor-Log mit Gateway-Timeout-Fehler

   2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
   ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
   AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
   Timeout)
   2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
   NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
   SSLClientChannel[C:XX.XX.XX.XX:443 Remote
   host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
   bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

   Im obigen Message Processor-Log sehen Sie, dass der Back-End-Server mit der IP-Adresse XX.XX.XX.XX auch nach 55 Sekunden (lastIO=55000ms) nicht geantwortet hat. Daher ist für den Message Processor ein Zeitüberschreitungsfehler aufgetreten und der Fehler 504 Gateway Timeout wurde gesendet.

   Weitere Informationen finden Sie unter „Wie wird das Zeitlimit für Message Processor gesteuert?“. Wie wird das Zeitlimit für den Message Processor gesteuert? Für Message Processors wird in der Regel über die Eigenschaft HTTPTransport.io.timeout.millis ein Standardwert für das Zeitlimit von 55 Sekunden festgelegt. Dieses Zeitlimit gilt für alle API-Proxys, die zu einer Organisation gehören, die von diesem Message Processor verarbeitet wird. Wenn der Backend-Server nicht innerhalb von 55 Sekunden antwortet, tritt auf dem Message Processor ein Zeitüberschreitungsfehler auf und der Fehler 504 Gateway Timeout wird an den Client gesendet. Das im Message Processor angegebene Zeitlimit kann durch das im API-Proxy angegebene Attribut io.timeout.millis überschrieben werden. Dieser Zeitüberschreitungswert gilt für einen bestimmten API-Proxy, in dem das oben genannte Attribut angegeben ist. Wenn beispielsweise io.timeout.millis im API-Proxy auf 10 Sekunden festgelegt ist, wird für diesen bestimmten API-Proxy der Zeitlimitwert von 10 Sekunden verwendet. Wenn der Backend-Server für den jeweiligen API-Proxy nicht innerhalb von 10 Sekunden antwortet, tritt für den Message Processor ein Zeitlimit auf und er sendet den Fehler 504 Gateway Timeout an den Client.

Auflösung

1. Prüfen Sie, warum der Back-End-Server mehr als 55 Sekunden benötigt, und sehen Sie nach, ob das Problem behoben oder der Server optimiert werden kann, damit er schneller reagiert.
2. Wenn es nicht möglich ist, den Backend-Server zu korrigieren/optimieren, oder wenn bekannt ist, dass der Backend-Server länger als das konfigurierte Zeitlimit benötigt, erhöhen Sie den Zeitlimitwert auf Router und Message Processor auf einen geeigneten Wert.

Szenario 2: Router-Zeitüberschreitung, bevor Message Processor/Backend-Server antwortet

504 Gateway Timeout-Fehler können auftreten, wenn das Zeitlimit des Routers überschritten wird, bevor der Message Processor oder der Backend-Server antwortet. Das kann unter folgenden Umständen passieren:

• Das im Router festgelegte Zeitlimit ist kürzer als das im Message Processor festgelegte Zeitlimit. Angenommen, das Zeitlimit für den Router beträgt 50 Sekunden und das für den Message Processor 55 Sekunden.

  Zeitüberschreitung auf dem Router	Zeitüberschreitung beim Message Processor
  50 Sekunden	55 Sekunden

• Der Zeitlimitwert im Message Processor wird mit einem höheren Zeitlimitwert überschrieben, indem die Eigenschaft io.timeout.millis in der TargetEndpoint-Konfiguration des API-Proxys festgelegt wird:

  Wenn beispielsweise die folgenden Zeitüberschreitungswerte festgelegt sind:

  Zeitüberschreitung auf dem Router	Zeitüberschreitung beim Message Processor	Zeitüberschreitung im API-Proxy
  57 Sekunden	55 Sekunden	120 Sekunden

  Der io.timeout.millis ist im API-Proxy jedoch auf 120 Sekunden festgelegt:

  <HTTPTargetConnection>
       <Properties>
            <Property name="io.timeout.millis">120000</Property>
        </Properties>
        <URL>http://www.apigee.com</URL>
  </HTTPTargetConnection>

  In diesem Fall tritt im Nachrichtenprozessor nach 55 Sekunden keine Zeitüberschreitung auf, obwohl der Zeitüberschreitungswert (55 Sekunden) niedriger ist als der Zeitüberschreitungswert des Routers (57 Sekunden). Das liegt daran, dass das Zeitlimit von 55 Sekunden auf dem Message Processor durch den Wert von 120 Sekunden überschrieben wird, der im API-Proxy festgelegt ist. Das Zeitlimit des Message Processor für diesen bestimmten API-Proxy beträgt also 120 Sekunden.

  Da der Router einen niedrigeren Zeitüberschreitungswert (57 Sekunden) als die im API-Proxy festgelegten 120 Sekunden hat, tritt für den Router eine Zeitüberschreitung auf, wenn der Backend-Server nach 57 Sekunden nicht antwortet.

Diagnose

1. NGINX-Zugriffslog prüfen (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. Wenn das Zeitlimit des Routers vor dem des Message Processors abläuft, sehen Sie in den NGINX-Zugriffsprotokollen für die jeweilige API-Anfrage den Status 504 und der message id des Message Processors wird auf - gesetzt. Das liegt daran, dass der Router innerhalb des auf dem Router festgelegten Zeitlimits keine Antwort vom Message Processor erhalten hat.

   Beispiel für einen NGINX-Logeintrag mit dem Fehlercode 504 aufgrund eines Router-Time-outs

   

3. Im obigen Beispiel sehen Sie den Status von 504 auf NGINX, die Nachrichten-ID des Message Processors ist - und die insgesamt verstrichene Zeit beträgt 57, 001 Sekunden. Das liegt daran, dass das Zeitlimit des Routers nach 57,001 Sekunden überschritten wurde und wir keine Antwort vom Message Processor erhalten haben.
4. In diesem Fall sehen Sie Broken Pipe-Ausnahmen in den Logs des Nachrichtenprozessors (/opt/apigee/var/log/edge-message-processor/logs/system.log).

   2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
   2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
   java.io.IOException: Broken pipe
           at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
            … <snipped>

Dieser Fehler wird angezeigt, weil der Router nach Ablauf des Zeitlimits die Verbindung zum Message Processor schließt. Wenn der Message Processor die Verarbeitung abgeschlossen hat, versucht er, die Antwort an den Router zu schreiben. Da die Verbindung zum Router bereits geschlossen ist, erhalten Sie die Broken Pipe exception auf dem Message Processor.

Diese Ausnahme ist unter den oben beschriebenen Umständen zu erwarten. Die eigentliche Ursache für den 504 Gateway Timeout-Fehler ist also weiterhin, dass der Backend-Server länger für die Antwort benötigt. Sie müssen dieses Problem beheben.

Auflösung

1. Wenn es sich um einen benutzerdefinierten Backend-Server handelt, gehen Sie so vor:
   1. Prüfen Sie, warum der Back-End-Server so lange für die Antwort benötigt, und sehen Sie nach, ob das Problem behoben oder der Server optimiert werden kann, damit er schneller reagiert.
   2. Wenn es nicht möglich ist, den Backend-Server zu korrigieren oder zu optimieren, oder wenn bekannt ist, dass der Backend-Server lange braucht, erhöhen Sie den Zeitüberschreitungswert auf Router und Message Processor.

      Idee: Legen Sie den Zeitlimitwert für die verschiedenen Komponenten in der folgenden Reihenfolge fest: Zeitlimit für Client > Zeitlimit für Router > Zeitlimit für Message Processor > Zeitlimit für API-Proxy

2. Wenn es sich um einen NodeJS-Backend-Server handelt, gilt Folgendes:
   1. Prüfen Sie, ob der NodeJS-Code Aufrufe an andere Back-End-Server sendet und ob es lange dauert, bis eine Antwort zurückgegeben wird. Prüfen Sie, warum die Backend-Server länger brauchen, und beheben Sie das Problem entsprechend.
   2. Prüfen Sie, ob die Message-Prozessoren eine hohe CPU- oder Arbeitsspeichernutzung aufweisen:
      1. Wenn ein Message Processor eine hohe CPU-Auslastung aufweist, generieren Sie alle 30 Sekunden drei Thread-Dumps mit dem folgenden Befehl:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Wenn ein Message Processor eine hohe Arbeitsspeicherauslastung aufweist, generieren Sie mit dem folgenden Befehl einen Heap-Dump:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Starten Sie den Message Processor mit dem folgenden Befehl neu. Dadurch sollte die CPU- und Arbeitsspeichernutzung sinken:

         /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

      4. Beobachten Sie die API-Aufrufe, um zu prüfen, ob das Problem weiterhin besteht.
      5. Wenden Sie sich an den Apigee Edge-Support und stellen Sie die Thread-Dumps, den Heap-Dump und die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)) zur Verfügung, damit die Ursache für die hohe CPU-/Speicherauslastung untersucht werden kann.

Szenario 3: Zeitüberschreitung der Clientanwendung, bevor Router/Message Processor/Backend-Server antwortet

504 Gateway Timeout-Fehler können auftreten, wenn für die Clientanwendung eine Zeitüberschreitung erfolgt, bevor der Backend-Server antwortet. Das kann folgende Ursachen haben:

1. Der in der Clientanwendung festgelegte Zeitlimitwert ist niedriger als der im Router und Message Processor festgelegte Zeitlimitwert:

   Wenn beispielsweise die folgenden Zeitüberschreitungswerte festgelegt sind:

   Zeitüberschreitung auf dem Client	Zeitüberschreitung auf dem Router	Zeitüberschreitung beim Message Processor
   50 Sekunden	57 Sekunden	55 Sekunden

   In diesem Fall beträgt die Gesamtzeit, die für eine Antwort auf eine API-Anfrage über Edge zur Verfügung steht, maximal 50 Sekunden. Dazu gehört die Zeit, die für das Senden einer API-Anfrage benötigt wird, die Verarbeitung der Anfrage durch Edge (Router, Message Processor), das Senden der Anfrage an den Backend-Server (falls zutreffend), die Verarbeitung der Anfrage durch das Backend und das Senden der Antwort, die Verarbeitung der Antwort durch Edge und das endgültige Zurücksenden der Antwort an den Client.

   Wenn der Router nicht innerhalb von 50 Sekunden auf den Client reagiert, tritt beim Client eine Zeitüberschreitung auf und die Verbindung zum Router wird geschlossen. Der Client erhält den Antwortcode 504.

   Dadurch wird in NGINX der Statuscode 499 festgelegt, der angibt, dass der Client die Verbindung geschlossen hat.

Diagnose

1. Wenn die Clientanwendung das Zeitlimit überschreitet, bevor sie eine Antwort vom Router erhält, wird die Verbindung zum Router geschlossen. In diesem Fall wird in den NGINX-Zugriffsprotokollen für die jeweilige API-Anfrage der Statuscode 499 angezeigt.

   Beispiel für einen NGINX-Logeintrag mit dem Statuscode 499
   
   

2. Im obigen Beispiel sehen Sie, dass der Status von 499 auf dem NGINX und die insgesamt verstrichene Zeit 50,001 Sekunden betragen. Das bedeutet, dass das Zeitlimit des Clients nach 50,001 Sekunden überschritten wurde.
3. In diesem Fall sehen Sie Broken Pipe-Ausnahmen in den Logs des Nachrichtenprozessors (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   ).

   2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
   2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
   java.io.IOException: Broken pipe
           at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
            … <snipped>

4. Nachdem das Zeitlimit des Routers abgelaufen ist, wird die Verbindung zum Message Processor geschlossen. Wenn der Message Processor die Verarbeitung abgeschlossen hat, versucht er, die Antwort an den Router zu schreiben. Da die Verbindung zum Router bereits geschlossen ist, erhalten Sie die Broken Pipe exception im Message Processor.
5. Diese Ausnahme ist unter den oben beschriebenen Umständen zu erwarten. Die eigentliche Ursache für den 504 Gateway Timeout-Fehler ist also weiterhin, dass der Backend-Server lange zum Antworten braucht. Sie müssen dieses Problem beheben.

Auflösung

1. Wenn es sich um Ihren benutzerdefinierten Backend-Server handelt, gehen Sie so vor:
   1. Prüfen Sie den Back-End-Server, um herauszufinden, warum er mehr als 57 Sekunden benötigt, und ob das Problem behoben oder der Server optimiert werden kann, damit er schneller reagiert.
   2. Wenn es nicht möglich ist, den Backend-Server zu korrigieren/optimieren, oder wenn Sie wissen, dass der Backend-Server lange Zeit in Anspruch nehmen wird, erhöhen Sie den Zeitüberschreitungswert auf dem Router und dem Message Processor.
      
      

      Idee: Legen Sie den Zeitlimitwert für die verschiedenen Komponenten in der folgenden Reihenfolge fest: Zeitlimit für Client > Zeitlimit für Router > Zeitlimit für Message Processor > Zeitlimit für API-Proxy

2. Wenn es sich um ein NodeJS-Backend handelt, gilt Folgendes:
   1. Prüfen Sie, ob der NodeJS-Code Aufrufe an andere Back-End-Server sendet und ob die Rückgabe lange dauert. Prüfen Sie, warum die Antwortzeit dieser Backend-Server länger ist.
   2. Prüfen Sie, ob die Message Processors eine hohe CPU- oder Arbeitsspeichernutzung aufweisen:
      1. Wenn ein Message Processor eine hohe CPU-Auslastung aufweist, generieren Sie alle 30 Sekunden drei Thread-Dumps mit dem folgenden Befehl:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Wenn ein Message Processor eine hohe Arbeitsspeichernutzung aufweist, generieren Sie mit dem folgenden Befehl einen Heap-Dump:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Starten Sie den Message Processor mit dem folgenden Befehl neu. Dadurch sollte die CPU- und Arbeitsspeicherauslastung sinken:

         /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

      4. Beobachten Sie die API-Aufrufe, um zu prüfen, ob das Problem weiterhin besteht.
      5. Wenden Sie sich an den Apigee Edge-Support und stellen Sie die Thread-Dumps, den Heap-Dump und die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)) zur Verfügung, damit die Ursache für die hohe CPU- und Speicherauslastung untersucht werden kann.

Zeitlimit für Router und Message Processor erhöhen

Wählen Sie die Zeitlimitwerte für den Router und den Message Processor sorgfältig entsprechend Ihren Anforderungen aus. Legen Sie keine beliebig großen Zeitlimitwerte fest. Wenn Sie Unterstützung benötigen, wenden Sie sich an den Apigee Edge-Support.

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties

1. Erstellen Sie die Datei /opt/apigee/customer/application/router.properties auf dem Router, falls sie noch nicht vorhanden ist.
2. Fügen Sie der Datei die folgende Zeile hinzu:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

   Wenn Sie beispielsweise ein Zeitlimit von 120 Sekunden festlegen möchten, gehen Sie so vor:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

3. Prüfen Sie, ob die Datei „apigee“ gehört:
4. Router neu starten:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

5. Wenn Sie mehr als einen Router haben, wiederholen Sie die obigen Schritte auf allen Routern.

Message Processor

1. Erstellen Sie die Datei /opt/apigee/customer/application/message-processor.properties auf dem Message Processor-Computer, falls sie noch nicht vorhanden ist.
2. Fügen Sie der Datei die folgende Zeile hinzu:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   Wenn Sie beispielsweise ein Zeitlimit von 120 Sekunden festlegen möchten, gehen Sie so vor:

   conf_http_HTTPTransport.io.timeout.millis=120000

3. Prüfen Sie, ob die Datei „apigee“ gehört:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Starten Sie den Message Processor neu:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

5. Wenn Sie mehr als einen Message Processor haben, wiederholen Sie die obigen Schritte für alle Message Processors.

Langsame API-Anfrageverarbeitung durch Edge

Wenn Edge sehr langsam ist und/oder die Verarbeitung der API-Anfrage lange dauert, erhalten Sie den Fehler 504 Gateway Timeout.

Diagnose

1. Verfolgen Sie die betroffene API in der Edge-UI.
2. Warten Sie entweder, bis der Fehler auftritt, oder führen Sie einige API-Aufrufe aus, um den Fehler 504 Gateway Timeout zu reproduzieren.
3. In diesem Fall wird im Trace möglicherweise eine Erfolgsmeldung angezeigt.
   1. Für den Router/Client tritt ein Zeitüberschreitungsfehler auf, da der Message Processor nicht innerhalb des auf dem Router/Client angegebenen Zeitlimits antwortet (je nachdem, welches Zeitlimit kürzer ist). Der Message Processor verarbeitet die Anfrage jedoch weiter und kann sie erfolgreich abschließen.
   2. Außerdem wird der im Message Processor festgelegte HTTPTransport.io.timeout.millis-Wert nur ausgelöst, wenn der Message Processor mit einem HTTP/HTTPS-Backend-Server kommuniziert. Mit anderen Worten: Dieses Zeitlimit wird nicht ausgelöst, wenn eine Richtlinie (außer der ServiceCallout-Richtlinie) im API-Proxy lange dauert.
4. Sehen Sie sich nach dem Auftreten des Fehlers die Anfrage mit der längsten verstrichenen Zeit an.
5. Prüfen Sie die verstrichene Zeit in jeder Phase und notieren Sie sich die Phase, in der die meiste Zeit benötigt wird.
6. Wenn Sie die längste verstrichene Zeit in einer der Richtlinien beobachten, die nicht die ServiceCallout-Richtlinie ist, deutet dies darauf hin, dass Edge lange für die Verarbeitung der Anfrage benötigt.
7. Hier ist ein Beispiel für einen UI-Trace mit einer sehr hohen verstrichenen Zeit für die JavaScript-Richtlinie:

   

8. Im obigen Beispiel sehen Sie, dass die JavaScript-Richtlinie mit etwa 245 Sekunden ungewöhnlich lange dauert.

Auflösung

1. Prüfen Sie, ob die Antwort auf die Richtlinie lange gedauert hat und ob es benutzerdefinierten Code gibt, dessen Verarbeitung lange dauern könnte. Wenn solcher Code vorhanden ist, prüfen Sie, ob Sie den identifizierten Code korrigieren oder optimieren können.
2. Wenn kein benutzerdefinierter Code vorhanden ist, der eine lange Verarbeitungszeit verursachen könnte, prüfen Sie, ob die Nachrichtenprozessoren eine hohe CPU- oder Arbeitsspeichernutzung aufweisen:
   1. Wenn ein Message Processor eine hohe CPU-Auslastung aufweist, generieren Sie alle 30 Sekunden drei Thread-Dumps mit dem folgenden Befehl:

      JAVA_HOME/bin/jstack -l PID > FILENAME

   2. Wenn ein Message Processor eine hohe Arbeitsspeicherauslastung aufweist, generieren Sie mit dem folgenden Befehl einen Heap-Dump:

      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

   3. Starten Sie den Message Processor mit dem folgenden Befehl neu. Dadurch sollten die CPU- und Arbeitsspeicherauslastung sinken.

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

   4. Beobachten Sie die API-Aufrufe und prüfen Sie, ob das Problem weiterhin besteht.
   5. Wenden Sie sich an den Apigee Edge-Support und stellen Sie die Thread-Dumps, den Heap-Dump und die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)) zur Verfügung, damit die Ursache für die hohe CPU- und Speicherauslastung untersucht werden kann.

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 504-Statuscodes einen bestimmten Grenzwert überschreitet.