500 Внутренняя ошибка сервера — потоковая передача включена

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

Симптом

Клиентское приложение получает HTTP-ответ со статусом 500 и сообщением "Внутренняя ошибка сервера при вызовах API".

Сообщения об ошибках

Клиентские приложения могут получить сообщение об ошибке, как показано ниже:

HTTP/1.1 500 Internal Server Error

За этим может последовать сообщение об ошибке, примерно такое:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

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

Ошибка 500 Internal Server Error может возникать по ряду различных причин. В этом руководстве рассматривается ошибка 500 Internal Server Error, возникающая при доступе к содержимому запроса/ответа при включенной потоковой передаче .

Причина Описание Кто может выполнить действия по устранению неполадок?
Доступ к полезной нагрузке при включенной потоковой передаче. Произошла ошибка, поскольку доступ к содержимому запроса/ответа осуществляется при включенной потоковой передаче. Пользователи частных и публичных облачных решений на периферии сети

Причина: Доступ к полезной нагрузке при включенной потоковой передаче.

Диагноз

Процедура №1: Использование трассировки

  1. Включите сеанс трассировки и выполните вызов API для воспроизведения проблемы — ошибка 500 Internal Server Error.
  2. Выберите один из запросов, завершившихся неудачей, и изучите трассировку.
  3. Проследите за различными этапами трассировки и определите место возникновения сбоя.
  4. Эта ошибка могла возникнуть во время анализа политики содержимого запроса/ответа.
  5. Вот пример скриншота трассировки, демонстрирующий политику JSONThreatProtection . Ошибка "Ожидается } в строке 1" :

    alt_text

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

    Неработающая политика: JSONThreatProtection

    Последовательность действий: Запрос через прокси-сервер

  6. Изучите некорректное определение политики и проверьте обрабатываемый полезный груз.

    В приведенном примере проверьте политику JSONThreatProtection с именем JSON-Threat-Protection , которая завершилась с ошибкой, и отметьте элемент <Source> .

    <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

    Обратите внимание, что элемент <Source> указывает на request. Это означает, что ошибка произошла при разборе содержимого запроса.

  7. Определите тип обрабатываемых данных, проверив запрос к API.

    8. Вы можете проверить содержимое полезной нагрузки запроса и заголовка Content-Type в API-запросе. В следующем примере команды curl используется полезная нагрузка в формате JSON.

    curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

    Вы также можете проверить политику, которая не проходит проверку, и определить тип обрабатываемых данных. В приведенном выше примере не проходит проверка политики JSON-Threat-Protection. Это указывает на то, что данные должны быть в формате JSON.

  8. Проверьте, соответствует ли полезная нагрузка правильному формату. Если полезная нагрузка недействительна, может возникнуть следующая ошибка.

  9. Если полезная нагрузка действительна, но вы по-прежнему получаете ошибки, указанные в разделе « Сообщения об ошибках» , то причиной этих ошибок является доступ к полезной нагрузке при включенной потоковой передаче.

    В зависимости от содержимого полезной нагрузки, анализируемой политикой (как определено на шаге №6), изучите содержимое полезной нагрузки в инструменте трассировки на соответствующем этапе.

    В приведенном примере происходит анализ содержимого запроса, поэтому изучите этап "Запрос получен от клиента" в трассировке и проверьте содержимое запроса.

    alt_text

    Если поле «Содержимое запроса» оказывается пустым, как показано на скриншоте выше, даже если вы отправили корректные данные, это указывает на вероятную причину проблемы: включена потоковая передача запросов.

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

    Аналогично, если при возникновении ошибки происходит разбор содержимого ответа, проверьте его содержимое на этапе "Получен ответ от целевого сервера" .

  10. Далее проверьте определения прокси-сервера и целевой конечной точки в зависимости от того, где в потоке API-прокси используется неработающая политика. Убедитесь, что потоковая передача включена.

    В приведенном примере неудачная политика выполнялась в потоке запросов прокси-сервера (как определено на шаге № 5 выше); поэтому изучите конечную точку прокси-сервера:

    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

    Как видно из приведенного выше примера, потоковая передача запросов включена, о чем свидетельствует значение свойства " request.streaming.enabled" равное true.

    Таким образом, причиной ошибки является использование политики JSONThreatProtection в API-прокси, которая обращается к полезной нагрузке запроса при включенной потоковой передаче. Это приводит к ошибкам, поскольку запускает буферизацию в API-прокси и сводит на нет цель использования потоковой передачи в Apigee Edge.

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

  11. Вы можете убедиться, что ошибка 500 вызвана политикой, проверив значение параметра "X-Apigee-fault-source" в фазе "AX" (Analytics Data Recorded) в трассировке, выполнив следующие шаги:
    1. Нажмите на этап " AX " (Запись аналитических данных), как показано на скриншоте ниже:

      alt_text

    2. Прокрутите вниз в разделе «Подробности этапа» до раздела «Заголовки ошибок» и Определите значения параметров "X-Apigee-fault-code" , "X-Apigee-fault-source" и "X-Apigee-fault-policy" , как показано ниже:

      alt_text

    3. Если значение параметра "X-Apigee-fault-source" равно "policy" , как показано на рисунке выше, это указывает на то, что ошибка вызвана доступом политики к полезной нагрузке при включенной потоковой передаче.

Разрешение

Доступ к полезной нагрузке при включенной потоковой передаче является антипаттерном, как объясняется в разделе «Антипаттерн: Доступ к полезной нагрузке запроса/ответа при включенной потоковой передаче» .

  1. Если вы хотите обработать полезную нагрузку, вам необходимо отключить потоковую передачу в прокси/целевой конечной точке, удалив свойства " request.streaming.enabled" and " response.streaming.enabled" как показано в примере ProxyEndpoint ниже:
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    ИЛИ

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

Примечание:

  • В этом сценарии для обработки полезной нагрузки запроса с включенной потоковой передачей использовалась политика JSONThreatProtection. Это привело к ошибке 500 Internal Server Error с различными другими ошибками.
  • Эти ошибки также могут наблюдаться в политиках, таких как JSONToXML и XMLToJSON, которые обрабатывают данные запроса или ответа при включенной потоковой передаче.
  • Мы настоятельно рекомендуем не использовать подобные политики в прокси-серверах, которым требуется доступ к данным при включенной потоковой передаче.
  • Это является антипаттерном, как описано в статье «Антипаттерн: Доступ к содержимому запроса/ответа при включенной потоковой передаче» .

Диагностика проблем с помощью мониторинга API.

Если вы используете частное облако, пропустите эту процедуру.

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

Рассмотрим пример сценария , демонстрирующий, как устранять проблемы с ошибками 5xx в ваших API с помощью мониторинга API. Например, вы можете настроить оповещение, которое будет отправляться, когда количество ошибок 500 превысит определенный порог.

Если вы хотите получать уведомления о появлении ошибки 500 в ответе от политики, вам необходимо настроить оповещение для кода состояния 500, указав в качестве источника ошибки Proxy.

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

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

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

  • Название организации
  • Название среды
  • Имя API-прокси
  • Выполните команду curl вместе с содержимым запроса (если таковое имеется), чтобы воспроизвести ошибку 500.
  • Файл трассировки, содержащий запросы с ошибкой 500 Internal Server Error.
  • Если ошибки 500 в настоящее время не возникают, укажите период времени с указанием часового пояса, когда ошибки 500 возникали в прошлом.

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

  • Полное сообщение об ошибке, полученное для неудачных запросов.
  • Организация, название среды и имя API-прокси, для которых наблюдаются ошибки 500.
  • Пакет API-прокси
  • Полезная нагрузка, использованная в запросе (если таковая имеется)
  • Файл трассировки, содержащий запросы с ошибкой 500 Internal Server Error.
  • Журналы доступа NGINX ( /opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log )
  • Журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log )
  • Период времени с указанием часового пояса, когда возникали ошибки 500.