502 Bad Gateway – TooBigBody

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Die Clientanwendung ruft den HTTP-Statuscode 502 Bad Gateway mit Fehlercode ab protocol.http.TooBigBody als Antwort auf API-Aufrufe an.

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 als Teil an Apigee Edge gesendet wird, der HTTP-Antwort ist größer als das zulässige Limit in Apigee Edge.

Mögliche Ursachen für diesen Fehler:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Die Größe der Antwortnutzlast liegt über dem zulässigen Limit	Die Nutzlastgröße, die vom Ziel-/Back-End-Server als Teil der HTTP-Antwort an Apigee gesendet wird, ist das Limit in Apigee überschreitet.	Edge-Nutzer von öffentlichen und privaten Clouds
Größe der Antwortnutzlast überschreitet das zulässige Limit nach Dekomprimierung	Die Nutzlastgröße, die vom Ziel-/Back-End-Server im komprimierten Format als Teil von HTTP gesendet wird Antwort an Apigee überschreitet das zulässige Limit, wenn es mit Apigee dekomprimiert wird.	Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

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

Ursache: Größe der Antwortnutzlast liegt über dem zulässigen Grenzwert

Diagnose

1. Bestimmen Sie den Fehlercode, die Fehlerquelle und die Größe der Antwortnutzlast für den bei Verwendung von API-Überwachungs-, Trace-Tool- oder NGINX-Zugriffsprotokollen beobachteten Fehler, wie unter Häufige Diagnoseschritte mit Szenario 1.
2. Wenn die Fehlerquelle den Wert target hat, bedeutet dies, dass die Antwort Nutzlastgröße, die vom Ziel-/Back-End-Server an Apigee gesendet wird, ist größer als zulässiges Limit in Apigee Edge.
3. Prüfen Sie die Größe der Antwortnutzlast wie in Schritt 1 ermittelt.
   • Wenn die Nutzlastgröße > 10 MB zulässig ist, ist dies die Ursache für den Fehler.
   • Wenn die Nutzlastgröße auf maximal 10 MB liegt, ist es möglich, dass die Antwort Payload wird in einem komprimierten Format übergeben. Gehe zu <ph type="x-smartling-placeholder"></ph> Ursache: Die Größe der Antwortnutzlast überschreitet nach der Dekomprimierung das zulässige Limit.
4. Validieren, dass die Nutzlastgröße der Antwort tatsächlich ist > Das Limit von 10 MB liegt in der tatsächliche Antwort mit den folgenden Schritten erhalten: <ph type="x-smartling-placeholder">
   </ph>
   1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, und gehe zu Auflösung.
   2. Wenn Sie Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, führen Sie die folgenden Schritte aus: <ph type="x-smartling-placeholder">
      </ph>
      1. Wenn Sie ein Nutzer einer öffentlichen Cloud/Private Cloud sind, stellen Sie eine Anfrage direkt an vom Back-End-Server selbst oder einer anderen Maschine, auf der Sie dürfen die Anfrage an den Back-End-Server senden.
      2. Als Private Cloud-Nutzer können Sie die Anfrage auch an den Back-End-Server von einem der Message Processors.
      3. Überprüfen Sie die Größe der in der Antwort übergebenen Nutzlast durch Überprüfen des Header „Content-Length“:
      4. Wenn Sie feststellen, dass die Größe der Nutzlast größer ist als die zulässigen Grenzwert in Apigee Edge, dann ist dies die Ursache des Problem.

   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 überschreitet. zulässiges Limit in Apigee Edge.

Auflösung

Weitere Informationen findest du unter Lösung.

Ursache: Antwort-Nutzlastgröße überschreitet zulässiges Limit nach Dekomprimierung

Wenn die Antwortnutzlast in einem komprimierten Format gesendet wird und der Antwortheader Content-Encoding ist auf gzip, Apigee dekomprimiert die Antwort. Payload. Wenn Apigee während der Dekomprimierung feststellt, dass die Größe der Nutzlast größer ist als das zulässige Limit in Apigee Edge., wird es weiter angehalten. 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 bei Verwendung der API-Überwachungs-, Trace-Tool- oder NGINX-Zugriffsprotokolle beobachteten Fehler, wie unter Häufige Diagnoseschritte mit Szenario 2:
2. Wenn die Fehlerquelle den Wert target hat, bedeutet dies, dass der von der Ziel-/Back-End-Anwendung an Apigee gesendete Antwortnutzlastgröße ist größer als zulässiges Limit in Apigee Edge.
3. Prüfen Sie die Größe der Antwortnutzlast wie in Schritt 1 ermittelt.
   • Wenn die Nutzlastgröße > 10 MB zulässig ist, ist dies die Ursache für den Fehler.
   • Wenn die Nutzlastgröße auf maximal 10 MB liegt, ist es möglich, dass die Antwortnutzlast werden im komprimierten Format übergeben. Überprüfen Sie in diesem Fall die unkomprimierte Größe der komprimierten Datei. Nutzlast der Antwort.
4. Sie können überprüfen, ob die Antwort vom Ziel/Back-End in einem komprimierten Format gesendet wurde und Die unkomprimierte Größe lag über dem zulässigen Grenzwert. Verwenden Sie dazu eine der folgenden Optionen: Methoden:

   Trace

   Über das Trace-Tool:

   1. Wenn Sie einen Trace für die fehlgeschlagene Anfrage erfasst haben, folgen Sie den Schritten in Trace und <ph type="x-smartling-placeholder">
      </ph>
      1. Bestimmen Sie den Wert von target.received.content.length.
      2. Prüfen Sie, ob die Anfrage vom Client den Parameter Content-Encoding: gzip header
   2. Wenn der Wert von target.received.content.length etwa die zulässigen 10 MB beträgt und dem Antwortheader Content-Encoding: gzip die Ursache des Fehlers.

   Tatsächliche Anfrage

   Mit der tatsächlichen Anfrage:

   1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, und gehe zu Auflösung.
   2. Wenn Sie Zugriff auf die eigentliche Anfrage an den Ziel-/Back-End-Server haben, führen Sie die folgenden Schritte aus: <ph type="x-smartling-placeholder">
      </ph>
      1. Prüfen Sie die Größe der in der Antwort übergebenen Nutzlast zusammen mit dem Der Content-Encoding-Header wurde in der Antwort gesendet.
      2. Wenn Sie feststellen, dass der Antwortheader Content-Encoding auf gzip und die unkomprimierte Größe der Nutzlast ist größer als die zulässigen Grenzwert in Apigee Edge, dann ist das die Ursache für Fehler.

         Vom Back-End-Server empfangene Beispielantwort:

         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 kleiner ist als Limit erreicht, die Größe der unkomprimierten Datei testzippedfile betrug jedoch ~15 MB.

   <ph type="x-smartling-placeholder">

   Message Processor-Logs

   Message Processor-Logs verwenden:

   <ph type="x-smartling-placeholder">

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

   2. Message Processor-Logs prüfen

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

   3. Suchen, um zu sehen, ob es während eines bestimmten Zeitraums 502 Fehler gibt (wenn das Problem in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit 502 Sie können die folgenden Suchzeichenfolgen verwenden:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Es werden Zeilen ab system.log angezeigt, die der unten gezeigten ähneln. 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, sobald der Message Processor den Gesamtzahl der gelesenen Byte ist > 10 MB haben, hält er an und gibt die folgende Zeile aus:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Impliziert, dass die Antwortnutzlastgröße größer als 10 MB ist und Apigee gibt den Fehler aus, wenn die Größe beginnt, das Limit von 10 MB zu überschreiten, wobei der Fehlercode als folgender Fehlercode auftritt: protocol.http.TooBigBody

      <ph type="x-smartling-placeholder">

Auflösung

Limits

Apigee erwartet, dass die Clientanwendung und der Backend-Server keine Nutzlastgrößen senden, die größer als das zulässige Limit gemäß der Dokumentation für Request/response size in Apigee Edge-Limits.

1. Wenn Sie ein Public Cloud-Nutzer sind, gilt die Höchstgrenze für Anfragen und Antworten Nutzlastgröße entsprechend der Dokumentation für Request/response size in Apigee Edge-Limits.
2. Wenn Sie ein Private Cloud-Nutzer sind, haben Sie möglicherweise das Standardhöchstwert Limit für die Nutzlastgröße von Anfragen und Antworten (auch wenn dies nicht empfohlen wird). Sie können die maximale Nutzlastgröße für Anfragen bestimmen, indem Sie die Anweisungen in So prüfen Sie das aktuelle Limit.

Wie kann ich das aktuelle Limit prüfen?

<ph type="x-smartling-placeholder">

In diesem Abschnitt wird erläutert, wie Sie prüfen können, ob die Property HTTPResponse.body.buffer.limit wurde mit einem neuen Wert für die Nachricht aktualisiert Prozessoren.

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

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

2. Das Ergebnis des obigen Befehls sieht wie folgt aus:

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

3. Beachten Sie in der obigen Beispielausgabe, dass die Eigenschaft HTTPResponse.body.buffer.limit wurde auf den Wert 10m festgelegt in http.properties

   Dies gibt an, dass das Limit für die Größe der Anfragenutzlast, das in Apigee für den Private Cloud ist 10 MB groß.

Wenn Sie weitere Unterstützung vom Apigee-Support benötigen, rufen Sie auf. Diagnosedaten müssen erfasst 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
• Vollständiger curl-Befehl zum Reproduzieren des Fehlers 502
• Ablaufverfolgungsdatei für 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 für fehlgeschlagene Anfragen
• Name der Organisation
• Name der Umgebung
• API-Proxy-Bundle
• Ablaufverfolgungsdatei für fehlgeschlagene API-Anfragen
• Vollständiger curl-Befehl zum Reproduzieren des Fehlers 502
• 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

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

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