502 Bad Gateway – TooBigBody

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

Symptom

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

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

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-/Back-End-Server an Apigee Edge als Teil der HTTP-Antwort gesendet wird, das zulässige Limit in Apigee Edge überschreitet.

Das kann folgende Ursachen haben:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Die Nutzlastgröße der Antwort ist größer als das zulässige Limit	Die Nutzlastgröße, die vom Ziel-/Back-End-Server als Teil der HTTP-Antwort an Apigee gesendet wird, überschreitet das in Apigee zulässige Limit.	Nutzer von Edge Public und Private Cloud
Die Größe der Antwortnutzlast überschreitet nach der Dekomprimierung das zulässige Limit	Die Nutzlastgröße, die vom Ziel-/Back-End-Server als Teil der HTTP-Antwort an Apigee in komprimierter Form gesendet wird, übersteigt bei der Dekomprimierung durch Apigee das zulässige Limit.	Nutzer von Edge Public und Private Cloud

Allgemeine Diagnoseschritte

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

Ursache: Die Nutzlastgröße der Antwort ist größer als das zulässige Limit

Diagnose

1. Bestimmen Sie den Fehlercode,die Fehlerquelle und die Größe der Antwortnutzlast für den Fehler, der mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs beobachtet wird, wie unter Allgemeine Diagnoseschritte in Szenario 1 erläutert.
2. Wenn die Fehlerquelle den Wert target hat, weist dies darauf hin, dass die vom Ziel-/Back-End-Server an Apigee gesendete Antwortnutzlastgröße das zulässige Limit in Apigee Edge überschreitet.
3. Prüfen Sie die Antwortnutzlastgröße (siehe Schritt 1).
   • Wenn die Nutzlastgröße über 10 MB liegt, ist das die Fehlerursache.
   • Wenn die Nutzlastgröße maximal 10 MB beträgt, kann die Antwortnutzlast in komprimiertem Format übergeben werden. Gehen Sie zu Ursache: Größe der Antwortnutzlast überschreitet den zulässigen Grenzwert nach der Dekomprimierung.
4. Prüfen Sie, ob die Größe der Antwortnutzlast tatsächlich größer als 10 MB ist. Gehen Sie dazu so vor:
   1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, gehen Sie zu Lösung.
   2. Wenn Sie Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, führen Sie die folgenden Schritte aus:
      1. Wenn Sie ein Nutzer einer öffentlichen Cloud oder einer privaten Cloud sind, stellen Sie vom Back-End-Server selbst oder von einer anderen Maschine, von der Sie die Anfrage an den Back-End-Server senden dürfen, eine Anfrage direkt an den Back-End-Server.
      2. Wenn Sie ein Private Cloud-Nutzer sind, können Sie die Anfrage auch von einem der Message Processor an den Back-End-Server stellen.
      3. Prüfen Sie die Größe der in der Antwort übergebenen Nutzlast, indem Sie den Header Content-Length prüfen.
      4. Wenn Sie feststellen, dass die Größe der Nutzlast das zulässige Limit in Apigee Edge überschreitet, ist dies die Ursache des Problems.

   Beispielantwort vom Back-End-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 er den zulässigen Grenzwert in Apigee Edge überschreitet.

Auflösung

Siehe Lösung.

Ursache: Die Größe der Antwortnutzlast überschreitet nach der Dekomprimierung den zulässigen Grenzwert

Wenn die Antwortnutzlast in einem komprimierten Format gesendet wird und der Antwortheader Content-Encoding auf gzip, gesetzt ist, dekomprimiert Apigee die Antwortnutzlast. Wenn Apigee während des Dekomprimierungsvorgangs feststellt, dass die Größe der Nutzlast größer als das zulässige Limit in Apigee Edge. ist, stoppt es die weitere Dekomprimierung und antwortet sofort mit 502 Bad Gateway und dem Fehlercode protocol.http.TooBigBody.

Diagnose

1. Bestimmen Sie den Fehlercode, die Fehlerquelle und die Größe der Antwortnutzlast für den Fehler, der mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs beobachtet wird, wie unter Allgemeine Diagnoseschritte in Szenario 2 erläutert.
2. Wenn die Fehlerquelle den Wert target hat, zeigt dies an, dass die von der Ziel-/Back-End-Anwendung an Apigee gesendete Antwortnutzlastgröße das zulässige Limit in Apigee Edge überschreitet.
3. Prüfen Sie die Antwortnutzlastgröße (siehe Schritt 1).
   • Wenn die Nutzlastgröße über 10 MB liegt, ist das die Fehlerursache.
   • Wenn die Nutzlastgröße maximal 10 MB beträgt, kann die Antwortnutzlast in komprimiertem Format übergeben werden. Prüfen Sie in diesem Fall die unkomprimierte Größe der komprimierten Antwortnutzlast.
4. Mit einer der folgenden Methoden können Sie überprüfen, ob die Antwort vom Ziel/Back-End in komprimiertem Format gesendet wurde und die nicht komprimierte Größe das zulässige Limit überschreitet:

   Trace

   Trace-Tool verwenden:

   1. Wenn Sie ein Trace für die fehlgeschlagene Anfrage erfasst haben, lesen Sie die Schritte unter Trace und
      1. Ermitteln Sie den Wert von target.received.content.length.
      2. Prüfen Sie, ob die Anfrage vom Client den Header Content-Encoding: gzip enthält.
   2. Wenn der Wert für target.received.content.length etwa die zulässige Grenze von 10 MB und der Antwortheader Content-Encoding: gzip liegt, ist das die Ursache für diesen Fehler.

   Tatsächliche Anfrage

   Tatsächliche Anfrage:

   1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, gehen Sie zu Lösung.
   2. Wenn Sie Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, führen Sie die folgenden Schritte aus:
      1. Prüfen Sie die Größe der Nutzlast, die in der Antwort zusammen mit dem in der Antwort gesendeten Header Content-Encoding übergeben wird.
      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 das die Ursache für diesen Fehler.

         Beispielantwort vom Back-End-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 ca. 15 MB.

   Message Processor-Protokolle

   Nachrichtenprozessor-Protokolle verwenden:

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

   2. Prüfen der Message Processor-Protokolle

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

   3. Suchen Sie nach 502-Fehlern innerhalb eines bestimmten Zeitraums (ob das Problem in der Vergangenheit aufgetreten ist) oder ob es immer noch Anfragen mit 502 gibt, die fehlschlagen. Sie können die folgenden Suchzeichenfolgen verwenden:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Die Zeilen von system.log sehen in etwa so aus (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. Sobald der Message Processor feststellt, dass die Gesamtzahl der Lesebyte größer als 10 MB ist, wird während des Dekomprimierungsvorgangs die folgende Zeile ausgegeben:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Dies impliziert, dass die Antwortutzlastgröße größer als 10 MB ist und Apigee den Fehler ausgibt, wenn die Größe beginnt, die Grenze von 10 MB mit dem Fehlercode protocol.http.TooBigBody zu überschreiten.

Auflösung

Einschränkungen

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

1. Wenn Sie ein Public Cloud-Nutzer sind, ist die Obergrenze für die Nutzlastgröße von Anfragen und Antworten wie unter Request/response size unter Apigee Edge-Limits dokumentiert.
2. Wenn Sie ein Private Cloud-Nutzer sind, haben Sie möglicherweise die standardmäßige Höchstgrenze für die Nutzlastgröße von Anfragen und Antworten geändert (obwohl dies nicht empfohlen wird). Sie können das Limit für die maximale Nutzlast von Anfragen ermitteln. Folgen Sie dazu der Anleitung unter Aktuelles Limit prüfen.

Wie überprüfe ich das aktuelle Limit?

In diesem Abschnitt wird erläutert, wie Sie überprüfen können, ob das Attribut HTTPResponse.body.buffer.limit mit einem neuen Wert auf den Message Processors aktualisiert wurde.

1. Suchen Sie auf dem Message Processor-Computer im Verzeichnis /opt/apigee/edge-message- processor/conf nach der Eigenschaft HTTPResponse.body.buffer.limit und prüfen Sie, welcher Wert wie unten dargestellt festgelegt wurde:

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

2. Das Ergebnis des obigen Befehls sieht so aus:

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

3. In der obigen Beispielausgabe wurde das Attribut HTTPResponse.body.buffer.limit mit dem Wert 10m in http.properties festgelegt.

   Dies weist darauf hin, dass das Limit für die in Apigee für Private Cloud konfigurierte Größe der Anfragenutzlast 10 MB beträgt.

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie Diagnoseinformationen müssen eingeholt werden.

Erfassen von Diagnoseinformationen erforderlich

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

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

• Name der Organisation
• Name der Umgebung
• API-Proxy-Name
• Schließen Sie den curl-Befehl ab, mit dem der Fehler 502 reproduziert wird
• Ablaufverfolgungsdatei für die API-Anfragen
• Vollständige Ausgabe der Antwort vom Ziel-/Back-End-Server zusammen mit der Größe der Nutzlast

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

• Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
• Name der Organisation
• Name der Umgebung
• API-Proxy-Bundle
• Ablaufverfolgungsdatei für fehlgeschlagenen API-Anfragen
• Schließen Sie den curl-Befehl ab, mit dem der Fehler 502 reproduziert wird
• Vollständige Ausgabe der Antwort vom Ziel-/Back-End-Server zusammen mit der Größe der Nutzlast

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

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

• Systemprotokolle von Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log