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

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

Симптом

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

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

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

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

Мониторинг API

Для диагностики ошибки с помощью мониторинга API:

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

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

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

  7. Выберите ячейку, содержащую код ошибки protocol.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
    • Content-Length (из раздела заголовков ответа ): ~11 МБ

    Сжатый

    Сценарий №2: Запрос отправляется в сжатом виде.

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

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

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

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

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

  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

Для диагностики ошибки с помощью журналов доступа 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-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source target

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

Диагноз

  1. Определите код ошибки , источник ошибки и размер полезной нагрузки ответа для обнаруженной ошибки, используя мониторинг API, инструмент трассировки или журналы доступа NGINX, как описано в разделе «Общие шаги диагностики для сценария № 1».
  2. Если в поле Fault Source указано значение 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. Если в поле Fault Source указано значение 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.

CwC

Вариант №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 в http.properties установлено со значением 10m .

    Это означает, что ограничение на размер полезной нагрузки запроса, настроенное в Apigee for Private Cloud, составляет 10 МБ.

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

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

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

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

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

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

  • Полное сообщение об ошибке, полученное для неудачных запросов.
  • Название организации
  • Название среды
  • Пакет API-прокси
  • Файл трассировки для неудачных запросов API
  • Полная команда curl, использованная для воспроизведения ошибки 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