504 Gateway-Zeitüberschreitung

Sie lesen die Dokumentation zu Apigee Edge.
Rufen Sie die Dokumentation zu Apigee X auf. Weitere Informationen

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 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 wird möglicherweise auch die folgende Fehlermeldung angezeigt:

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

Was verursacht Gateway-Zeitüberschreitungen?

Ein typischer Pfad für eine API-Anfrage über die Edge-Plattform ist Client -> Router -> Nachrichtenprozessor -> Backend-Server, wie in der folgenden Abbildung dargestellt:

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

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

Zeitüberschreitung Details
Zeitüberschreitung beim Message Processor
  • Der Backend-Server antwortet nicht innerhalb des auf dem Message Processor konfigurierten Zeitlimits auf den Message Processor.
  • Der Nachrichtenprozessor überschreitet das Zeitlimit und sendet den Antwortstatus 504 Gateway Timeout an den Router.
Zeitüberschreitung auf dem Router
  • Der Message Processor antwortet nicht innerhalb des angegebenen Zeitlimits auf dem Router.
  • Der Router löst ein Zeitlimit aus und sendet den Antwortstatus als 504 Gateway Timeout an die Clientanwendung.
Zeitüberschreitung in der Clientanwendung
  • Der Router antwortet nicht innerhalb des angegebenen Zeitlimits auf die Clientanwendung.
  • Die Clientanwendung überschreitet das Zeitlimit und beendet den Antwortstatus mit 504 Gateway Timeout für den Endnutzer.

Mögliche Ursachen

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

Ursache Details Schritte für
Langsamer Back-End-Server Der Backend-Server, der die API-Anfrage verarbeitet, ist aufgrund hoher Auslastung oder schlechter Leistung zu langsam. Nutzer der öffentlichen und privaten Cloud
Langsame Verarbeitung von API-Anfragen durch Edge Edge benötigt für die Verarbeitung der API-Anfrage aufgrund hoher Last oder schlechter Leistung lange Zeit.

Langsamer Backend-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 die Zeitüberschreitung in einem der folgenden Szenarien auftreten:

  1. Beim Message Processor tritt eine Zeitüberschreitung auf, bevor der Backend-Server antwortet.
  2. Der Router überschreitet das Zeitlimit, bevor der Message Processor/Backend-Server antwortet.
  3. Die Clientanwendung löst ein Zeitlimit aus, bevor der Router/Message Processor/Backend-Server antwortet.

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

Szenario 1: Beim Message Processor tritt ein Zeitlimit auf, bevor der Backend-Server antwortet

Diagnose

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

Verfahren 1: Trace verwenden

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

  1. Verfolgen Sie die betroffene API in der Edge-Benutzeroberfläche. Warten Sie entweder, bis der Fehler auftritt, oder führen Sie einige API-Aufrufe aus und reproduzieren Sie den Fehler 504 Gateway Timeout.
  2. Sobald der Fehler aufgetreten ist, prüfen Sie die spezifische Anfrage, in der der Antwortcode als 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 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 lange dauert:
    • Anfrage an Zielserver gesendet
    • ServiceCallout-Richtlinie

Im Folgenden finden Sie ein Beispiel für einen Trace, der zeigt, dass der Back-End-Server auch nach 55 Sekunden nicht reagiert hat, was zu einem 504 Gateway Timeout-Fehler geführt hat:

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

Prozedur Nr. 2: Message Processor-Logs verwenden

  1. Prüfen Sie das Protokoll des Nachrichtenprozessors (/opt/apigee/var/log/edge-message-processor/logs/system.log).

  2. Wenn Sie für die API-Proxy-Anfrage zu der bestimmten Zeit Gateway Timeout- und onTimeoutRead-Fehler feststellen, ist die Zeitüberschreitung für den Message Processor abgelaufen.

    Beispiel für ein Message Processor-Log mit einem 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 Protokoll des Nachrichten-Prozessors 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 beim Message Processor zu einer Zeitüberschreitung und hat 504 Gateway Timeout Fehler gesendet.

    Wie wird die Zeitüberschreitung beim Message Processor gesteuert?

    • Wie wird das Zeitlimit für den Message Processor gesteuert? Message Processors haben normalerweise einen Standardwert für die Zeitüberschreitung von 55 Sekunden, der über die Property HTTPTransport.io.timeout.millis festgelegt wird. Dieser Zeitlimitwert gilt für alle API-Proxys, die zu einer Organisation gehören, die von diesem Message Processor bedient wird.
      • Wenn der Backend-Server nicht innerhalb von 55 Sekunden antwortet, läuft die Zeitüberschreitung des Message Processor ab und er sendet den Fehler 504 Gateway Timeout an den Client.
    • Der im Nachrichtenprozessor angegebene Zeitlimitwert kann durch die im API-Proxy angegebene Property io.timeout.millis überschrieben werden. Dieser Zeitüberschreitungswert gilt für einen bestimmten API-Proxy, in dem die oben genannte Property angegeben ist. Wenn beispielsweise io.timeout.millis im API-Proxy auf 10 Sekunden festgelegt ist, wird für diesen API-Proxy ein Zeitlimit von 10 Sekunden verwendet.
      • Wenn der Backend-Server für den jeweiligen API-Proxy nicht innerhalb von 10 Sekunden antwortet, tritt beim Message Processor ein Zeitüberschreitungsfehler auf und der Client erhält den Fehler 504 Gateway Timeout.

Auflösung

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

Szenario #2: Der Router löst ein Zeitlimit aus, bevor der Message Processor/Backend-Server antwortet

Möglicherweise erhalten Sie 504 Gateway Timeout-Fehler, wenn der Router ein Zeitlimit erreicht, bevor der Message Processor/Backend-Server antwortet. Das kann unter folgenden Umständen passieren:

  • Das Zeitlimit, das auf dem Router festgelegt ist, ist kürzer als das Zeitlimit, das auf dem Message Processor festgelegt ist. Angenommen, das Zeitlimit für den Router beträgt 50 Sekunden, während es für den Message Processor 55 Sekunden ist.
    Zeitüberschreitung auf dem Router Zeitüberschreitung beim Nachrichtenprozessor
    50 Sekunden 55 Sekunden
  • Der Zeitlimitwert für den Message Processor wird mithilfe des Attributsatzes io.timeout.millis in der Zielendpunktkonfiguration des API-Proxys überschrieben:

    Angenommen, die folgenden Zeitüberschreitungswerte sind festgelegt:

    Zeitüberschreitung auf dem Router Zeitüberschreitung beim Message Processor Zeitüberschreitung innerhalb des API-Proxys
    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 führt der Message Processor nach 55 Sekunden kein Zeitlimit aus, obwohl der Zeitlimitwert (55 Sekunden) unter dem Zeitlimitwert des Routers (57 Sekunden) liegt. Das liegt daran, dass das Zeitlimit von 55 Sekunden im Message Processor durch den Wert von 120 Sekunden überschrieben wird, der im API-Proxy festgelegt ist. Das Zeitlimit des Message Processors für diesen API-Proxy beträgt also 120 Sekunden.

    Da der Router ein niedrigeres Zeitlimit (57 Sekunden) als die 120 Sekunden hat, die im API-Proxy festgelegt sind, tritt beim Router eine Zeitüberschreitung auf, wenn der Backend-Server nach 57 Sekunden nicht antwortet.

Diagnose

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

  2. Wenn das Zeitlimit für den Router vor dem Message Processor erreicht wird, wird in den NGINX-Zugriffsprotokollen für die jeweilige API-Anfrage der Status 504 angezeigt und der message id vom Message Processor 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 504 aufgrund einer Router-Zeitüberschreitung

  3. Im obigen Beispiel ist der Status 504 in NGINX zu sehen.Die Nachrichten-ID vom Message Processor ist - und die Gesamtzeit beträgt 57,001 Sekunden. Das liegt daran, dass der Router nach 57.001 Sekunden eine Zeitüberschreitung anzeigte und wir keine Antwort vom Message Processor erhalten haben.
  4. In diesem Fall werden in den Logs des Nachrichtenprozessors Broken Pipe Ausnahmen 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, weil der Router nach Ablauf der Zeitüberschreitung 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, wird die Broken Pipe exception am Message Processor angezeigt.

Diese Ausnahme ist unter den oben genannten Umständen zu erwarten. Die tatsächliche Ursache für den 504 Gateway Timeout-Fehler ist also weiterhin, dass der Backend-Server zu lange zum Ansprechen braucht. Sie müssen dieses Problem beheben.

Auflösung

  1. Bei einem benutzerdefinierten Backend-Server gilt Folgendes:
    1. Prüfen Sie, warum der Back-End-Server so lange braucht, um zu antworten, und ob er repariert oder optimiert werden kann, damit er schneller reagiert.
    2. Wenn es nicht möglich ist, den Backend-Server zu reparieren oder zu optimieren, oder wenn bekannt ist, dass der Backend-Server viel Zeit in Anspruch nimmt, erhöhen Sie den Zeitüberschreitungswert für Router und Message Processor.

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

      Zeitlimit auf Client > Zeitüberschreitung auf dem Router > Zeitüberschreitung im Nachrichtenprozessor > Zeitüberschreitung im API-Proxy
  2. Wenn es sich um einen NodeJS-Backend-Server handelt, gehen Sie so vor:
    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 Back-End-Server länger brauchen, und beheben Sie das Problem gegebenenfalls.
    2. Prüfen Sie, ob die CPU- oder Arbeitsspeicherauslastung der Nachrichten-Prozessoren hoch ist:
      1. Wenn bei einem Nachrichtenprozessor eine hohe CPU-Auslastung auftritt, generieren Sie alle 30 Sekunden mit dem folgenden Befehl drei Thread-Dumps: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Wenn bei einem Nachrichtenprozessor eine hohe Arbeitsspeichernutzung 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 Nachrichten-Prozessor mit dem folgenden Befehl neu. Die CPU- und Arbeitsspeichernutzung sollte sinken: 
        /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 ihm die Thread-Dumps, Heap-Dumps und die Protokolle der Message Processors (/opt/apigee/var/log/edge-message-processor/logs/system.log)), damit er die Ursache für die hohe CPU-/Speichernutzung ermitteln kann.

Prüfen Sie Folgendes: Wie wird der Zeitüberschreitung für NodeJS-Backend-Server auf dem Message Processor gesteuert?

  • Der NodeJS-Backend-Server wird im JVM-Prozess des Message Processor ausgeführt. Der Zeitlimitwert 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. Das Zeitlimit ist also standardmäßig für alle API-Proxys deaktiviert, die zu einer Organisation gehören, die von diesem Message Processor bedient wird. Selbst wenn ein NodeJS-Backend-Server lange braucht, tritt beim Message Processor kein Zeitlimit auf.
  • Wenn der NodeJS-Backend-Server jedoch zu lange braucht und die API-Anfrage mehr als 57 Sekunden dauert, tritt eine Zeitüberschreitung auf dem Router auf und der 504 Gateway Timeout-Fehler wird an den Client gesendet.

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

Sie erhalten möglicherweise 504 Gateway Timeout-Fehler, wenn das Zeitlimit der Clientanwendung überschritten wird, bevor der Back-End-Server antwortet. Das kann in folgenden Fällen passieren:

  1. Der für die Clientanwendung festgelegte Zeitlimitwert ist niedriger als der für den Router und den Nachrichtenprozessor festgelegte Zeitlimitwert:

    Angenommen, die folgenden Zeitüberschreitungswerte sind festgelegt:

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

    In diesem Fall beträgt die Gesamtzeit, die für den Empfang einer Antwort auf eine API-Anfrage über Edge zur Verfügung steht, weniger als 50 Sekunden. Dies umfasst die Zeit, die zum Stellen einer API-Anfrage benötigt wird, die von Edge verarbeitete Anfrage (Router, Message Processor), die Anfrage, die an den Back-End-Server gesendet wird (falls zutreffend), die Verarbeitung der Anfrage und das Senden der Antwort durch das Back-End, die Verarbeitung der Antwort durch Edge und die anschließende Rücksendung an den Client.

    Wenn der Router nicht innerhalb von 50 Sekunden auf den Client antwortet, 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 bei der Clientanwendung eine Zeitüberschreitung auftritt, bevor sie eine Antwort vom Router erhält, wird die Verbindung mit dem Router beendet. 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. Im obigen Beispiel ist der Status von 499 in NGINX „ok“ und die Gesamtzeit beträgt 50.001 Sekunden. Dies bedeutet, dass beim Client nach 50,001 Sekunden eine Zeitüberschreitung aufgetreten ist.
  3. In diesem Fall werden in den Logs des Nachrichtenprozessors Broken Pipe Ausnahmen 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. Nach einer Zeitüberschreitung des Routers wird die Verbindung mit dem Message Processor geschlossen. Wenn der Nachrichtenprozessor die Verarbeitung abgeschlossen hat, versucht er, die Antwort an den Router zu schreiben. Da die Verbindung zum Router bereits geschlossen ist, wird die Broken Pipe exception am Message Processor angezeigt.
  5. Diese Ausnahme ist unter den oben beschriebenen Umständen zu erwarten. Die eigentliche Ursache für den Fehler 504 Gateway Timeout liegt also immer noch darin, dass der Back-End-Server lange zum Antworten benötigt und Sie dieses Problem beheben müssen.

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 festzustellen, warum es länger als 57 Sekunden dauert, und prüfen Sie, ob er korrigiert/optimiert werden kann, um schneller zu reagieren.
    2. Wenn es nicht möglich ist, den Back-End-Server zu reparieren/optimieren, oder wenn Sie wissen, dass der Back-End-Server lange Zeit benötigt, erhöhen Sie den Zeitüberschreitungswert auf dem Router und dem Message Processor.

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

      Zeitüberschreitung beim Client > Zeitüberschreitung beim Router > Zeitüberschreitung beim Nachrichtenprozessor > Zeitüberschreitung im API-Proxy
  2. Bei einem NodeJS-Back-End gilt:
    1. Prüfen Sie, ob der Node.js-Code Aufrufe an andere Back-End-Server sendet und ob die Rückgabe sehr lange dauert. Prüfen Sie, warum diese Backend-Server länger benötigen.
    2. Prüfen Sie, ob die CPU- oder Arbeitsspeicherauslastung der Nachrichten-Prozessoren hoch ist:
      1. Wenn ein Nachrichtenprozessor eine hohe CPU-Auslastung aufweist, generieren Sie alle 30 Sekunden mit dem folgenden Befehl drei Thread-Dumps: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Wenn ein Nachrichten-Prozessor 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 Nachrichten-Prozessor mit dem folgenden Befehl neu. Dadurch sollten CPU und Arbeitsspeicher deaktiviert werden: 
        /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 ihm die Thread-Dumps, Heap-Dumps und Message Processor-Protokolle (/opt/apigee/var/log/edge-message-processor/logs/system.log)), damit er die Ursache für die hohe CPU-/Speichernutzung untersuchen kann.

Zeitlimit für Router und Message Processor erhöhen

Wählen Sie die Zeitlimits für den Router und den Message Processor sorgfältig entsprechend Ihren Anforderungen aus. Legen Sie keine willkürlich langen Zeitlimits 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 dem Routercomputer, 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 ein Zeitlimit von 120 Sekunden festlegen möchten, geben Sie folgenden Wert ein:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Achten Sie darauf, dass diese Datei Apigee gehört:
  4. Router neu starten: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. Wenn Sie mehrere 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 dieser 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. Der Eigentümer dieser Datei muss apigee sein: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Starten Sie den Nachrichtenprozessor 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: Lege den Wert für die Zeitüberschreitung für die verschiedenen Komponenten in der folgenden Reihenfolge fest:

Zeitüberschreitung beim Client > Zeitüberschreitung beim Router > Zeitüberschreitung beim Nachrichtenprozessor > Zeitüberschreitung im API-Proxy

Langsame API-Anfrageverarbeitung durch Edge

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

Diagnose

  1. Verfolgen Sie die betroffene API in der Edge-Benutzeroberfläche.
  2. Warten Sie entweder, bis der Fehler auftritt, oder führen Sie einige API-Aufrufe aus, um den 504 Gateway Timeout-Fehler zu reproduzieren.
  3. Hinweis: In diesem Fall wird im Trace möglicherweise eine erfolgreiche Antwort angezeigt.
    1. Der Router/Client löst ein Zeitlimit aus, da der Message Processor nicht innerhalb des angegebenen Zeitlimits auf dem Router/Client antwortet (je nachdem, welches Zeitlimit kürzer ist). Der Message Processor verarbeitet die Anfrage jedoch weiter und sie kann erfolgreich abgeschlossen werden.
    2. Außerdem wird der für den Nachrichtenprozessor festgelegte Wert HTTPTransport.io.timeout.millis nur ausgelöst, wenn der Nachrichtenprozessor mit einem HTTP-/HTTPS-Backendserver kommuniziert. Mit anderen Worten: Diese Zeitüberschreitung wird nicht ausgelöst, wenn eine andere Richtlinie (außer der ServiceCallout-Richtlinie) im API-Proxy lange dauert.
  4. Prüfen Sie nach dem Auftreten des Fehlers die Anfrage mit der längsten verstrichenen Zeit.
  5. Prüfen Sie die verstrichene Zeit in jeder Phase und notieren Sie sich die Phase, in der die meiste Zeit verbracht wird.
  6. Wenn die längste verstrichene Zeit in einer anderen Richtlinie als der ServiceCallout-Richtlinie festgestellt wird, bedeutet das, dass die Verarbeitung der Anfrage in Edge sehr lange dauert.
  7. Hier ist ein Beispiel für einen UI-Trace mit einer sehr langen Ablaufzeit für die JavaScript-Richtlinie:

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

Auflösung

  1. Prüfen Sie, ob die Richtlinie, auf die die lange Antwortzeit zurückzuführen ist, und benutzerdefinierter Code die Verarbeitung möglicherweise verzögern. Wenn Sie solchen Code finden, versuchen Sie, ihn zu korrigieren oder zu optimieren.
  2. Wenn es keinen benutzerdefinierten Code gibt, der zu einer langen Verarbeitungszeit führen könnte, prüfen Sie, ob die CPU- oder Speichernutzung der Nachrichtenverarbeiter hoch ist:
    1. Wenn die CPU-Auslastung bei einem Message Processor hoch ist, 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 Arbeitsspeicherauslastung 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. Dadurch sollte die CPU- und Arbeitsspeichernutzung sinken. 
      /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 stellen Sie die Thread-Dumps, den Heap-Dump und die 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.

Probleme mithilfe des API-Monitorings diagnostizieren

Mit dem 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.

In diesem Beispielszenario wird gezeigt, wie Sie mithilfe des API-Monitorings 5xx-Probleme mit Ihren APIs beheben. Sie können beispielsweise eine Benachrichtigung einrichten, die benachrichtigt wird, wenn die Anzahl der 504-Statuscodes einen bestimmten Schwellenwert überschreitet.