500 Внутренняя ошибка сервера — внутренний сервер

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

Видео

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

Симптом

Клиентское приложение получает HTTP-статус 500 с сообщением Internal Server Error в ответ на вызовы API.

Код состояния HTTP 500 — это стандартный ответ об ошибке. Он означает, что сервер столкнулся с непредвиденной ситуацией, которая помешала ему выполнить запрос. Эта ошибка обычно возвращается сервером, когда никакой другой код ошибки не подходит.

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

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

HTTP/1.1 500 Internal Server Error

Кроме того, вы можете увидеть сообщение об ошибке, похожее на показанное ниже:

Образец №1

Пример ответа бэкэнд-сервера #1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Образец №2

Пример ответа бэкэнд-сервера #2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

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

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

Возможные причины этой проблемы следующие:

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

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

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

Мониторинг API

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

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

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

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

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

  5. Постройте график зависимости кода ошибки от времени .

  6. Выберите ячейку, содержащую код ошибки messaging.adaptors.http.flow.ErrorResponseCode , как показано ниже:

    ( Посмотреть увеличенное изображение )

  7. Информация о коде ошибки messaging.adaptors.http.flow.ErrorResponseCode отображается следующим образом:

    ( Посмотреть увеличенное изображение )

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

    ( Посмотреть увеличенное изображение )

  9. В окне «Журналы» обратите внимание на следующие сведения:
    • Идентификатор сообщения запроса
    • Код состояния: 500
    • Источник неисправности: target
    • Код ошибки: messaging.adaptors.http.flow.ErrorResponseCode

След

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

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

  1. Включите сеанс трассировки и либо
    • Дождитесь появления ошибки 500 Internal Server Error с кодом ошибки messaging.adaptors.http.flow.ErrorResponseCode , или
    • Если вы можете воспроизвести проблему, выполните вызов API для воспроизведения ошибки 500 Internal Server Error

  2. Убедитесь, что параметр «Показывать все FlowInfos» включен:

  3. Выберите один из запросов, завершившихся неудачей, и изучите трассировку.
  4. Проследите за различными этапами трассировки и определите место возникновения сбоя.

  5. Как правило, ошибка возникает после этапа получения ответа от целевого сервера , как показано ниже:

    ( Посмотреть увеличенное изображение )

  6. Перейдите к этапу AX (Analytics Data Recorded) в трассировке и щелкните по нему.

  7. Прокрутите вниз до раздела «Заголовки ответа с подробными сведениями о фазе» и определите значения X-Apigee-fault-code , X-Apigee-fault-source и X-Apigee-Message-ID, как показано ниже:

    ( Посмотреть увеличенное изображение )

  8. Обратите внимание на значения X-Apigee-fault-code , X-Apigee-fault-source и X-Apigee-Message-ID :
    9. Заголовки ответа Ценить
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Процедура №3: ​​Использование журналов доступа NGINX

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

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

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

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

  3. Выполните поиск, чтобы проверить наличие ошибок 500 с кодом ошибки messaging.adaptors.http.flow.ErrorResponseCode за определенный период времени (если проблема возникала ранее) или если какие-либо запросы по-прежнему завершаются с ошибкой 500 .

  4. Если вы обнаружите ошибки 500 с кодом X-Apigee-fault-code, совпадающим со значением messaging.adaptors.http.flow.ErrorResponseCode , определите значение X-Apigee-fault-source.

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

    ( Посмотреть увеличенное изображение )

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

    Заголовки Ценить
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Причина: Ошибка на серверной части.

Диагноз

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

  1. Определите код ошибки и источник ошибки, используя мониторинг API, инструмент трассировки или журналы доступа NGINX, как описано в разделе «Общие шаги диагностики» .
  2. Если источником ошибки является target , а кодом ошибки — messaging.adaptors.http.flow.ErrorResponseCode , это означает, что ошибка возвращается серверной частью.
  3. Для диагностики причины проблемы можно использовать один из следующих шагов:

    След

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

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

    1. В разделе «Трассировка» выберите API-запрос, завершившийся ошибкой 500 Internal Server Error .

    2. Выберите ответ, полученный от целевого сервера на этапе обработки неудачного запроса API, как показано на рисунке ниже:

      ( Посмотреть увеличенное изображение )

    3. Прокрутите вниз до раздела «Подробности этапа» и проверьте раздел «Содержимое ответа», который содержит ответ от бэкэнд-сервера.

      Пример содержания ответа:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      В приведенном выше ответе обратите внимание, что сообщение об ошибке от бэкэнд-сервера — «Не авторизовано». Это указывает на то, что пользователь, возможно, передал неверные учетные данные, и поэтому получает эту ошибку.

    Вызов бэкэнд-сервера

    Осуществление прямого вызова бэкэнд-сервера:

    Вы можете напрямую обратиться к серверной части и:

    • Проверьте, получаете ли вы тот же ответ 500 Internal Server Error , что и при отправке запроса через Apigee Edge.
    • Проверьте сообщение об ошибке (ответ), полученное от бэкэнд-сервера.

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

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

    3. Если доступ к серверной части возможен только из обработчиков сообщений, то вы можете использовать команду curl , Postman или любой другой REST-клиент и вызывать API серверной части напрямую из обработчика сообщений.

    4. Убедитесь, что серверная часть действительно возвращает 500 Internal Server Error , проверьте сообщение об ошибке (ответ), возвращаемое сервером, и определите причину этой ошибки.

    Журналы бэкэнд-сервера

    Использование журналов бэкэнд-сервера

    1. Просмотрите журналы серверной части и попытайтесь получить более подробную информацию об ошибке и ее причине.
    2. По возможности включите режим отладки на бэкэнд-сервере, чтобы получить более подробную информацию об ошибке и ее причине.

  4. Проверьте, используете ли вы цепочку прокси-серверов в конкретной целевой конечной точке неисправного API-прокси; то есть, вызывает ли целевой сервер/целевая конечная точка другой прокси-сервер в Apigee Edge. Чтобы это определить:

    1. Если у вас есть трассировка неудачного запроса, перейдите к этапу «Запрос отправлен на целевой сервер» и нажмите «Показать Curl» .

    2. Открывается окно "Curl для запроса, отправленного на целевой сервер", в котором можно определить псевдоним хоста целевого сервера.
    3. Проверьте целевую конечную точку вашего API-прокси и убедитесь, что URL-адрес бэкэнд-сервера или имя хоста на целевом сервере указывают на другой прокси-сервер или на ваш собственный бэкэнд-сервер.
    4. Если псевдоним хоста целевого сервера указывает на псевдоним виртуального хоста, то это цепочка прокси-серверов. В этом случае необходимо повторить все описанные выше шаги для цепочки прокси-серверов, пока не будет определена точная причина 500 Internal Server Error . В таких случаях 500 Internal Server Error может возникать и в других цепочках прокси-серверов на других этапах, что можно диагностировать и устранить, используя инструкции, приведенные в этом руководстве или в руководстве по устранению ошибки 500 Internal Server Error .
    5. Если псевдоним хоста целевого сервера указывает на ваш бэкэнд-сервер, перейдите в раздел «Решение» .

Разрешение

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

В приведенном выше примере для решения этой проблемы может потребоваться запросить у пользователей ввод действительных учетных данных.

Важные моменты, на которые следует обратить внимание.

  1. Фактическое сообщение об ошибке, возвращаемое бэкэнд-сервером для 500 Internal Server Error можно просмотреть только в том случае, если вы записали трассировку для запросов, завершившихся с ошибкой.
  2. Ответ бэкэнд-сервера не будет регистрироваться в журналах мониторинга API, журналах доступа NGINX или журналах обработчика сообщений по соображениям безопасности.
  3. Вы можете просмотреть журналы бэкэнд-сервера или включить режим отладки на бэкэнде, чтобы получить более подробную информацию об 500 Internal Server Error и/или просмотреть сообщение об ошибке, возвращаемое бэкэнд-сервером.

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

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

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

  • Название организации
  • Название среды
  • Имя 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

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

  • Журналы системы обработки сообщений /opt/apigee/var/log/edge-message-processor/logs/system.log
  • Период времени с указанием часового пояса, когда возникали ошибки 500 .