500 Internal Server Error

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Videos

Mira los siguientes videos para obtener más información sobre cómo resolver los 500 errores internos del servidor.

Video Descripción
Introducción Proporciona una introducción a los 500 errores internos del servidor y las posibles causas. También demuestra un error interno del servidor 500 en tiempo real junto con los pasos para solucionar el problema.
Soluciona errores de solicitud de oferta de servicio y extracción de variables Demuestra dos errores 500 internos del servidor causados por las políticas de oferta de servicio y de extracción de variables y se muestra cómo solucionar y resolver estos errores.
Soluciona errores de la política de JavaScript Muestra un error interno del servidor 500 causado por una política de JavaScript y los pasos para solucionar este problema.
Soluciona fallas de los servidores de backend Muestra el ejemplo 500 Errores internos del servidor causados por una falla en el servidor de backend y muestra los pasos para resolverlos.

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 500 con el mensaje "Error interno del servidor" como respuesta a las llamadas a la API. El servidor interno 500 podría ser causado por un error durante la ejecución de cualquier política en Edge o por un error en el servidor de destino o backend.

El código de estado HTTP 500 es una respuesta de error genérica. Significa que el servidor encontró un condición inesperada que impidió que completara la solicitud. Este error suele ser el servidor muestra cuando ningún otro código de error es adecuado.

Mensajes de error

Es posible que recibas el siguiente mensaje de error:

HTTP/1.1 500 Internal Server Error

En algunos casos, es posible que veas otro mensaje de error con más detalles. Aquí hay un ejemplo mensaje de error:

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

Causas posibles

El error interno del servidor 500 se puede generar debido a diferentes causas. En Edge, las causas se pueden clasificar en dos categorías principales según dónde ocurrió el error:

Causa Detalles Se proporcionan pasos detallados para la solución de problemas
Error de ejecución en una política perimetral Una política en el proxy de API podría fallar por algún motivo. Usuarios perimetrales de nubes privadas y públicas
Error en el servidor backend El servidor de backend puede fallar por algún motivo. Usuarios perimetrales de nubes privadas y públicas

Error de ejecución en una política perimetral

Una política dentro de el proxy de API puede fallar por algún motivo. Esta sección explica cómo solucionar el problema si el error interno del servidor 500 se produce durante la ejecución de una política.

Diagnóstico

Pasos de diagnóstico para usuarios de nubes privadas y públicas

Si tienes la sesión de la IU de seguimiento para el error, haz lo siguiente:

  1. Verifica si la ejecución de una política provocó el error. Consulta Determinar la fuente del problema para obtener más detalles.
  2. Si el error ocurrió durante la ejecución de la política, continúa. Si el error lo causó el ve a Error en el servidor backend.
  3. Selecciona la solicitud a la API que presenta errores como 500 Internal Server Error en el seguimiento.
  4. Examina la solicitud y selecciona la política específica que falló o el flujo llamado “Error” inmediatamente después de la política con errores en el seguimiento.
  5. Para obtener más detalles sobre el error, revisa el “error” en Propiedades o el contenido del error.
  6. Usa los detalles que recopilaste sobre el error para determinar la causa.

Pasos de diagnóstico solo para los usuarios de la nube privada

Si no tienes la sesión de la IU de seguimiento, haz lo siguiente:

  1. Verifica que el error haya ocurrido durante la ejecución de una política. Consulta Determinar la fuente del problema para obtener más detalles.
  2. Si el error se debió a la ejecución de la política, continúa. Si el error ocurrió durante la etapa de políticas ejecución, continúa. Si el error lo causó el servidor de backend, consulta Error en el servidor de backend.
  3. Usa los registros de acceso de NGINX como se explica en Determina el origen del problema para determinar la política con errores en el proxy de API y, también, ID de mensaje de solicitud único
  4. Revisa los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) y busca la su ID de mensaje de solicitud único.
  5. Si encuentras el ID del mensaje de solicitud único, consulta si puedes obtener más información sobre el causa de la falla.

Solución

Si has determinado la causa del problema con la política, intenta corregirlo. Para ello, sigue estos pasos: corregir la política y volver a implementar el proxy.

Los siguientes ejemplos muestran cómo determinar la causa y la resolución de diferentes tipos de problemas.

Si necesitas más ayuda para solucionar el problema 500 Error interno del servidor o si sospechas que que hay un problema en Edge, comunícate con Apigee Asistencia.

Ejemplo 1: Falla en la política de Texto destacado del servicio debido a un error en el backend servidor

Si la llamada al servidor de backend falla dentro de la política de texto destacado de servicios con algún error, como como 4XX o 5XX, se considerará como 500 Error interno del servidor.

  1. Este es un ejemplo en el que el servicio de backend falla con un error 404 dentro del Política de textos destacados Se envía el siguiente mensaje de error al usuario final: 
    {
"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. La siguiente sesión de la IU de seguimiento muestra el código de estado 500 debido a un error en el servicio Política de textos destacados:

  3. En este ejemplo, el “error” indica el motivo de la política de Texto destacado del servicio falla como "ResponseCode 404 is attached as error". Este error puede ocurrir si el recurso al que se accede por medio de la URL del servidor backend en la política de Service Prompt no se disponibles.
  4. Comprueba la disponibilidad del recurso en el servidor de backend. Es posible que no esté disponible de forma temporal o permanente, o bien podría haberse trasladado a otra ubicación.

Ejemplo 1 de resolución

  1. Comprueba la disponibilidad del recurso en el servidor de backend. Es posible que no esté disponible de forma temporal o permanente, o bien podría haberse trasladado a otra ubicación.
  2. Corrige la URL del servidor de backend en la política de texto destacado del servicio para que apunte a una URL válida y existente. recurso.
  3. Si el recurso no está disponible temporalmente, intenta realizar la solicitud a la API una vez que recurso está disponible.

Ejemplo 2: Error en la política de extracción de variables

Veamos ahora otro ejemplo, en el que 500 Error interno del servidor se debe a un error de la política de Extract Variables y cómo solucionar el problema.

  1. El siguiente seguimiento en la sesión de la IU muestra el código de estado 500 debido a un error en Extract Política de variables:

  2. Selecciona la política de Extract Variables que falla, desplázate hacia abajo y observa el mensaje "Error Contenido” para obtener más información:

  3. El contenido del error indica que la variable "serviceCallout.oamCookieValidationResponse" no está disponible en con la política de Extract Variables. Como indica el nombre de la variable, debe contener el símbolo de la política de Llamada de Servicio anterior.
  4. Si seleccionas la política Service Prompt en el seguimiento, es posible que veas que "serviceCallout.oamCookieValidationResponse" variable no se estableció. Esta indica que la llamada al servicio de backend falló, lo que da como resultado una respuesta vacía de salida.
  5. A pesar de que la política de texto destacado de servicios haya fallado, la ejecución de las políticas después de La política de textos destacados continúa porque el error "continueOnError" marca de la política de texto destacado de servicios se haya establecido como verdadero, como se muestra a continuación:

    <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. Ten en cuenta el ID de mensaje único &quot;X-Apigee.Message-ID&quot; de esta API específica del seguimiento, como se muestra a continuación:
    1. Selecciona la opción "Datos de Analytics registrados". fase de la solicitud.
    2. Desplázate hacia abajo y anota el valor de X-Apigee.Message-ID.

  7. Ver el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/system.log) y busca la columna el ID del mensaje anotado en el paso 6. Se observó el siguiente mensaje de error para la API específica solicitud: 
    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

    El error anterior indica que la política de texto destacado de servicios falló debido a una conexión error de tiempo de espera durante la conexión al servidor backend.

  8. Para determinar la causa del error de tiempo de espera de conexión, se ejecutó la telnet al servidor de backend desde los procesadores de mensajes. Telnet el comando proporcionó el mensaje “Se agotó el tiempo de espera de la conexión” como se muestra a continuación: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    Por lo general, este error se observa en las siguientes circunstancias:

    • Cuando el servidor de backend no está configurado para permitir el tráfico desde el mensaje perimetral Procesadores.
    • Si el servidor de backend no está escuchando en el puerto específico.

    En el ejemplo anterior, si bien la política de extracción de variables falló, el porque Edge no pudo conectarse al servidor de backend en la solicitud de servicio política de la empresa. Y la causa de este error fue que el servidor final backend no se configuró para permitir el tráfico de los procesadores de mensajes de Edge.

    Tu propia política de extracción de variables se comportará de manera diferente y puede fallar con otras y por una buena razón. Puedes solucionar el problema de manera adecuada según la causa de la falla. tu política de Extract Variables revisando el mensaje en el campo error propiedad.

Resolución de ejemplo 2

  1. Corrige la causa del error o falla en la política de extracción de variables de manera adecuada.
  2. En el ejemplo ilustrado anterior, la solución fue rectificar la configuración de red para permitir el tráfico de los procesadores de mensajes de Edge a tu servidor de backend. Esto lo hizo incluir en la lista de entidades permitidas los procesadores Direcciones IP en el servidor de backend específico. Por ejemplo: en Linux, puedes usar iptables para permitir el tráfico desde Envía mensajes a las direcciones IP del procesador de mensajes en el servidor de backend.

Ejemplo 3: Error en la política JavaTexto destacado

Ahora veamos un ejemplo más, en el que 500 Error interno del servidor se debe a un error en la política de Texto destacado de Java y descubre cómo solucionar el problema.

  1. El siguiente seguimiento de la IU muestra el código de estado 500 debido a un error en la Política de texto destacado de Java:

  2. Selecciona el flujo llamado "Error" seguido de la política de texto destacado de Java con errores. para obtener los detalles del error, como se muestra en la siguiente figura:

  3. En este ejemplo, la propiedad "error" en la sección Properties revela que el error se debe a que se está usando una contraseña vencida durante la conexión a la base de datos de Oracle desde la política JavaCallout. Tu propio texto destacado de Java se comportará de manera diferente propagar un mensaje diferente en la propiedad error.
  4. Verifica el código de la política JavaTexto destacado y confirma la configuración correcta que se debe que se usan.

Resolución de ejemplo 3

Corrige el código de texto destacado de Java o la configuración de manera adecuada para evitar la excepción del entorno de ejecución. En En el ejemplo anterior de error de llamada de Java ilustrado, se debería usar la contraseña correcta para conectarse a la base de datos de Oracle y resolver el problema.

Error en el servidor backend

Un error interno del servidor 500 también podría originarse en el servidor backend. Esta sección se explica cómo solucionar el problema si el error proviene del servidor backend.

Diagnóstico

Pasos de diagnóstico para todos los usuarios

La causa de otros errores de backend puede variar mucho. Deberás diagnosticar cada situación de forma independiente.

  1. Verifica que el servidor de backend haya causado el error. Consulta Determinar la fuente del problema para obtener más detalles.
  2. Si el error lo causó el servidor de backend, continúa. Si el error ocurrió durante ejecución de políticas, ve a Error de ejecución en Edge Política.
  3. Sigue los pasos que se indican a continuación dependiendo de si tienes acceso o no a una sesión de Trace para la API con errores o si el backend es un servidor Node.js:

Si no tienes una sesión de seguimiento de la llamada a la API con errores, haz lo siguiente:

  1. Si el seguimiento de la IU no está disponible para la solicitud con errores, comprueba el servidor de backend para obtener detalles sobre el error.
  2. Si es posible, habilita el modo de depuración en el servidor de backend para obtener más detalles sobre el y la causa del error.

Si tienes una sesión de Trace para la llamada a la API con errores, haz lo siguiente:

Si tienes una sesión de Trace, los siguientes pasos te ayudarán a diagnosticar el problema.

  1. En la herramienta Trace, selecciona la solicitud a la API que falló con 500 Internal Server. Se produjo un error.
  2. En el servidor de destino, selecciona la fase "ResponseReceived from target server". a la API, como se muestra en la siguiente figura:

  3. Consulta la sección "Contenido de la respuesta" para obtener detalles sobre el error.

  4. En este ejemplo, el contenido de la respuesta que es un sobre SOAP muestra la cadena de error como Mensaje "Not Authorized" La causa más probable de esto es que no se pasan las credenciales adecuadas (nombre de usuario/contraseña, token de acceso, etc.) a el servidor de backend por el usuario. Para solucionar este problema, pasa las credenciales correctas a el servidor de backend.

Si el backend es un servidor Node.js:

  1. Si el backend es un servidor de backend de Node.js, verifica los registros de Node.js. para el proxy de API específico en la IU perimetral (tanto los usuarios de la nube pública como verificar los registros de Node.js). Si eres un usuario de la nube privada perimetral, puedes también puede consultar los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para obtener más información sobre el error.

    Opción Registros de NodeJS en la IU de Edge: Pestaña Overview del proxy de API

Solución

  1. Una vez que hayas identificado la causa del error, soluciona el problema en tu servidor de backend.
  2. Si es un servidor de backend de Node.js, haz lo siguiente:
    1. Verifica si se muestra el error desde tu código personalizado y, si es posible, corrige el problema.
    2. Si el error no aparece en tu código personalizado o si necesitas asistencia, comunícate con Asistencia de Apigee.

Si necesitas más ayuda para solucionar el problema 500 Error interno del servidor o si sospechas que que hay un problema en Edge, comunícate con Apigee Asistencia.

Determinación de la fuente del problema

Utiliza uno de los siguientes procedimientos para determinar si se produjo el error interno del servidor 500. durante la ejecución de una política en el proxy de API o en el servidor de backend.

Usa Trace en la IU

Nota: Los pasos de esta sección se pueden realizar tanto en Público como en Usuarios de la nube privada.

  1. Si el problema aún está activo, habilita el seguimiento en la IU de la API afectada.
  2. Una vez que hayas capturado el seguimiento, selecciona la solicitud a la API que muestra el código de respuesta como 500
  3. Navega por todas las fases de la solicitud a la API con errores y comprueba qué fase muestra el error 500 interno del servidor:
    1. Si el error aparece durante la ejecución de una política, continúa con Error de ejecución en una política perimetral.
    2. Si el servidor de backend respondió con 500 Internal Server, entonces continúe con Error en el servidor backend.

Usar API Monitoring

Nota: Solo los usuarios de la nube pública pueden realizar los pasos detallados en esta sección.

La supervisión de API te permite aislar las áreas problemáticas con rapidez para diagnosticar los problemas de errores, rendimiento y latencia, así como su origen. como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Lee una situación de ejemplo que demuestra cómo solucionar problemas 5xx con tus APIs con la supervisión de API. Por ejemplo, es posible que quieras configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 500 o fallas de steps.servicecallout.ExecutionFailed supere un umbral en particular.

Cómo usar el acceso NGINX Registros

Nota: Los pasos que se indican en esta sección son para los usuarios de la nube privada perimetral. solamente.

También puedes consultar los registros de acceso de NGINX para determinar si se arrojó el código de estado 500. durante la ejecución de una política en el proxy de API o en el servidor de backend. Este es especialmente útil si el problema ocurrió en el pasado o si es intermitente y que no puedan capturar el registro en la IU. Sigue estos pasos para determinar esta información a partir de Registros de acceso de NGINX:

  1. Verifica los registros de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. Busca si hay errores 500 para el proxy de API específico en el y el tiempo de actividad.
  3. Si hay errores del tipo 500, verifica si el error es de política o de servidor de destino. como se muestra a continuación:

    Entrada de ejemplo en la que se muestra un error de política

    Entrada de ejemplo en la que se muestra un error del servidor de destino

  4. Cuando hayas identificado si se trata de un error de política o del servidor de destino, haz lo siguiente:
    1. Continúa con Error de ejecución en una política perimetral si es un error de política.
    2. Continúa con Error en el servidor backend si es un destino. error de servidor.