502 Nieprawidłowa bramka – TooBigBody

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 502 Bad Gateway z kodem błędu protocol.http.TooBigBody jako odpowiedź na wywołania interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Możesz też zobaczyć następujący komunikat o błędzie:

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

Możliwe przyczyny

Ten błąd występuje, jeśli rozmiar ładunku wysyłany przez serwer docelowy/backend do Apigee Edge w ramach części odpowiedzi HTTP przekracza dozwolony limit w Apigee Edge.

Oto możliwe przyczyny tego błędu:

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Rozmiar ładunku odpowiedzi jest większy niż dozwolony limit	Wielkość ładunku wysyłanego przez serwer docelowy/serwer backendu w ramach odpowiedzi HTTP do Apigee to przekracza limit dozwolony w Apigee.	Użytkownicy chmury publicznej i prywatnej Edge
Rozmiar ładunku odpowiedzi przekracza dozwolony limit po dekompresja	Rozmiar ładunku wysłany w formacie skompresowanym przez serwer docelowy/backend jako część HTTP odpowiedź na Apigee przekracza dozwolony limit podczas dekompresowania przez Apigee.	Użytkownicy chmury publicznej i prywatnej Edge

Typowe kroki diagnostyki

Użyj jednego z tych narzędzi lub metod, aby zdiagnozować ten błąd:

Przyczyna: rozmiar ładunku odpowiedzi jest większy niż dozwolony limit

Diagnostyka

1. Określ kod błędu, źródło błędu i rozmiar ładunku odpowiedzi dla błąd zaobserwowany przy użyciu monitorowania interfejsów API, narzędzia Trace lub logów dostępu NGINX, jak wyjaśniono w Typowe kroki diagnostyki w scenariuszu nr 1.
2. Jeśli źródło błędu ma wartość target, oznacza to, że odpowiedź rozmiar ładunku wysłanego przez serwer docelowy/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 > Limit 10 MB, to jest przyczyną błędu.
   • Jeśli rozmiar ładunku wynosi maksymalnie 10 MB, możliwe, że odpowiedź jest przekazywany w formacie skompresowanym. Przejdź do Przyczyna: rozmiar ładunku odpowiedzi po dekompresji przekracza dozwolony limit.
4. Sprawdź, czy rozmiar ładunku odpowiedzi jest rzeczywiście > Dozwolony limit 10 MB: wykonaj te czynności:
   1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego do serwera docelowego/backendu, i wybierz Rozwiązanie.
   2. Jeśli masz dostęp do rzeczywistego żądania wysłanego do serwera docelowego/backendu, wykonaj te czynności:
      1. Jeśli jesteś użytkownikiem chmury publicznej lub chmury prywatnej, poproś o nie bezpośrednio do do serwera backendu lub z innego komputera, mogą wysyłać żądania do serwera backendu.
      2. Jeśli jesteś użytkownikiem Private Cloud, możesz również wysłać prośbę do serwera backendu jednego z procesorów wiadomości.
      3. Aby sprawdzić rozmiar ładunku przekazywanego w odpowiedzi, sprawdź pole Nagłówek Content-Length.
      4. Jeśli okaże się, że rozmiar ładunku jest większy niż dozwolony limit w Apigee Edge, to jest przyczyną Google Cloud.

   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), bo przekracza dozwolony limit w Apigee Edge.

Rozdzielczość

Zobacz Rozwiązanie.

Przyczyna: rozmiar ładunku odpowiedzi przekracza dozwolony limit po dekompresja

Jeśli ładunek odpowiedzi jest wysyłany w formacie skompresowanym i nagłówek odpowiedzi Content-Encoding ma wartość gzip, Apigee dekompresuje odpowiedź ładunek. Jeśli podczas procesu dekompresji Apigee stwierdzi, że rozmiar ładunku jest większy przekracza dozwolony limit w Apigee Edge, a następnie zatrzymuje się dalej. dekompresji i natychmiast reaguje z kodem 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 dla błąd zaobserwowany przy użyciu monitorowania interfejsów API, narzędzia Trace Tool lub logów dostępu NGINX, jak wyjaśniono w Typowe kroki diagnostyki w scenariuszu nr 2.
2. Jeśli Źródło błędu ma wartość target, oznacza to, że rozmiar ładunku odpowiedzi wysłanego przez aplikację docelową/backend 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 > dozwolony limit 10 MB, to on jest przyczyną błędu.
   • Jeśli rozmiar ładunku wynosi około 10 MB, możliwe, że ładunek odpowiedzi przekazywane w formacie skompresowanym. W takim przypadku sprawdź rozmiar skompresowanego pliku ładunku odpowiedzi.
4. Możesz sprawdzić, czy odpowiedź ze środowiska docelowego/backendu została wysłana w formacie skompresowanym i rozmiar nieskompresowanego był większy niż dozwolony limit w przypadku jednego z tych elementów metody:

   Śledzenie

   Za pomocą narzędzia Trace (Śledzenie):

   1. Jeśli masz zarejestrowany ślad dla nieudanego żądania, zapoznaj się z krokami opisanymi w Trace i
      1. Określ wartość parametru target.received.content.length.
      2. Sprawdź, czy żądanie klienta zawierało Kodowanie treści: nagłówek gzip
   2. Jeśli wartość target.received.content.length wynosi około 10 MB dozwolonych i nagłówka odpowiedzi Content-Encoding: gzip . przyczyny tego błędu.

   Rzeczywiste żądanie

   Na podstawie rzeczywistego żądania:

   1. Jeśli nie masz dostępu do rzeczywistego żądania wysłanego do serwera docelowego/backendu, i wybierz Rozwiązanie.
   2. Jeśli masz dostęp do rzeczywistego żądania wysłanego do serwera docelowego/backendu, wykonaj te czynności:
      1. Sprawdź rozmiar ładunku przekazywanego w odpowiedzi razem z Nagłówek Content-Encoding został wysłany w odpowiedzi.
      2. Jeśli zauważysz, że nagłówek odpowiedzi Content-Encoding jest ustawiony na gzip, a rozmiar ładunku nieskompresowanego jest większy niż dozwolone jest ograniczenie w Apigee Edge, to jest przyczyną ten błąd.

         Przykładowa odpowiedź odebrana 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 oraz rozmiar pliku testzippedfile.gz w odpowiedzi jest mniejszy niż limit, jednak rozmiar nieskompresowanego pliku testzippedfile wynosił Ok. 15 MB.

   .

   Logi procesora wiadomości

   Przy użyciu dzienników procesora wiadomości:

   1. Jeśli jesteś użytkownikiem Private Cloud, możesz używać logów procesora wiadomości do: określenie najważniejszych informacji o błędach HTTP 502.

   2. Sprawdzanie logów procesora wiadomości

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

   3. Wyszukaj błędy (502) w danym okresie (jeśli problem wystąpił w przeszłości) lub jeśli masz jakieś żądania, które nadal kończą się niepowodzeniem 502 Możesz użyć następujących ciągów wyszukiwania:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Znajdziesz tam wiersze z domeny 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. W trakcie procesu dekompresji, gdy tylko procesor wiadomości określi łączna liczba bajtów odczytanych wynosi > 10 MB, zatrzymuje się i wydrukuje następujący wiersz:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Oznacza to, że Rozmiar ładunku odpowiedzi wynosi więcej niż 10 MB, a Apigee zgłasza błąd, gdy rozmiar zaczyna przekraczać limit 10 MB i zawiera kod 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 informacjami dla Request/response size w Limity brzegowe Apigee.

1. Jeśli jesteś użytkownikiem Public Cloud, maksymalny limit żądań i odpowiedzi rozmiar ładunku jest taki sam jak w przypadku Request/response size w Limity brzegowe Apigee.
2. Jeśli jesteś użytkownikiem Private Cloud , możliwe, że domyślne maksimum zostało zmienione limitu rozmiaru ładunku żądań i odpowiedzi (mimo że nie jest to zalecana metoda). Maksymalny rozmiar ładunku żądania możesz określić, postępując zgodnie z instrukcjami w Jak sprawdzić aktualny limit

Jak sprawdzić obecny limit?

Z tej sekcji dowiesz się, jak sprawdzić, czy usługa Pole HTTPResponse.body.buffer.limit zostało zaktualizowane o nową wartość w wiadomości Procesory.

1. Na komputerze z procesorem wiadomości 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 jest taki:

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

3. Zwróć uwagę, że w przykładowych danych wyjściowych powyżej Parametr HTTPResponse.body.buffer.limit został ustawiony na wartość 10m w http.properties

   Wskazuje to, że limit rozmiaru ładunku żądania skonfigurowany w Apigee dla Cloud Private Cloud zajmuje 10 MB.

Jeśli nadal potrzebujesz pomocy zespołu pomocy Apigee, wejdź na Musi zbierać informacje diagnostyczne.

Musi zbierać informacje diagnostyczne

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

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

• Nazwa organizacji
• Nazwa środowiska
• Nazwa serwera proxy interfejsu API
• Kompletne 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 serwera backendu wraz z rozmiarem ładunku

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

• Pełny komunikat o błędzie zaobserwowany dla nieudanych żądań
• Nazwa organizacji
• Nazwa środowiska
• Pakiet serwera proxy interfejsu API
• Plik śledzenia nieudanych żądań do interfejsu API
• Kompletne polecenie curl użyte do odtworzenia błędu 502
• Pełne dane wyjściowe odpowiedzi z serwera docelowego lub serwera 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 przez wartości rzeczywiste.

• Dzienniki systemowe procesora wiadomości /opt/apigee/var/log/edge-message-processor/logs/system.log