502 Bad Gateway - TooBigBody

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

Symptom

Клиентское приложение получает код статуса 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
Размер полезной нагрузки ответа после декомпрессии превышает допустимое значение Размер полезной нагрузки, отправленной целевым или внутренним сервером в сжатом формате в составе HTTP-ответа Apigee, превышает допустимый лимит при распаковке Apigee. Пользователи общедоступного и частного облака Edge

Распространенные этапы диагностики

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

Мониторинг API

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

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

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

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

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

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

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

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

Трассировка

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

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

  4. Перейдите к этапу Error (Ошибка), который следует сразу после этапа Response received from target server (Получен ответ от целевого сервера), как показано ниже:

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

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

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

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

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

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

    Несжатый

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

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

    • Ответ, полученный от целевого сервера: 200 OK
    • Content-Length (из раздела Response Headers): ~11 МБ.

    Размер в сжатом виде

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

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

    • Ответ, полученный от целевого сервера: 200 OK
    • Content-Encoding. Если этот заголовок есть в разделе Response Headers, запишите его значение. Например, в этом примере значением является 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

Чтобы диагностировать ошибку с помощью журналов доступа 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. Если в поле Источник ошибки указано значение 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. Если вы являетесь пользователем Private Cloud, то можете использовать журналы Message Processor, чтобы определить ключевую информацию об ошибках 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. Во время распаковки, как только Message Processor определит, что общее количество прочитанных байтов превышает 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. Используйте свойство "Конверсии в магазине", чтобы увеличить лимит буфера

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

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

Ограничения

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

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

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

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

  1. На компьютере Message Processor найдите свойство 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.

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

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

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

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

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

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

  • Системные журналы Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log