504 Gateway-Zeitüberschreitung

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

Symptom

Die Clientanwendung empfängt den HTTP-Statuscode 504 mit der Nachricht Gateway Timeout als Antwort auf die API-Aufrufe.

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

Fehlermeldungen

Die Clientanwendung ruft den folgenden Antwortcode ab:

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 führt zu Gateway-Zeitüberschreitungen?

Typischer Pfad für eine API-Anfrage über die Edge-Plattform ist Client -> Router -> Message Processor -> Back-End-Server, wie in der folgenden Abbildung dargestellt:

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

Die folgende Tabelle enthält weitere Details dazu, wann Zeitüberschreitungen in Edge auftreten können:

Zeitüberschreitung Details
Zeitüberschreitung beim Message Processor
  • Der Back-End-Server reagiert nicht innerhalb eines festgelegten Zeitlimits auf den Message Processor.
  • Message Processor läuft ab und sendet den Antwortstatus 504 Gateway Timeout an den Router.
Zeitüberschreitung auf dem Router
  • Message Processor reagiert nicht innerhalb des auf dem Router angegebenen Zeitlimits auf den Router.
  • Der Router überschreitet das Zeitlimit und sendet den Antwortstatus 504 Gateway Timeout an die Clientanwendung.
Zeitüberschreitung bei Clientanwendung
  • Der Router reagiert nicht innerhalb des auf dem Router angegebenen Zeitlimits auf die Clientanwendung.
  • Bei der Clientanwendung tritt eine Zeitüberschreitung auf und beendet den Antwortstatus für den Endnutzer als 504 Gateway Timeout.

Mögliche Ursachen

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

Ursache Details Schritte für
Langsamer Back-End-Server Der Back-End-Server, der die API-Anfrage verarbeitet, ist aufgrund hoher Last oder schlechter Leistung zu langsam. Nutzer öffentlicher und privater Clouds
Langsame API-Anfrageverarbeitung durch Edge Die Verarbeitung der API-Anfrage durch Edge aufgrund hoher Last oder schlechter Leistung dauert sehr lange.

Langsamer Back-End-Server

Wenn der Back-End-Server sehr langsam ist oder die Verarbeitung der API-Anfrage lange dauert, wird der Fehler 504 Gateway Timeout angezeigt. Wie im Abschnitt oben erläutert, kann das Zeitlimit in einem der folgenden Szenarien auftreten:

  1. Message Processor überschreitet das Zeitlimit, bevor der Back-End-Server antwortet.
  2. Der Router überschreitet das Zeitlimit, bevor der Message Processor/Back-End-Server antwortet.
  3. Bei der Clientanwendung tritt eine Zeitüberschreitung auf, bevor der Router/Nachrichtenprozessor/Back-End-Server antwortet.

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

Szenario 1 Der Message Processor überschreitet das Zeitlimit, bevor der Back-End-Server antwortet

Diagnose

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

Prozedur 1: Trace verwenden

Wenn das Problem weiterhin besteht (504 Fehler treten immer noch auf), gehen Sie so vor:

  1. Verfolgen Sie die betroffene API in der Edge-Benutzeroberfläche. Warten Sie entweder, bis der Fehler auftritt, oder führen Sie nach dem API-Aufruf einige API-Aufrufe aus und reproduzieren Sie den Fehler 504 Gateway Timeout.
  2. Sobald der Fehler aufgetreten ist, prüfen Sie die Anfrage, in der der Antwortcode als 504 angezeigt wird.
  3. Prüfen Sie in jeder Phase die verstrichene Zeit und notieren Sie sich die Phase, in der Sie die meiste Zeit aufgewendet haben.
  4. Wenn direkt nach einer der folgenden Phasen der Fehler mit der längsten verstrichenen Zeit auftritt, weist dies darauf hin, dass der Back-End-Server langsam ist oder die Verarbeitung der Anfrage sehr lange dauert:
    • Anfrage an Zielserver gesendet
    • ServiceCallout policy

Das folgende Beispiel zeigt ein Trace-Beispiel, das zeigt, dass der Back-End-Server auch nach 55 Sekunden nicht reagiert hat, was zu einem 504 Gateway Timeout-Fehler führte:

Im obigen Trace tritt das Zeitlimit des Message Processor nach 55.002 ms ab, da der Back-End-Server nicht antwortet.

Prozedur Nr. 2 Nachrichtenprozessorprotokolle verwenden

  1. Protokoll des Message Processor prüfen (/opt/apigee/var/log/edge-message-processor/logs/system.log)

  2. Wenn zu dieser Zeit für eine bestimmte API-Proxy-Anfrage Gateway Timeout- und onTimeoutRead-Fehler auftreten, ist eine Zeitüberschreitung beim Message Processor aufgetreten.

    Beispiel für ein Message Processor-Log mit Gateway-Zeitüberschreitungsfehler

    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 nicht geantwortet hat (lastIO=55000ms). Infolgedessen kam es bei Message Processor zu einer Zeitüberschreitung und es gab 504 Gateway Timeout Fehler.

    Überprüfen Sie Folgendes: Wie wird das Zeitlimit von Message Processor gesteuert?

    • Wie wird das Zeitlimit von Message Processor gesteuert? Nachrichtenprozessoren werden normalerweise mit einem Standardzeitlimit von 55 Sekunden über das Attribut HTTPTransport.io.timeout.millis festgelegt. Dieser Zeitüberschreitungswert gilt für alle API-Proxys, die zu einer von diesem Message Processor bereitgestellten Organisation gehören.
      • Wenn der Back-End-Server nicht innerhalb von 55 Sekunden antwortet, überschreitet der Nachrichtenprozessor das Zeitlimit und sendet den Fehler 504 Gateway Timeout an den Client.
    • Der im Message Processor angegebene Zeitüberschreitungswert kann durch die im API-Proxy angegebene Eigenschaft io.timeout.millis überschrieben werden. Dieser Zeitüberschreitungswert gilt für einen bestimmten API-Proxy, in dem das oben genannte Attribut angegeben ist. Wenn io.timeout.millis beispielsweise im API-Proxy auf 10 Sekunden festgelegt ist, wird für diesen spezifischen API-Proxy das Zeitlimit von 10 Sekunden verwendet.
      • Wenn der Back-End-Server für den jeweiligen API-Proxy nicht innerhalb von 10 Sekunden antwortet, kommt es zu einer Zeitüberschreitung des Message Processor und 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 prüfen Sie, ob er behoben oder für eine schnellere Reaktion optimiert werden kann.
  2. Wenn der Back-End-Server nicht repariert oder optimiert werden kann oder bekannt ist, dass der Back-End-Server mehr Zeit als das konfigurierte Zeitlimit benötigt, erhöhe den Wert für das Zeitlimit auf Router und Message Processor auf einen geeigneten Wert.

Szenario 2: Der Router überschreitet das Zeitlimit, bevor der Message Processor/Back-End-Server antwortet

Wenn der Router das Zeitlimit überschreitet, bevor der Nachrichtenprozessor/Back-End-Server antwortet, erhalten Sie möglicherweise 504 Gateway Timeout-Fehler. Dies kann unter folgenden Umständen passieren:

  • Das Zeitlimit, das auf dem Router eingestellt ist, ist kürzer als das Zeitlimit, das auf dem Message Processor festgelegt wurde. Beispiel: Das Zeitlimit des Routers beträgt 50 Sekunden, während der Message Processor 55 Sekunden beträgt.
    Zeitüberschreitung auf dem Router Zeitüberschreitung beim Message Processor
    50 Sekunden 55 Sekunden
  • Der Zeitüberschreitungswert auf dem Message Processor wird mit einem höheren Zeitlimit überschrieben. Dazu wird das Attribut io.timeout.millis in der Zielendpunktkonfiguration des API-Proxys verwendet:

    Beispiel für folgende Zeitüberschreitungswerte:

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

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

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

    Dann tritt nach 55 Sekunden keine Zeitüberschreitung des Message Processor ein, auch wenn das Zeitlimit (55 Sekunden) unter dem Zeitlimit des Routers (57 Sekunden) liegt. Dies liegt daran, dass der Zeitüberschreitungswert von 55 Sekunden auf dem Message Processor durch den Wert von 120 Sekunden überschrieben wird, der im API-Proxy festgelegt ist. Der Zeitüberschreitungswert des Message Processor für diesen spezifischen API-Proxy beträgt also 120 Sekunden.

    Da der Router einen niedrigeren Zeitüberschreitungswert (57 Sekunden) als 120 Sekunden hat, der im API-Proxy festgelegt ist, tritt beim Router eine Zeitüberschreitung auf, wenn der Back-End-Server nicht nach 57 Sekunden antwortet.

Diagnose

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

  2. Wenn beim Router vor dem Message Processor eine Zeitüberschreitung auftritt, wird in den NGINX-Zugriffslogs für die jeweilige API-Anfrage der Status 504 angezeigt. Außerdem wird der message id des Message Processor als - festgelegt. 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 Fehler 504 aufgrund einer Zeitüberschreitung des Routers

  3. Beachten Sie im obigen Beispiel den Status von 504 in NGINX, die Nachrichten-ID vom Nachrichtenprozessor lautet - und die verstrichene Gesamtzeit beträgt 57.001 Sekunden. Dies liegt daran, dass es nach 57.001 Sekunden zu einer Zeitüberschreitung des Routers kam und wir keine Antwort vom Message Processor erhalten haben.
  4. In diesem Fall werden Broken Pipe-Ausnahmen in den Message Processor-Logs angezeigt (/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, da beim Router die Verbindung zum Message Processor beendet wird. Wenn der Message Processor seine Verarbeitung abgeschlossen hat, versucht er, die Antwort an den Router zu schreiben. Da die Verbindung zum Router bereits getrennt ist, wird das Broken Pipe exception auf dem Message Processor angezeigt.

Diese Ausnahme sollte unter den oben beschriebenen Umständen auftreten. Die tatsächliche Ursache für den Fehler 504 Gateway Timeout ist also immer noch, dass der Back-End-Server mehr Zeit für die Antwort benötigt und Sie dieses Problem beheben müssen.

Auflösung

  1. Bei einem benutzerdefinierten Back-End-Server gilt:
    1. Prüfen Sie, warum der Back-End-Server so lange reagiert, und prüfen Sie, ob er korrigiert/optimiert werden kann, um eine schnellere Antwort zu liefern.
    2. Wenn sich der Back-End-Server nicht reparieren bzw. optimieren lässt oder bekannt ist, dass der Back-End-Server sehr lange braucht, Erhöhen Sie den Zeitüberschreitungswert auf dem Router und dem Message Processor.

      Idee: Legen Sie den Zeitüberschreitungswert für die verschiedenen Komponenten in der folgenden Reihenfolge fest:

      Zeitlimit auf Client > Zeitlimit auf Router > Zeitlimit auf Nachrichtenprozessor > Zeitlimit im API-Proxy
  2. Wenn es sich um einen NodeJS-Back-End-Server handelt, dann gilt:
    1. Prüfen Sie, ob der NodeJS-Code Aufrufe an andere Back-End-Server sendet und ob die Rückgabe einer Antwort lange dauert. Prüfen Sie, warum die Back-End-Server länger benötigen, und beheben Sie das Problem gegebenenfalls.
    2. Prüfen Sie, ob die CPU- oder Arbeitsspeichernutzung der Message Processorn hoch ist:
      1. Wenn ein Message Processor eine hohe CPU-Auslastung aufweist, generieren Sie mit dem folgenden Befehl alle 30 Sekunden drei Thread-Dumps: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Wenn bei einem Message Processor eine hohe Speichernutzung auftritt, 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. Es sollte die CPU und den Arbeitsspeicher reduzieren: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Überwachen Sie die API-Aufrufe, um festzustellen, ob das Problem weiterhin besteht.
      5. Wenden Sie sich an den Apigee Edge-Support und senden Sie die Thread-Dumps, Heap-Dumps und Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log), um die Ursache für die hohe CPU-/Arbeitsspeichernutzung zu untersuchen.

Überprüfen: Wie wird das Zeitlimit für NodeJS-Back-End-Server im Message Processor gesteuert?

  • Der NodeJS-Back-End-Server wird im JVM-Prozess des Message Processor ausgeführt. Der Zeitüberschreitungswert für NodeJS-Back-End-Server wird über das Attribut http.request.timeout.seconds in der Datei nodejs.properties gesteuert. Dieses Attribut ist standardmäßig auf 0 gesetzt, d. h., das Zeitlimit ist standardmäßig für alle API-Proxys deaktiviert, die zu einer von diesem Message Processor bereitgestellten Organisation gehören. Selbst wenn ein NodeJS-Back-End-Server lange braucht, kommt es also beim Message Processor zu keiner Zeitüberschreitung.
  • Wenn der Node.js-Back-End-Server jedoch lange dauert und die für die API-Anfrage benötigte Zeit mehr als 57 Sekunden beträgt, löst der Router eine Zeitüberschreitung aus und sendet den Fehler 504 Gateway Timeout an den Client.

Szenario 3: Bei der Clientanwendung tritt eine Zeitüberschreitung auf, bevor der Router/Nachrichtenprozessor/Back-End-Server antwortet

Wenn die Clientanwendung das Zeitlimit überschreitet, bevor der Back-End-Server antwortet, erhalten Sie möglicherweise 504 Gateway Timeout-Fehler. Diese Situation kann in folgenden Fällen auftreten:

  1. Das Zeitlimit, das in der Clientanwendung eingestellt wurde, ist kleiner als das Zeitlimit, das auf dem Router und dem Message Processor eingestellt wurde:

    Beispiel für folgende Zeitüberschreitungswerte:

    Zeitüberschreitung auf 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 verfügbar ist, um eine Antwort auf eine API-Anfrage über Edge zu erhalten, <= 50 Sekunden. Dazu gehören die Zeit, die für eine API-Anfrage benötigt wird, die Anfrage von Edge verarbeitet wird (Router, Message Processor), die Anfrage, die an den Back-End-Server gesendet wird (falls zutreffend), das Back-End, das die Anfrage verarbeitet und die Antwort sendet, die Edge die Antwort verarbeitet und sie schließlich an den Client zurücksendet.

    Wenn der Router nicht innerhalb von 50 Sekunden auf den Client reagiert, kommt es zu einer Zeitüberschreitung und beendet die Verbindung mit dem Router. Der Client erhält den Antwortcode 504.

    Dadurch legt der NGINX-Code den Statuscode 499 fest, der angibt, dass der Client die Verbindung geschlossen hat.

Diagnose

  1. Wenn bei der Clientanwendung eine Zeitüberschreitung auftritt, bevor sie eine Antwort vom Router erhält, wird die Verbindung mit dem Router getrennt. In diesem Fall wird in den NGINX-Zugriffslogs für die jeweilige API-Anfrage der Statuscode 499 angezeigt.

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

  2. Beachten Sie im obigen Beispiel, dass der Status von 499 im NGINX und die verstrichene Gesamtzeit 50,001 Sekunden betragen. Das bedeutet, dass beim Client nach 50,001 Sekunden eine Zeitüberschreitung aufgetreten ist.
  3. In diesem Fall wird Broken Pipe Exceptions in den Message Processor-Logs angezeigt (/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. Sobald für den Router eine Zeitüberschreitung auftritt, wird die Verbindung zum Message Processor geschlossen. Wenn der Message Processor seine Verarbeitung abgeschlossen hat, versucht er, die Antwort an den Router zu schreiben. Da die Verbindung zum Router bereits getrennt ist, wird das Broken Pipe exception auf dem Message Processor angezeigt.
  5. Diese Ausnahme ist unter den oben beschriebenen Umständen zu erwarten. Die tatsächliche Ursache für den Fehler 504 Gateway Timeout ist also immer noch, dass der Back-End-Server lange auf die Antwort benötigt und Sie dieses Problem beheben müssen.

Auflösung

  1. Wenn es sich um Ihren benutzerdefinierten Back-End-Server handelt, gehen Sie so vor:
    1. Überprüfen Sie den Back-End-Server, um festzustellen, warum er mehr als 57 Sekunden benötigt, und prüfen Sie, ob er korrigiert/optimiert werden kann, um eine schnellere Antwort zu liefern.
    2. Wenn es nicht möglich ist, den Back-End-Server zu reparieren bzw. zu optimieren, oder wenn Sie wissen, dass der Back-End-Server viel Zeit benötigt, erhöhe den Zeitüberschreitungswert auf Router und Message Processor.

      Idee: Legen Sie den Zeitüberschreitungswert für die verschiedenen Komponenten in der folgenden Reihenfolge fest:

      Zeitlimit auf Client > Zeitlimit auf Router > Zeitlimit auf Nachrichtenprozessor > Zeitlimit im API-Proxy
  2. Wenn es sich um ein NodeJS-Back-End handelt, dann gilt:
    1. Prüfen Sie, ob der NodeJS-Code Aufrufe an andere Back-End-Server sendet und ob dies lange dauert. Überprüfen Sie, warum diese Back-End-Server länger dauern.
    2. Prüfen Sie, ob die CPU- oder Speichernutzung der Message Processorn hoch ist:
      1. Wenn ein Message Processor eine hohe CPU-Auslastung hat, generieren Sie mit dem folgenden Befehl alle 30 Sekunden drei Thread-Dumps: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Wenn für einen Message Processor eine hohe Speichernutzung besteht, 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. Dies sollte CPU und Arbeitsspeicher reduzieren: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Überwachen Sie die API-Aufrufe, um festzustellen, ob das Problem weiterhin besteht.
      5. Wenden Sie sich an den Apigee Edge-Support und stellen Sie die Thread-Dumps, Heap-Dumps und Message Processor-Logs bereit, /opt/apigee/var/log/edge-message-processor/logs/system.log)damit das Team die Ursache für die hohe CPU-/Arbeitsspeichernutzung untersuchen kann.

Erhöhen Sie den Zeitüberschreitungswert auf dem Router und dem Message Processor

Wählen Sie die Zeitüberschreitungswerte, die auf dem Router und dem Nachrichtenprozessor eingestellt werden sollen, je nach Ihren Anforderungen sorgfältig aus. Legen Sie keine beliebig großen Zeitüberschreitungswerte fest. Wenn Sie Hilfe 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 der Routermaschine, falls sie noch nicht vorhanden ist.
  2. Fügen Sie dieser Datei die folgende Zeile hinzu: 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    Wenn Sie beispielsweise das Zeitlimit von 120 Sekunden festlegen möchten, legen Sie den Wert so fest:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Achten Sie darauf, dass diese Datei zu 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 oben beschriebenen Schritte für alle Router.

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 dieser Datei die folgende Zeile hinzu: 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    Wenn Sie beispielsweise das Zeitlimit von 120 Sekunden festlegen möchten, legen Sie den Wert so fest:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Achten Sie darauf, dass diese Datei zu 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 Processor.

Idee: Legen Sie den Wert für die Zeitüberschreitung auf den verschiedenen Komponenten in der folgenden Reihenfolge fest:

Zeitlimit auf Client > Zeitlimit auf Router > Zeitlimit auf Message Processor > Zeitlimit im API-Proxy

Langsame API-Anfrageverarbeitung durch Edge

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

Diagnose

  1. Verfolgen Sie die betroffene API in der Edge-Benutzeroberfläche.
  2. Warten Sie entweder, bis der Fehler auftritt, oder führen Sie nach dem API-Aufruf einige API-Aufrufe aus und reproduzieren Sie den Fehler 504 Gateway Timeout.
  3. Hinweis: In diesem Fall wird möglicherweise eine erfolgreiche Antwort im Trace angezeigt.
    1. Für den Router/Client tritt eine Zeitüberschreitung auf, da der Message Processor nicht innerhalb des auf dem Router/Client angegebenen Timeout-Zeitraums antwortet (je nachdem, was das kürzeste Timeout hat). Der Message Processor fährt jedoch mit der Verarbeitung der Anfrage fort und kann die Anfrage erfolgreich abschließen.
    2. Darüber hinaus wird der für den Nachrichtenprozessor festgelegte Wert HTTPTransport.io.timeout.millis nur dann ausgelöst, wenn der Nachrichtenprozessor mit einem HTTP-/HTTPS-Back-End-Server kommuniziert. Mit anderen Worten: Dieses Zeitlimit wird nicht ausgelöst, wenn irgendeine Richtlinie (mit Ausnahme der ServiceCallout-Richtlinie) im API-Proxy sehr lange dauert.
  4. Wenn der Fehler aufgetreten ist, prüfen Sie die Anfrage mit der längsten verstrichenen Zeit.
  5. Prüfen Sie in jeder Phase die verstrichene Zeit und notieren Sie sich die Phase, in der Sie die meiste Zeit aufgewendet haben.
  6. Wenn Sie die längste verstrichene Zeit in einer anderen Richtlinie als der Service-Callout-Richtlinie beobachten, weist dies darauf hin, dass Edge die Verarbeitung der Anfrage sehr lange dauert.
  7. Hier ist ein Beispiel-UI-Trace, das eine sehr lange verstrichene Zeit für die JavaScript-Richtlinie zeigt:

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

Auflösung

  1. Prüfen Sie, ob die Antwort auf die Richtlinie lange gedauert hat und ob benutzerdefinierter Code vorhanden ist, dessen Verarbeitung möglicherweise lange dauert. Wenn es einen solchen Code gibt, prüfen Sie, ob Sie den erkannten Code korrigieren/optimieren können.
  2. Wenn kein benutzerdefinierter Code vorhanden ist, der zu einer langen Verarbeitungszeit führen könnte, prüfen Sie, ob die CPU- oder Speichernutzung der Message Processoren hoch ist:
    1. Wenn ein Message Processor eine hohe CPU-Auslastung aufweist, generieren Sie mit dem folgenden Befehl alle 30 Sekunden drei Thread-Dumps: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Wenn ein Message Processor eine hohe Arbeitsspeichernutzung hat, 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. Dies sollte CPU und Arbeitsspeicher reduzieren. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. Überwachen Sie die API-Aufrufe und prüfen Sie, ob das Problem weiterhin besteht.
    5. Wenden Sie sich an den Apigee Edge-Support und geben Sie die Thread-Dumps, Heap-Dumps und Message Processor-Logs an, /opt/apigee/var/log/edge-message-processor/logs/system.log)damit das Team die Ursache für die hohe CPU-/Arbeitsspeichernutzung untersuchen kann.

Probleme mithilfe von API-Monitoring diagnostizieren

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

Arbeiten Sie ein Beispielszenario durch, in dem veranschaulicht wird, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API Monitoring beheben können. Sie können beispielsweise eine Benachrichtigung einrichten, die benachrichtigt wird, wenn die Anzahl der 504-Statuscodes einen bestimmten Grenzwert überschreitet.