502 Плохой шлюз — TooBigBody

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Симптом

Клиентское приложение получает код состояния HTTP 502 Bad Gateway с кодом ошибки protocol.http.TooBigBody в качестве ответа на вызовы API.

Сообщение об ошибке

Клиентское приложение получает следующий код ответа:

HTTP/1.1 502 Bad Gateway

Кроме того, вы можете увидеть следующее сообщение об ошибке:

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

Возможные причины

Эта ошибка возникает, если размер полезной нагрузки, отправленный целевым/внутренним сервером в Apigee Edge как часть ответа HTTP, превышает допустимый предел в Apigee Edge .

Вот возможные причины ошибки:

Причина Описание Инструкции по устранению неполадок применимы для
Размер полезных данных ответа превышает допустимый предел Размер полезной нагрузки, отправленный целевым/внутренним сервером как часть HTTP-ответа Apigee, превышает допустимый предел в Apigee. Пользователи Edge Public и Private Cloud
Размер полезных данных ответа превышает допустимый предел после распаковки Размер полезной нагрузки, отправленной в сжатом формате целевым/внутренним сервером как часть HTTP-ответа Apigee, превышает допустимый предел при распаковке Apigee. Пользователи Edge Public и Private Cloud

Общие этапы диагностики

Для диагностики этой ошибки используйте один из следующих инструментов/методов:

API-мониторинг

Чтобы диагностировать ошибку с помощью мониторинга API:

  1. Войдите в пользовательский интерфейс Apigee Edge как пользователь с соответствующей ролью .

  2. Переключитесь на организацию, в которой вы хотите разобраться в проблеме.

  3. Перейдите на страницу Анализ > Мониторинг API > Расследование .
  4. Выберите конкретный период времени, в течение которого вы наблюдали ошибки.
  5. Вы можете выбрать прокси- фильтр, чтобы сузить код неисправности.
  6. Постройте график зависимости кода неисправности от времени .

  7. Выберите ячейку с кодом неисправности protocol.http.TooBigBody http.TooBigBody, как показано ниже:

  8. Вы увидите информацию о коде неисправности protocol.http.TooBigBody , как показано ниже:

  9. Нажмите «Просмотреть журналы» и разверните строку с невыполненным запросом.

  10. В окне «Журналы» обратите внимание на следующие детали:
    • Код состояния: 502
    • Источник неисправности: target
    • Код ошибки: protocol.http.TooBigBody .
  11. Если источник сбоя имеет значение target , а код сбоя имеет значение protocol.http.TooBigBody , это означает, что ответ HTTP от целевого/внутреннего сервера имеет размер полезных данных ответа, превышающий разрешенный предел в Apigee Edge .

След

Чтобы диагностировать ошибку с помощью инструмента трассировки:

  1. Включите сеанс трассировки и выполните одно из следующих действий:
    • Дождитесь появления ошибки 502 Bad Gateway или
    • Если вы можете воспроизвести проблему, выполните вызов API и воспроизведите ошибку 502 Bad Gateway .
  2. Выберите один из неудачных запросов и проверьте трассировку.
  3. Перемещайтесь по различным этапам трассировки и найдите место, где произошел сбой.

  4. Перейдите к этапу «Ошибка» сразу после получения ответа от этапа целевого сервера, как показано ниже:

    Обратите внимание на значения ошибки из трассировки:

    • ошибка: Body buffer overflow
    • error.class : com.apigee.errors.http.server.BadGateway

    Это указывает на то, что Apigee Edge (компонент процессора сообщений) выдает ошибку, как только получает ответ от внутреннего сервера, из-за того, что размер полезной нагрузки превышает допустимый предел.

  5. Вы увидите ошибку на этапе отправки ответа клиенту, как показано ниже:

  6. Обратите внимание на значения ошибки из трассировки. Приведенный выше пример трассировки показывает:
    • ошибка: 502 Bad Gateway
    • Содержимое ошибки: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}

  7. Перейдите к этапу «Ответ, полученный от целевого сервера» , как показано ниже для различных сценариев:

    Несжатый

    Сценарий № 1: Полезная нагрузка ответа отправляется в несжатом виде.

    Обратите внимание на значения ошибки из трассировки:

    • Ответ, полученный от целевого сервера : 200 OK
    • Длина контента (из раздела «Заголовки ответов» ): ~ 11 МБ.

    Сжатый

    Сценарий 2. Полезные данные запроса отправляются в сжатом виде.

    Обратите внимание на значения ошибки из трассировки:

    • Ответ, полученный от целевого сервера : 200 OK
    • Content-Encoding : если вы видите этот заголовок в разделе «Заголовки ответов» , обратите внимание на значение. Например, в этом примере значением является gzip .

  8. Обратите внимание на тело в разделе «Содержание ответа» :

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

  9. Перейдите к этапу AX (запись аналитических данных) в трассировке и щелкните его, чтобы просмотреть соответствующие сведения.

  10. Прокрутите страницу «Сведения о этапе» до раздела «Чтение переменных» и определите значения target.received.content.length , которые указывают:
    • Фактический размер полезных данных ответа, когда он отправляется в несжатом формате и
    • Размер полезных данных ответа при распаковке Apigee, когда полезные данные отправляются в сжатом формате. В этом сценарии оно всегда будет таким же, как и значение разрешенного лимита (10 МБ).

    Несжатый

    Сценарий 1. Полезные данные ответа отправляются в несжатом виде.

    Обратите внимание на значение target.received.content.length :

    Заголовки запросов Ценить
    target.received.content.length ~11 МБ

    Сжатый

    Сценарий 2. Полезные данные запроса отправляются в сжатом виде.

    Обратите внимание на значение target.received.content.length :

    Заголовки запросов Ценить
    target.received.content.length ~10 МБ

  11. В следующей таблице объясняется, почему Apigee возвращает ошибку 502 в двух сценариях, основанных на значении target.received.content.length :

    Сценарий Значение target.received.content.length Причина неудачи
    Полезная нагрузка ответа в несжатом формате ~11 МБ Размер > допустимый предел 10 МБ.
    Полезная нагрузка ответа в сжатом формате ~10 МБ

    Предельный размер превышен при распаковке

НГИНКС

Чтобы диагностировать ошибку с помощью журналов доступа NGINX:

  1. Если вы являетесь пользователем частного облака , вы можете использовать журналы доступа NGINX для определения ключевой информации об ошибках HTTP 502 .

  2. Проверьте журналы доступа NGINX:

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

    Где: ORG , ENV и PORT# заменяются фактическими значениями.

  3. Выполните поиск, чтобы узнать, возникли ли какие-либо ошибки 502 в течение определенного периода времени (если проблема возникла в прошлом) или есть ли какие-либо запросы, которые по-прежнему не выполняются с 502 .
  4. Если вы обнаружите какие-либо ошибки 502 с кодом X-Apigee-fault-code , соответствующим значению protocol.http.TooBigBody , определите значение X-Apigee-fault-source.

    Пример ошибки 502 из журнала доступа NGINX:

    Приведенный выше пример записи из журнала доступа NGINX имеет следующие значения для X-Apigee-fault-code и X-Apigee-fault-source:

    Заголовки ответов Ценить
    X-Apigee-код неисправности protocol.http.TooBigBody
    X-Apigee-источник-ошибки target

Причина: Размер полезной нагрузки ответа превышает допустимый предел.

Диагностика

  1. Определите код ошибки , источник ошибки и размер полезной нагрузки ответа для ошибки, наблюдаемой с помощью мониторинга API, инструмента трассировки или журналов доступа NGINX, как описано в разделе «Общие шаги диагностики для сценария № 1».
  2. Если источник сбоя имеет значение target , это означает, что размер полезных данных ответа, отправленный целевым/внутренним сервером в Apigee, превышает допустимый предел в Apigee Edge .
  3. Проверьте размер полезной нагрузки ответа , определенный на шаге 1 .
  4. Убедитесь, что размер полезных данных ответа действительно превышает допустимый предел 10 МБ, проверив фактический ответ, выполнив следующие действия:
    1. Если у вас нет доступа к фактическому запросу, отправленному на целевой/внутренний сервер, перейдите к разделу «Разрешение» .
    2. Если у вас есть доступ к фактическому запросу, отправленному на целевой/внутренний сервер, выполните следующие шаги:
      1. Если вы являетесь пользователем публичного или частного облака , отправьте запрос непосредственно на внутренний сервер с самого внутреннего сервера или любого другого компьютера, с которого вам разрешено отправлять запросы на внутренний сервер.
      2. Если вы являетесь пользователем частного облака , вы также можете отправить запрос на внутренний сервер от одного из процессоров сообщений.
      3. Проверьте размер полезных данных, переданных в ответе, проверив заголовок Content-Length.
      4. Если вы обнаружите, что размер полезных данных превышает допустимый предел в Apigee Edge , то это и есть причина проблемы.

    Пример ответа внутреннего сервера:

    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>

    В приведенном выше примере вы можете видеть, что Content-Length: 11534336 (which is ~11 MB) что является причиной этой ошибки, поскольку оно превышает допустимый предел в Apigee Edge .

Разрешение

См. Резолюцию .

Причина: Размер полезной нагрузки ответа превышает допустимый предел после распаковки.

Если полезные данные ответа отправляются в сжатом формате , а для заголовка ответа Content-Encoding установлено значение gzip , Apigee распаковывает полезные данные ответа. Если во время процесса распаковки Apigee обнаружит, что размер полезных данных превышает допустимый предел в Apigee Edge. , затем он прекращает дальнейшую распаковку и немедленно отвечает 502 Bad Gateway и кодом ошибки protocol.http.TooBigBody .

Диагностика

  1. Определите код ошибки, источник ошибки и размер полезной нагрузки ответа для наблюдаемой ошибки с помощью мониторинга API, инструмента трассировки или журналов доступа NGINX, как описано в разделе «Общие шаги диагностики для сценария № 2».
  2. Если источник сбоя имеет значение target , это означает, что размер полезных данных ответа, отправленный целевым/внутренним приложением в Apigee, превышает допустимый предел в Apigee Edge.
  3. Проверьте размер полезной нагрузки ответа , определенный на шаге 1 .
    • Если размер полезных данных превышает допустимый предел 10 МБ, это и есть причина ошибки.
    • Если размер полезных данных ~ 10 МБ разрешен, то возможно, что полезные данные ответа передаются в сжатом формате. В этом случае проверьте размер несжатых полезных данных сжатого ответа.
  4. Вы можете проверить, был ли ответ от цели/серверной части отправлен в сжатом формате, а размер несжатого изображения превышал допустимый предел, используя один из следующих методов:

    След

    Используя инструмент «Трассировка»:

    1. Если вы зафиксировали трассировку неудачного запроса, обратитесь к шагам, подробно описанным в разделе Трассировка и
      1. Определите значение target.received.content.length
      2. Проверьте, содержит ли запрос от клиента заголовок Content-Encoding: gzip .
    2. Если значение target.received.content.length находится в пределах допустимого предела в 10 МБ, а заголовок ответа Content-Encoding: gzip , то это причина этой ошибки.

    Фактический запрос

    Использование фактического запроса:

    1. Если у вас нет доступа к фактическому запросу, отправленному на целевой/внутренний сервер, перейдите к разделу «Разрешение» .
    2. Если у вас есть доступ к фактическому запросу, отправленному на целевой/внутренний сервер, выполните следующие шаги:
      1. Проверьте размер полезных данных, переданных в ответе вместе с заголовком Content-Encoding , отправленным в ответе.
      2. Если вы обнаружите, что для заголовка ответа Content-Encoding установлено значение gzip , а размер несжатых полезных данных превышает допустимый предел в Apigee Edge , то это и есть причина данной ошибки.

        Пример ответа, полученного от внутреннего сервера:

        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>

        В приведенном выше случае отправляется заголовок Content-Encoding: gzip и размер файла testzippedfile.gz в ответе меньше предельного, однако размер несжатого файла testzippedfile составил ~15 МБ.

    Журналы процессора сообщений

    Использование журналов процессора сообщений:

    1. Если вы являетесь пользователем частного облака , вы можете использовать журналы процессора сообщений для определения ключевой информации об ошибках HTTP 502 .

    2. Проверьте журналы процессора сообщений

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

    3. Выполните поиск, чтобы узнать, возникли ли какие-либо ошибки 502 в течение определенного периода времени (если проблема возникла в прошлом) или есть ли какие-либо запросы, которые по-прежнему завершаются с ошибкой 502 . Вы можете использовать следующие строки поиска:

      grep -ri "chunkCount"

      grep -ri "BadGateway: Body buffer overflow"
    4. Вы найдете строки из system.log аналогичные показанным ниже ( TotalRead и chunkCount могут отличаться в вашем случае): 
      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. Как только в процессе распаковки процессор сообщений определяет, что общее количество прочитанных байт > 10 МБ, он останавливается и печатает следующую строку:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Это означает, что размер полезной нагрузки ответа превышает 10 МБ, и Apigee выдает ошибку, когда размер начинает превышать предел в 10 МБ с кодом ошибки в качестве protocol.http.TooBigBody

Разрешение

Исправить размер

Вариант № 1 [рекомендуется]: Исправьте приложение целевого сервера, чтобы оно не отправляло размер полезной нагрузки, превышающий предел Apigee.

  1. Проанализируйте причину, по которой конкретный целевой сервер отправляет размер ответа/полезной нагрузки, превышающий допустимый предел, определенный в разделе «Пределы» .
  2. Если это нежелательно, измените приложение целевого сервера так, чтобы оно отправляло размер ответа/полезной нагрузки меньше допустимого предела.
  3. Если это желательно и вы хотите отправить ответ/полезную нагрузку, превышающую разрешенный лимит, перейдите к следующим параметрам.

Подписанный шаблон URL

Вариант № 2 [рекомендуется]: используйте шаблон подписанных URL-адресов в Apigee JavaCallout.

Для полезных данных размером более 10 МБ Apigee рекомендует использовать шаблон подписанных URL-адресов в Apigee JavaCallout, как показано в примере Edge Callout: Signed URL Generator на GitHub.

Потоковое вещание

Вариант №3: использовать потоковую передачу

Если вашему прокси-серверу API необходимо обрабатывать очень большие запросы и/или ответы, вы можете включить потоковую передачу в Apigee.

КвК

Вариант № 4. Используйте свойство CwC, чтобы увеличить лимит буфера.

Эту опцию следует использовать только в том случае, если вы не можете использовать ни одну из рекомендуемых опций, поскольку при увеличении размера по умолчанию могут возникнуть проблемы с производительностью.

Apigee предоставляет свойство CwC , которое позволяет увеличить лимит размера полезной нагрузки запроса и ответа. Подробную информацию см. в разделе Установка ограничения размера сообщения на маршрутизаторе или процессоре сообщений .

Пределы

Apigee ожидает, что клиентское приложение и внутренний сервер не будут отправлять размеры полезной нагрузки, превышающие разрешенный предел, как указано для Request/response size в Apigee Edge Limits .

  1. Если вы являетесь пользователем публичного облака , то максимальный предел размера полезной нагрузки запроса и ответа соответствует Request/response size указанному в Apigee Edge Limits .
  2. Если вы являетесь пользователем частного облака, возможно, вы изменили максимальный предел по умолчанию для размера полезной нагрузки запроса и ответа (хотя это не рекомендуется). Вы можете определить максимальный размер полезных данных запроса, следуя инструкциям в разделе Как проверить текущий предел .

Как проверить текущий лимит?

В этом разделе объясняется, как проверить, что свойство HTTPResponse.body.buffer.limit обновлено новым значением в процессорах сообщений.

  1. На компьютере с процессором сообщений найдите свойство HTTPResponse.body.buffer.limit в каталоге /opt/apigee/edge-message- processor/conf и проверьте, какое значение было установлено, как показано ниже: 

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

  2. Пример результата выполнения приведенной выше команды выглядит следующим образом: 

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

  3. Обратите внимание, что в приведенном выше примере для свойства HTTPResponse.body.buffer.limit установлено значение 10m в http.properties .

    Это указывает на то, что ограничение размера полезных данных запроса, настроенное в Apigee для частного облака, составляет 10 МБ.

Если вам по-прежнему нужна помощь со стороны службы поддержки Apigee, перейдите к разделу «Необходимо собрать диагностическую информацию» .

Необходимо собрать диагностическую информацию

Соберите следующую диагностическую информацию, а затем обратитесь в службу поддержки Apigee Edge :

Если вы являетесь пользователем Public Cloud , предоставьте следующую информацию:

  • Название организации
  • Имя среды
  • Имя API-прокси
  • Полная команда завитка, используемая для воспроизведения ошибки 502
  • Файл трассировки запросов API
  • Полный вывод ответа от целевого/внутреннего сервера вместе с размером полезной нагрузки.

Если вы являетесь пользователем частного облака , предоставьте следующую информацию:

  • Полное сообщение об ошибке, наблюдаемое для неудачных запросов
  • Название организации
  • Имя среды
  • Пакет API-прокси
  • Файл трассировки неудачных запросов API
  • Полная команда завитка, используемая для воспроизведения ошибки 502
  • Полный вывод ответа от целевого/внутреннего сервера вместе с размером полезной нагрузки.

  • Журналы доступа NGINX /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

    Где: ORG , ENV и PORT# заменяются фактическими значениями.

  • Системные журналы процессора сообщений /opt/apigee/var/log/edge-message-processor/logs/system.log