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

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

Видео

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

Симптом

Клиентское приложение получает код состояния 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 причины можно разделить на две основные категории в зависимости от того, где произошла ошибка:

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

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

Диагностика

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

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

1. Убедитесь, что ошибка вызвана выполнением политики. Подробности см. в разделе Определение источника проблемы .
2. Если ошибка произошла во время выполнения политики, продолжайте. Если ошибка была вызвана внутренним сервером, перейдите к разделу «Ошибка на внутреннем сервере» .
3. Выберите запрос API, который завершается с ошибкой 500 Internal Server Error в трассировке.
4. Изучите запрос и выберите конкретную политику, в которой произошел сбой, или поток с именем «Ошибка», который следует сразу за неудачной политикой в ​​трассировке.
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. Сбой в политике вызова службы из-за ошибки на внутреннем сервере.

Если вызов внутреннего сервера завершается неудачно в рамках политики вызова службы с какой-либо ошибкой, например 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 рассматривается как ошибка». Эта ошибка может возникнуть, если ресурс, доступ к которому осуществляется через URL-адрес внутреннего сервера в политике вызова службы, недоступен.
4. Проверьте доступность ресурса на внутреннем сервере. Он может быть недоступен временно/постоянно или может быть перемещен в другое место.

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

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

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

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

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

   

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

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

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

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

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

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

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

   

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

   

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

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

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

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

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

Диагностика

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

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

1. Убедитесь, что ошибка вызвана внутренним сервером. Подробности см. в разделе Определение источника проблемы .
2. Если ошибка вызвана внутренним сервером, продолжайте. Если ошибка произошла во время выполнения политики, перейдите к разделу «Ошибка выполнения» в Edge Policy .
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 Private Cloud , вы также можете проверить журналы своего процессора сообщений ( /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 во время выполнения политики в прокси-сервере API или на внутреннем сервере.

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

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

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