Ошибка 500: внутренняя ошибка сервера

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

Видео

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

Symptom

Клиентское приложение получает код статуса HTTP 500 с сообщением Внутренняя ошибка сервера в качестве ответа на вызовы API. Ошибка 500 (внутренняя ошибка сервера) может быть вызвана ошибкой при выполнении любой политики в Edge или ошибкой на целевом/внутреннем сервере.

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

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

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

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

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

Ошибка 500 может возникать по разным причинам. В Edge причины можно разделить на две основные категории в зависимости от того, где произошла ошибка:

Ошибка выполнения в правилах Edge

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

диагностика;

Диагностика для пользователей частного и общедоступного облака

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

1. Убедитесь, что ошибка вызвана применением правил. Подробнее о том, как определить источник проблемы…
2. Если ошибка произошла во время выполнения правила, перейдите к следующему шагу. Если ошибка вызвана серверной частью, перейдите к разделу Ошибка на сервере.
3. Выберите в трассировке запрос к API, который завершился с ошибкой 500 (внутренняя ошибка сервера).
4. Изучите запрос и выберите правило, которое не удалось выполнить, или поток с названием "Ошибка", который следует за этим правилом в трассировке.
5. Чтобы узнать больше об ошибке, проверьте поле error в разделе Properties или Error content.
6. Используя собранные сведения об ошибке, попробуйте определить ее причину.

Диагностические шаги только для пользователей частного облака

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

1. Убедитесь, что ошибка произошла при выполнении правила. Подробнее о том, как определить источник проблемы…
2. Если ошибка была вызвана выполнением правил, перейдите к следующему шагу. Если ошибка произошла во время выполнения правила, перейдите к следующему шагу. Если ошибка возникла на серверной части, перейдите к разделу Ошибка на серверной части.
3. Используйте журналы доступа NGINX, как описано в разделе Как определить источник проблемы, чтобы найти неработающее правило в прокси-сервере API, а также уникальный идентификатор сообщения запроса.
4. Проверьте журналы Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) и найдите в них уникальный идентификатор запроса.
5. Если вы найдете уникальный идентификатор сообщения запроса, попробуйте получить дополнительную информацию о причине сбоя.

Разрешение

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

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

Если вам нужна помощь в устранении ошибки 500 Internal Server Error или вы подозреваете, что проблема связана с Edge, обратитесь в службу поддержки Apigee.

Пример 1. Сбой в работе правила вызова сервиса из-за ошибки на внутреннем сервере

Если вызов внутреннего сервера в рамках правила Service Callout завершается неудачно с любой ошибкой, например 4XX или 5XX, то это будет считаться внутренней ошибкой сервера 500.

1. Ниже приведен пример, в котором бэкенд-служба завершается с ошибкой 404 в рамках правила Service Callout. Конечному пользователю отправляется следующее сообщение об ошибке:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. На следующем скриншоте интерфейса трассировки показан код статуса 500, вызванный ошибкой в правиле вызова сервиса:

   

3. В этом примере в свойстве "error" указана причина сбоя правила Service Callout: "ResponseCode 404 is treated as error" (Код ответа 404 считается ошибкой). Эта ошибка может возникнуть, если ресурс, к которому осуществляется доступ через URL внутреннего сервера в правиле вызова сервиса, недоступен.
4. Проверьте доступность ресурса на внутреннем сервере. Возможно, он временно или навсегда недоступен или был перемещен в другое место.

Пример 1. Решение

1. Проверьте доступность ресурса на внутреннем сервере. Возможно, он временно или навсегда недоступен или был перемещен в другое место.
2. Исправьте URL серверной части в правилах вызова сервиса, чтобы он указывал на действительный и существующий ресурс.
3. Если ресурс временно недоступен, попробуйте отправить запрос к API, когда ресурс станет доступен.

Пример 2. Ошибка в правилах извлечения переменных

Рассмотрим другой пример, в котором внутренняя ошибка сервера 500 вызвана ошибкой в правиле Extract Variables. Мы расскажем, как устранить эту проблему.

1. На следующем скриншоте сеанса в интерфейсе показан код статуса 500, вызванный ошибкой в правиле Extract Variables:

   

2. Выберите неработающее правило Extract Variables, прокрутите страницу вниз и найдите раздел Error Content (Контент ошибки), чтобы получить более подробную информацию:
   
   
3. Сообщение об ошибке указывает на то, что переменная serviceCallout.oamCookieValidationResponse недоступна в правиле извлечения переменных. Как следует из названия переменной, она должна содержать ответ предыдущего правила Service Callout.
4. Выберите в трассировке правило Service Callout. Вы можете обнаружить, что переменная serviceCallout.oamCookieValidationResponse не задана. Это означает, что вызов к бэкенд-службе не удался, в результате чего переменная ответа оказалась пустой.
5. Несмотря на то что правила в отношении выносок для звонков не были выполнены, выполнение правил после них продолжается, поскольку флаг continueOnError в правилах в отношении выносок для звонков имеет значение true, как показано ниже:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. Обратите внимание на уникальный идентификатор сообщения X-Apigee.Message-ID для этого конкретного запроса API из трассировки, как показано ниже:
   1. Выберите этап "Запись данных аналитики" в запросе.
   2. Прокрутите страницу вниз и запишите значение X-Apigee.Message-ID.

   

7. Посмотрите журнал Message Processor (/opt/apigee/var/log/edge-message-processor/system.log) и найдите уникальный идентификатор сообщения, записанный на шаге 6. При выполнении запроса к API возникла следующая ошибка:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   Указанная выше ошибка означает, что правило Service Callout не сработало из-за ошибки тайм-аута подключения к серверу.

8. Чтобы определить причину ошибки тайм-аута подключения, выполните команду telnet для внутреннего сервера из процессоров сообщений. Команда telnet выдала ошибку "Время ожидания подключения истекло", как показано ниже:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   Обычно эта ошибка возникает в следующих случаях:

   • Если сервер не настроен на прием трафика от процессоров сообщений пограничного сервера.
   • Если внутренний сервер не прослушивает определенный порт.

   В приведенном выше примере, хотя правило Extract Variables не сработало, фактическая причина заключалась в том, что Edge не смог подключиться к серверу бэкэнда в правиле Service Callout. Причина сбоя в том, что конечный сервер не был настроен на разрешение трафика от процессоров сообщений Edge.

   Ваше правило Extract Variables будет работать иначе и может не сработать по другой причине. Чтобы устранить проблему, проверьте сообщение в свойстве error.

Пример 2. Решение

1. Устраните причину ошибки или сбоя в правиле "Извлечь переменные".
2. В примере выше проблема была решена путем исправления конфигурации сети, чтобы разрешить трафик от процессоров сообщений Edge на внутренний сервер. Это было сделано путем добавления IP-адресов процессоров сообщений в белый список на определенном внутреннем сервере. Например, в Linux можно использовать iptables, чтобы разрешить трафик с IP-адресов процессора сообщений на внутреннем сервере.

Пример 3. Сбой в правиле JavaCallout

Рассмотрим ещё один пример, в котором ошибка 500: внутренняя ошибка сервера возникает из-за ошибки в правиле Java Callout. Мы расскажем, как устранить эту проблему.

1. На следующем скриншоте показан код статуса 500, полученный из-за ошибки в правилах вызова Java:

   

2. Выберите поток Error, а затем вызовите правила Java, чтобы получить сведения об ошибке, как показано на рисунке ниже.

   

3. В этом примере свойство error в разделе Properties показывает, что ошибка произошла из-за того, что при подключении к базе данных Oracle из правила JavaCallout использовался пароль с истекшим сроком действия. Ваш собственный вызов Java будет работать иначе и заполнять другое сообщение в свойстве error.
4. Проверьте код правила JavaCallout и убедитесь, что используется правильная конфигурация.

Пример 3. Решение

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

Ошибка на внутреннем сервере

Ошибка 500 "Внутренняя ошибка сервера" также может быть вызвана проблемами с внутренним сервером. В этом разделе рассказывается, как устранить неполадку, если ошибка возникает на сервере.

диагностика;

Диагностика для всех пользователей

Причины других ошибок на стороне сервера могут быть самыми разными. Вам нужно будет диагностировать каждую ситуацию отдельно.

1. Убедитесь, что ошибка вызвана внутренним сервером. Подробнее о том, как определить источник проблемы…
2. Если ошибка была вызвана внутренним сервером, перейдите к следующему шагу. Если ошибка произошла во время выполнения правила, перейдите к разделу Ошибка выполнения правила в Edge.
3. Выполните следующие действия в зависимости от того, есть ли у вас доступ к сеансу трассировки для API, который не удалось вызвать, или если серверная часть представляет собой сервер Node.js:

Если у вас нет сеанса трассировки для неудачного вызова API:

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

Если у вас есть сеанс трассировки для невыполненного вызова API:

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

1. В инструменте Trace выберите запрос к API, который не удалось выполнить из-за внутренней ошибки сервера 500.
2. Выберите этап Ответ получен от целевого сервера из неудачного запроса к API, как показано на рисунке ниже.

   

3. Чтобы узнать подробности об ошибке, проверьте раздел Содержимое ответа.

   

4. В этом примере в контенте ответа, который представляет собой конверт SOAP, строка ошибки содержит сообщение "Не авторизовано". Скорее всего, пользователь не передал на сервер правильные учетные данные (имя пользователя/пароль, токен доступа и т. д.). Чтобы устранить эту проблему, передайте правильные учетные данные на серверную часть.

Если в качестве серверной части используется сервер Node.js:

1. Если в качестве внутреннего сервиса используется сервер Node.js, проверьте журналы Node.js для определенного прокси API в интерфейсе Edge (пользователи как общедоступного, так и частного облака могут проверять журналы Node.js). Если вы используете Edge Private Cloud, то можете также проверить журналы Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log), чтобы получить более подробную информацию об ошибке.
   
   

   Вариант "Журналы NodeJS" на вкладке "Обзор" прокси API в интерфейсе Edge

   

Разрешение

1. После того как вы определите причину ошибки, устраните ее на серверной части.
2. Если это сервер Node.js:
   1. Проверьте, возникает ли ошибка в вашем коде, и устраните ее, если это возможно.
   2. Если ошибка не связана с вашим кодом или вам нужна помощь, обратитесь в службу поддержки Apigee.

Если вам нужна помощь в устранении ошибки 500 Internal Server Error или вы подозреваете, что проблема связана с Edge, обратитесь в службу поддержки Apigee.

Как определить источник проблемы

Чтобы определить, была ли ошибка 500 (внутренняя ошибка сервера) вызвана во время выполнения правила в прокси-сервере API или бэкенд-сервером, выполните одну из следующих процедур.

Как использовать трассировку в интерфейсе

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

1. Если проблема не устранена, включите трассировку в интерфейсе для затронутого API.
2. После того как вы записали трассировку, выберите запрос к API, в котором код ответа указан как 500.
3. Перейдите ко всем этапам неудачного запроса к API и проверьте, на каком из них возвращается ошибка 500 Internal Server Error:
   1. Если ошибка возникает при выполнении правила, перейдите к разделу Ошибка выполнения правила Edge.
   2. Если внутренний сервер вернул ошибку 500 (внутренняя ошибка сервера), перейдите к разделу Ошибка на внутреннем сервере.

Как использовать API Monitoring

Примечание. Шаги в этом разделе могут выполнить только пользователи общедоступного облака.

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

Пошаговое руководство по устранению ошибок 5xx в API с помощью API Monitoring. Например, вы можете настроить оповещение, которое будет срабатывать, когда количество кодов статуса 500 или ошибок steps.servicecallout.ExecutionFailed превысит определенное пороговое значение.

Как использовать журналы доступа NGINX

Примечание. Инструкции в этом разделе предназначены только для пользователей Edge Private Cloud.

Вы также можете обратиться к журналам доступа NGINX, чтобы определить, был ли код статуса 500 сгенерирован во время выполнения правила в прокси-сервере API или на бэкенд-сервере. Это особенно полезно, если проблема возникала в прошлом или если она непостоянна и вы не можете записать трассировку в интерфейсе. Чтобы получить эту информацию из журналов доступа NGINX, выполните следующие действия:

1. Проверьте журналы доступа NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
2. Выполните поиск ошибок 500 для определенного прокси-сервера API за определенный период времени.
3. Если есть ошибки 500, проверьте, связаны ли они с правилами или целевым сервером, как показано ниже:

   Пример записи с ошибкой в правилах

   

   Пример записи с ошибкой целевого сервера

   

4. Определив, какая ошибка возникла (нарушение правил или ошибка целевого сервера):
   1. Если это ошибка правила, перейдите к разделу Ошибка выполнения правила Edge.
   2. Если это ошибка целевого сервера, перейдите к разделу Ошибка на внутреннем сервере.