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

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

Симптом

Клиентское приложение получает код состояния ответа 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 может возникнуть по ряду различных причин. В этом сборнике руководств основное внимание уделяется внутренней ошибке сервера 500, вызванной доступом к полезной нагрузке запроса/ответа при включенной потоковой передаче .

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

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

Диагностика

Процедура №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 дает сбой. Это указывает на то, что полезная нагрузка должна быть в формате 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» (запись аналитических данных) в трассировке, выполнив действия, указанные ниже:
    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 с источником ошибки в качестве прокси-сервера.

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

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

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

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

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

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