502 Nieprawidłowa bramka – TooBigBody

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

W odpowiedzi na wywołania interfejsu API aplikacja kliencka otrzymuje kod stanu HTTP 502 Bad Gateway z kodem błędu protocol.http.TooBigBody .

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Możesz też zobaczyć ten komunikat o błędzie:

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

Możliwe przyczyny

Ten błąd występuje, gdy rozmiar ładunku wysłanego przez serwer docelowy lub backendowy do Apigee Edge w ramach odpowiedzi HTTP jest większy niż dozwolony limit w Apigee Edge.

Oto możliwe przyczyny tego błędu:

Typowe etapy diagnostyki

Aby zdiagnozować ten błąd, użyj jednego z tych narzędzi lub technik:

Przyczyna: rozmiar ładunku odpowiedzi przekracza dopuszczalny limit.

Diagnostyka

1. Określ kod błędu,źródło błędu i rozmiar ładunku odpowiedzi w przypadku zaobserwowanego błędu, korzystając z monitorowania interfejsu API, narzędzia Trace lub logów dostępu NGINX, jak opisano w typowych krokach diagnostycznych w scenariuszu 1.
2. Jeśli Źródło błędu ma wartość target, oznacza to, że rozmiar ładunku odpowiedzi wysłanej przez serwer docelowy lub serwer backendu do Apigee jest większy niż dozwolony limit w Apigee Edge.
3. Sprawdź rozmiar ładunku odpowiedzi określony w kroku 1.
   • Jeśli rozmiar ładunku przekracza dozwolony limit 10 MB, to jest to przyczyną błędu.
   • Jeśli rozmiar ładunku jest zbliżony do dozwolonego limitu 10 MB, może się zdarzyć, że ładunek odpowiedzi zostanie przekazany w formacie skompresowanym. Wejdź na Przyczyna: rozmiar ładunku odpowiedzi po dekompresji przekracza dozwolony limit.
4. Sprawdź, czy rozmiar ładunku odpowiedzi jest większy niż dopuszczalny limit 10 MB. W tym celu wykonaj te czynności:
   1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego do serwera docelowego lub backendu, przejdź do sekcji Rozwiązanie.
   2. Jeśli masz dostęp do rzeczywistego żądania wysłanego do serwera docelowego lub backendu, wykonaj te czynności:
      1. Jeśli jesteś użytkownikiem chmury publicznej lub prywatnej, wyślij żądanie bezpośrednio do serwera backendu z samego serwera backendu lub z dowolnego innego urządzenia, z którego możesz wysłać żądanie do serwera backendu.
      2. Jeśli jesteś użytkownikiem chmury prywatnej, możesz też wysłać żądanie do serwera backendu z jednego z procesorów wiadomości.
      3. Sprawdź rozmiar ładunku przekazanego w odpowiedzi, sprawdzając nagłówek Content-Length.
      4. Jeśli okaże się, że rozmiar ładunku przekracza dozwolony limit w Apigee Edge, to jest to przyczyną problemu.

   Przykładowa odpowiedź z serwera backendu:

   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>

   W powyższym przykładzie widać, że przyczyną tego błędu jest Content-Length: 11534336 (which is ~11 MB), ponieważ przekracza dopuszczalny limit w Apigee Edge.

Rozdzielczość

Zapoznaj się z sekcją Rozwiązanie.

Przyczyna: rozmiar ładunku odpowiedzi po dekompresji przekracza dozwolony limit.

Jeśli ładunek odpowiedzi jest wysyłany w skompresowanym formacie, a nagłówek odpowiedzi Content-Encoding ma wartość gzip, , Apigee dekompresuje ładunek odpowiedzi. Jeśli podczas dekompresji Apigee stwierdzi, że rozmiar ładunku jest większy niż dozwolony limit w Apigee Edge, zatrzyma dalszą dekompresję i natychmiast odpowie kodem stanu 502 Bad Gateway i kodem błędu protocol.http.TooBigBody.

Diagnostyka

1. Określ kod błędu, źródło błędu i rozmiar ładunku odpowiedzi w przypadku zaobserwowanego błędu, korzystając z monitorowania interfejsu API, narzędzia do śledzenia lub logów dostępu NGINX, zgodnie z opisem w typowych krokach diagnostycznych w scenariuszu 2.
2. Jeśli Fault Source ma wartość target, oznacza to, że rozmiar ładunku odpowiedzi wysłanego przez aplikację docelową lub backendową do Apigee jest większy niż dozwolony limit w Apigee Edge.
3. Sprawdź rozmiar ładunku odpowiedzi określony w kroku 1.
   • Jeśli rozmiar ładunku przekracza dozwolony limit 10 MB, to jest to przyczyną błędu.
   • Jeśli rozmiar ładunku wynosi około 10 MB, czyli jest bliski dozwolonemu limitowi, ładunek odpowiedzi może być przekazywany w formacie skompresowanym. W takim przypadku sprawdź nieskompresowany rozmiar skompresowanego ładunku odpowiedzi.
4. Możesz sprawdzić, czy odpowiedź z usługi docelowej lub backendu została wysłana w formacie skompresowanym, a rozmiar nieskompresowany był większy niż dopuszczalny limit, korzystając z jednej z tych metod:

   Śledzenie

   Korzystanie z narzędzia Ślad:

   1. Jeśli udało Ci się zarejestrować ślad nieudanego żądania, wykonaj czynności opisane w sekcjach Ślad i 
      1. Określ wartość parametru target.received.content.length.
      2. Sprawdź, czy żądanie od klienta zawierało nagłówek Content-Encoding: gzip .
   2. Jeśli wartość target.received.content.length jest zbliżona do dopuszczalnego limitu 10 MB, a nagłówek odpowiedzi to Content-Encoding: gzip, to jest to przyczyna tego błędu.

   Rzeczywista prośba

   Używanie rzeczywistej prośby:

   1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego do serwera docelowego lub backendu, przejdź do sekcji Rozwiązanie.
   2. Jeśli masz dostęp do rzeczywistego żądania wysłanego do serwera docelowego lub backendu, wykonaj te czynności:
      1. Sprawdź rozmiar ładunku przekazanego w odpowiedzi wraz z nagłówkiem Content-Encoding wysłanym w odpowiedzi.
      2. Jeśli nagłówek odpowiedzi Content-Encoding ma wartość gzip, a nieskompresowany rozmiar ładunku przekracza dozwolony limit w Apigee Edge, to jest to przyczyna tego błędu.

         Przykładowa odpowiedź otrzymana z serwera backendu:

         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>

         W tym przypadku wysyłany jest nagłówek Content-Encoding: gzip, a rozmiar pliku testzippedfile.gz w odpowiedzi jest mniejszy niż limit, jednak rozmiar rozpakowanego pliku testzippedfile wynosił około 15 MB.

   Dzienniki procesora komunikatów

   Korzystanie z dzienników procesora komunikatów:

   1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz użyć logów procesora komunikatów, aby określić kluczowe informacje o błędach HTTP 502.

   2. Sprawdzanie dzienników procesora komunikatów

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

   3. Sprawdź, czy w określonym czasie wystąpiły jakieś 502błędy (jeśli problem pojawił się w przeszłości) lub czy nadal występują nieudane żądania z kodem 502. Możesz użyć tych ciągów wyszukiwania:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. W pliku znajdziesz wiersze z system.log podobne do tych poniżej (TotalRead i chunkCount mogą się różnić w Twoim przypadku):

      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. Podczas dekompresji, gdy tylko procesor wiadomości stwierdzi, że łączna liczba odczytanych bajtów jest większa niż 10 MB, zatrzymuje się i wyświetla ten wiersz:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Oznacza to, że rozmiar ładunku odpowiedzi przekracza 10 MB, a Apigee zgłasza błąd, gdy rozmiar zaczyna przekraczać limit 10 MB, z kodem błędu protocol.http.TooBigBody.

Rozdzielczość

Limity

Apigee oczekuje, że aplikacja kliencka i serwer backendu nie będą wysyłać ładunków o rozmiarach większych niż dozwolony limit, zgodnie z dokumentacją dotyczącą Request/response size w  limitach Apigee Edge.

1. Jeśli jesteś użytkownikiem chmury publicznej, maksymalny limit rozmiaru ładunku żądania i odpowiedzi jest taki, jak podano w przypadku Request/response size w  limitach Apigee Edge.
2. Jeśli jesteś użytkownikiem chmury prywatnej , możesz mieć zmodyfikowany domyślny limit maksymalny rozmiaru ładunku żądania i odpowiedzi (chociaż nie jest to zalecane). Maksymalny limit rozmiaru ładunku żądania możesz określić, postępując zgodnie z instrukcjami w artykule Jak sprawdzić obecny limit.

Jak sprawdzić bieżący limit?

W tej sekcji dowiesz się, jak sprawdzić, czy właściwość HTTPResponse.body.buffer.limit została zaktualizowana o nową wartość w procesorach wiadomości.

1. Na komputerze procesora komunikatów wyszukaj właściwość HTTPResponse.body.buffer.limit w katalogu /opt/apigee/edge-message- processor/conf i sprawdź, jaka wartość została ustawiona, jak pokazano poniżej:

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

2. Przykładowy wynik powyższego polecenia wygląda tak:

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

3. W przykładzie danych wyjściowych powyżej zwróć uwagę, że właściwość HTTPResponse.body.buffer.limit ma wartość 10m w http.properties.

   Oznacza to, że limit rozmiaru ładunku żądania skonfigurowany w Apigee dla chmury prywatnej wynosi 10 MB.

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, zapoznaj się z sekcją Informacje diagnostyczne, które musisz zebrać.

musi zbierać informacje diagnostyczne;

Zbierz te informacje diagnostyczne, a potem skontaktuj się z zespołem pomocy Apigee Edge:

Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:

• Nazwa organizacji
• Nazwa środowiska
• Nazwa proxy interfejsu API
• Pełne polecenie curl użyte do odtworzenia błędu 502
• Plik śledzenia żądań do interfejsu API
• Pełne dane wyjściowe odpowiedzi z serwera docelowego lub backendu wraz z rozmiarem ładunku.

Jeśli jesteś użytkownikiem chmury Private Cloud, podaj te informacje:

• Pełny komunikat o błędzie dotyczący żądań, które nie zostały zrealizowane
• Nazwa organizacji
• Nazwa środowiska
• Pakiet proxy interfejsu API
• Plik śledzenia nieudanych żądań do interfejsu API
• Pełne polecenie curl użyte do odtworzenia błędu 502
• Pełne dane wyjściowe odpowiedzi z serwera docelowego lub backendu wraz z rozmiarem ładunku.

• Logi dostępu NGINX/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Gdzie: ORG, ENV i PORT# są zastępowane rzeczywistymi wartościami.

• Dzienniki systemowe procesora komunikatów /opt/apigee/var/log/edge-message-processor/logs/system.log