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

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

Видео

Посмотрите следующие видеоролики, чтобы узнать больше о решении проблемы с ошибкой 500 Internal Server Error.

Симптом

Клиентское приложение получает в ответ на вызовы API HTTP-приложения с кодом состояния 500 и сообщением "Internal Server Error" . Ошибка 500 Internal Server Error может быть вызвана ошибкой во время выполнения какой-либо политики в 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 Internal Server Error может возникать по ряду различных причин. В Edge причины можно разделить на две основные категории в зависимости от места возникновения ошибки:

Ошибка выполнения в политике пограничного сервера

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

Диагноз

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

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

1. Убедитесь, что ошибка была вызвана выполнением политики. Подробности см. в разделе «Определение источника проблемы» .
2. Если ошибка произошла во время выполнения политики, продолжите. Если ошибка вызвана серверной частью, перейдите к разделу «Ошибка на серверной части» .
3. В трассировке выберите API-запрос, который завершается ошибкой 500 Internal Server Error.
4. Проанализируйте запрос и выберите конкретную политику, которая завершилась с ошибкой, или поток с именем «Error», следующий непосредственно за неудачной политикой в ​​трассировке.
5. Более подробную информацию об ошибке можно получить, проверив поле «Ошибка» в разделе «Свойства» или содержимое сообщения об ошибке.
6. Используя собранную информацию об ошибке, попытайтесь определить её причину.

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

Если у вас нет сессии трассировки пользовательского интерфейса, то:

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

Разрешение

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

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

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

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

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

1. Вот пример, где серверная служба выдает ошибку 404 в рамках политики вызова службы. Конечному пользователю отправляется следующее сообщение об ошибке:

   {
   "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" указывает причину сбоя политики вызова сервиса как "ResponseCode 404 is treated as error". Эта ошибка может возникнуть, если ресурс, к которому осуществляется доступ через URL-адрес бэкэнд-сервера в политике вызова сервиса, недоступен.
4. Проверьте доступность ресурса на бэкэнд-сервере. Возможно, он временно/постоянно недоступен или был перемещен в другое место.

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

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

Пример 2: Сбой в политике извлечения переменных

Теперь рассмотрим другой пример, где ошибка 500 Internal Server Error вызвана ошибкой в ​​политике извлечения переменных, и посмотрим, как устранить и решить эту проблему.

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

   

2. Выберите политику извлечения переменных, которая не прошла проверку, прокрутите вниз и посмотрите раздел «Содержимое ошибки» для получения более подробной информации:
   
   
3. Содержимое ошибки указывает на то, что переменная "serviceCallout.oamCookieValidationResponse" недоступна в политике извлечения переменных. Как следует из названия переменной, она должна содержать ответ предыдущей политики вызова сервиса.
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. Просмотрите журнал обработчика сообщений ( /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

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

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

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

   Как правило, эта ошибка наблюдается при следующих обстоятельствах:

   • Когда серверная часть не настроена на разрешение трафика от пограничных обработчиков сообщений.
   • Если серверная часть не прослушивает указанный порт.

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

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

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

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

Пример 3: Сбой в политике JavaCallout

Рассмотрим еще один пример, где ошибка 500 Internal Server Error вызвана ошибкой в ​​политике Java Callout, и посмотрим, как устранить и решить эту проблему.

1. Приведенная ниже трассировка пользовательского интерфейса показывает код состояния 500 из-за ошибки в политике вызовов Java:

   

2. Выберите поток с именем «Ошибка», а затем — неудачную политику вызова Java, чтобы получить подробную информацию об ошибке, как показано на рисунке ниже:

   

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

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

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

Ошибка на бэкэнд-сервере.

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

Диагноз

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

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

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

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

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

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

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

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

   

3. Для получения подробной информации об ошибке проверьте раздел «Содержание ответа» .

   

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

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

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

   Опция «Логирование NodeJS» в пользовательском интерфейсе Edge — вкладка «Обзор» в настройках API-прокси.

   

Разрешение

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

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

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

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

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

Примечание: Действия, описанные в этом разделе, могут быть выполнены как пользователями публичного, так и частного облака.

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

Использование мониторинга API

Примечание: Действия, описанные в этом разделе, могут быть выполнены только пользователями публичного облака.

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

Рассмотрим пример сценария , демонстрирующий, как устранять проблемы с кодами состояния 5xx в ваших API с помощью мониторинга API. Например, вы можете настроить оповещение, которое будет отправляться, когда количество кодов состояния 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. Если ошибка связана с целевым сервером, перейдите к разделу «Ошибка на бэкэнд-сервере» .