502 Bad Gateway – TooBigBody

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

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 502 Bad Gateway mit dem Fehlercode protocol.http.TooBigBody als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt auf, wenn die Nutzlastgröße, die vom Ziel-/Backend-Server als Teil der HTTP-Antwort an Apigee Edge gesendet wird, das zulässige Limit in Apigee Edge überschreitet.

Mögliche Ursachen für den Fehler:

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Verfahren, um diesen Fehler zu diagnostizieren:

Ursache: Die Größe der Antwortnutzlast überschreitet das zulässige Limit.

Diagnose

1. Ermitteln Sie den Fehlercode, die Fehlerquelle und die Größe der Antwortnutzlast für den beobachteten Fehler mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte in Szenario 1 beschrieben.
2. Wenn die Fehlerquelle den Wert target hat, bedeutet das, dass die Größe der Antwortnutzlast, die vom Ziel-/Backend-Server an Apigee gesendet wird, das zulässige Limit in Apigee Edge überschreitet.
3. Prüfen Sie die Größe der Antwortnutzlast, die in Schritt 1 ermittelt wurde.
   • Wenn die Nutzlastgröße das zulässige Limit von 10 MB überschreitet, ist dies die Ursache des Fehlers.
   • Wenn die Nutzlastgröße das zulässige Limit von etwa 10 MB erreicht, wird die Antwortnutzlast möglicherweise im komprimierten Format übergeben. Gehen Sie zu Ursache: Größe der Antwortnutzlast überschreitet nach der Dekomprimierung das zulässige Limit.
4. Prüfen Sie, ob die Größe der Antwortnutzlast tatsächlich das zulässige Limit von 10 MB überschreitet. Gehen Sie dazu so vor:
   1. Wenn Sie keinen Zugriff auf die tatsächliche Anfrage an den Ziel-/Backend-Server haben, fahren Sie mit Lösung fort.
   2. Wenn Sie Zugriff auf die tatsächliche Anfrage an den Ziel-/Backend-Server haben, führen Sie die folgenden Schritte aus:
      1. Wenn Sie ein Public Cloud-/Private Cloud-Nutzer sind, stellen Sie eine Anfrage direkt an den Backend-Server, entweder vom Backend-Server selbst oder von einem anderen Computer, von dem aus Sie die Anfrage an den Backend-Server senden dürfen.
      2. Wenn Sie Private Cloud verwenden, können Sie die Anfrage auch von einem der Message Processors an den Backend-Server senden.
      3. Prüfen Sie die Größe der in der Antwort übergebenen Nutzlast anhand des Content-Length-Headers.
      4. Wenn die Größe der Nutzlast das zulässige Limit in Apigee Edge überschreitet, ist dies die Ursache des Problems.

   Beispielantwort vom Backend-Server:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   Im obigen Beispiel sehen Sie, dass Content-Length: 11534336 (which is ~11 MB) die Ursache für diesen Fehler ist, da es das zulässige Limit in Apigee Edge überschreitet.

Auflösung

Weitere Informationen finden Sie unter Lösung.

Ursache: Die Größe der Antwortnutzlast überschreitet nach der Dekomprimierung das zulässige Limit.

Wenn die Antwortnutzlast im komprimierten Format gesendet wird und der Antwortheader Content-Encoding auf gzip, gesetzt ist, dekomprimiert Apigee die Antwortnutzlast. Wenn Apigee während der Dekomprimierung feststellt, dass die Größe der Nutzlast das zulässige Limit in Apigee Edge überschreitet, wird die Dekomprimierung beendet und sofort mit 502 Bad Gateway und dem Fehlercode protocol.http.TooBigBody geantwortet.

Diagnose

1. Ermitteln Sie den Fehlercode, die Fehlerquelle und die Größe der Antwortnutzlast für den beobachteten Fehler mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte in Szenario 2 beschrieben.
2. Wenn die Fehlerquelle den Wert target hat, bedeutet dies, dass die Größe der Antwortnutzlast, die von der Ziel-/Backend-Anwendung an Apigee gesendet wird, das zulässige Limit in Apigee Edge überschreitet.
3. Prüfen Sie die Größe der Antwortnutzlast, die in Schritt 1 ermittelt wurde.
   • Wenn die Nutzlastgröße das zulässige Limit von 10 MB überschreitet, ist dies die Ursache des Fehlers.
   • Wenn die Nutzlastgröße das zulässige Limit von etwa 10 MB erreicht, wird die Antwortnutzlast möglicherweise im komprimierten Format übergeben. Prüfen Sie in diesem Fall die unkomprimierte Größe der komprimierten Antwortnutzlast.
4. Sie können mit einer der folgenden Methoden prüfen, ob die Antwort vom Ziel/Backend im komprimierten Format gesendet wurde und die unkomprimierte Größe das zulässige Limit überschritten hat:

   Trace

   Trace-Tool verwenden:

   1. Wenn Sie einen Trace für die fehlgeschlagene Anfrage erfasst haben, folgen Sie der Anleitung unter Trace und
      1. Wert von target.received.content.length ermitteln
      2. Prüfen Sie, ob die Anfrage vom Client den Header Content-Encoding: gzip enthält.
   2. Wenn der Wert von target.received.content.length in der Nähe des zulässigen Limits von 10 MB liegt und der Antwortheader Content-Encoding: gzip lautet, ist dies die Ursache für diesen Fehler.

   Tatsächliche Anfrage

   Tatsächliche Anfrage verwenden:

   1. Wenn Sie keinen Zugriff auf die tatsächliche Anfrage haben, die an den Ziel-/Backend-Server gesendet wurde, fahren Sie mit Lösung fort.
   2. Wenn Sie Zugriff auf die tatsächliche Anfrage haben, die an den Ziel-/Backend-Server gesendet wurde, führen Sie die folgenden Schritte aus:
      1. Prüfen Sie die Größe der in der Antwort übergebenen Nutzlast sowie den in der Antwort gesendeten Content-Encoding-Header.
      2. Wenn Sie feststellen, dass der Antwortheader Content-Encoding auf gzip gesetzt ist und die unkomprimierte Größe der Nutzlast das zulässige Limit in Apigee Edge überschreitet, ist dies die Ursache für diesen Fehler.

         Beispiel für eine Antwort vom Backend-Server:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         Im obigen Fall wird der Header Content-Encoding: gzip gesendet und die Größe der Datei testzippedfile.gz in der Antwort liegt unter dem Limit. Die Größe der unkomprimierten Datei testzippedfile betrug jedoch etwa 15 MB.

   Logs des Message Processors

   Nachrichtenprozessor-Logs verwenden:

   1. Wenn Sie Private Cloud-Nutzer sind, können Sie die Message Processor-Logs verwenden, um die wichtigsten Informationen zu HTTP-502-Fehlern zu ermitteln.

   2. Logs des Message Processors prüfen

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

   3. Suchen Sie nach 502-Fehlern in einem bestimmten Zeitraum (wenn das Problem in der Vergangenheit aufgetreten ist) oder danach, ob bei Anfragen immer noch 502-Fehler auftreten. Sie können die folgenden Suchstrings verwenden:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Sie finden Zeilen aus system.log, die so aussehen wie unten (TotalRead und chunkCount können in Ihrem Fall variieren):

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)

   5. Während der Dekomprimierung wird der Vorgang beendet und die folgende Zeile ausgegeben, sobald der Message Processor feststellt, dass die Anzahl der gelesenen Bytes insgesamt größer als 10 MB ist:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Das bedeutet, dass die Größe der Antwortnutzlast mehr als 10 MB beträgt und Apigee den Fehler ausgibt, wenn die Größe das Limit von 10 MB mit dem Fehlercode protocol.http.TooBigBody überschreitet.

Auflösung

Limits

Apigee erwartet, dass die Clientanwendung und der Backend-Server keine Nutzlastgrößen senden, die das zulässige Limit überschreiten, wie für Request/response size in den Apigee Edge-Limits dokumentiert.

1. Wenn Sie ein Public Cloud-Nutzer sind, gilt für die maximale Größe der Anfrage- und Antwortnutzlast das Limit, das für Request/response size in den Apigee Edge-Limits dokumentiert ist.
2. Wenn Sie ein Private Cloud-Nutzer sind, haben Sie möglicherweise das standardmäßige maximale Limit für die Größe der Anfrage- und Antwortnutzlast geändert, obwohl dies nicht empfohlen wird. Wie Sie das Limit für die maximale Größe der Anfragenutzlast ermitteln, erfahren Sie hier.

Aktuelles Limit prüfen

In diesem Abschnitt wird erläutert, wie Sie prüfen, ob die Property HTTPResponse.body.buffer.limit in den Message Processors mit einem neuen Wert aktualisiert wurde.

1. Suchen Sie auf der Message Processor-Maschine im Verzeichnis /opt/apigee/edge-message- processor/conf nach der Property HTTPResponse.body.buffer.limit und prüfen Sie, welcher Wert festgelegt wurde (siehe unten):

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. Das Beispielergebnis des oben genannten Befehls sieht so aus:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

3. In der obigen Beispielausgabe sehen Sie, dass die Property HTTPResponse.body.buffer.limit mit dem Wert 10m in http.properties festgelegt wurde.

   Das bedeutet, dass das in Apigee for Private Cloud konfigurierte Limit für die Größe der Anfrage-Nutzlast 10 MB beträgt.

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Name der Organisation
• Name der Umgebung
• Name des API-Proxys
• Vollständiger curl-Befehl zum Reproduzieren des 502-Fehlers
• Trace-Datei für die API-Anfragen
• Vollständige Ausgabe der Antwort vom Ziel-/Backend-Server zusammen mit der Größe der Nutzlast

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Organisation
• Name der Umgebung
• API-Proxy-Bundle
• Trace-Datei für die fehlgeschlagenen API-Anfragen
• Vollständiger curl-Befehl zum Reproduzieren des 502-Fehlers
• Vollständige Ausgabe der Antwort vom Ziel-/Backend-Server zusammen mit der Größe der Nutzlast

• NGINX-Zugriffslogs /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Dabei gilt:ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.

• Systemprotokolle des Message Processors /opt/apigee/var/log/edge-message-processor/logs/system.log