Error interno del servidor: Servidor de backend

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Videos

Video Descripción
Error interno del servidor 500 - provocado por el backend Muestra un 500 Internal Server Error en tiempo real causado por el servidor de backend junto con los pasos para solucionar y resolver el error.

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 500 con el mensaje Internal Server Error como respuesta a las llamadas a la API.

El código de estado HTTP 500 es una respuesta de error genérica. Significa que el servidor encontró una condición inesperada que le impidió completar la solicitud. Por lo general, el servidor muestra este error cuando ningún otro código de error es adecuado.

Mensajes de error

La aplicación cliente obtiene el siguiente código de respuesta: 

HTTP/1.1 500 Internal Server Error

Además, es posible que veas un mensaje de error similar al que se muestra a continuación:

Ejemplo 1

Ejemplo de respuesta del servidor de backend n.o 1

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

Muestra n.o 2

Ejemplo de respuesta del servidor de backend n° 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>

Causas posibles

El servidor de backend podría mostrar 500 Internal Server Error debido a varias causas. En esta guía, se explica cómo solucionar el problema mediante pasos comunes y resolver este error, independientemente de su causa.

Las posibles causas de este problema son las siguientes:

Causa Descripción Instrucciones de solución de problemas aplicables para
Error en el servidor de backend El servidor de backend puede fallar por algún motivo. Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

Usa una de las siguientes herramientas o técnicas para diagnosticar este error:

Supervisión de API

Procedimiento n.o 1: Usar la supervisión de APIs

Para diagnosticar el error con la supervisión de la API, sigue estos pasos:

  1. Accede a la IU de Apigee Edge como un usuario con el rol adecuado.

  2. Cambia a la organización en la que quieres investigar el problema.

  3. Navega a la página Analyze > API Monitoring > Investigate.
  4. Selecciona el período específico en el que observaste los errores.

  5. Traza el código de falla en función del valor Time.

  6. Selecciona una celda que tenga el código de falla messaging.adaptors.http.flow.ErrorResponseCode, como se muestra a continuación:

    ( ver imagen más grande)

  7. Se muestra información sobre el código de falla messaging.adaptors.http.flow.ErrorResponseCode como se muestra a continuación:

    ( ver imagen más grande)

  8. Haz clic en Ver registros y expande la fila de la solicitud fallida.

    ( ver imagen más grande)

  9. En la ventana Registros, ten en cuenta los siguientes detalles:
    • ID de mensaje de solicitud
    • Código de estado: 500
    • Fuente de la falla: target
    • Código de falla: messaging.adaptors.http.flow.ErrorResponseCode

Trace

Procedimiento n.o 2: Usa la herramienta de seguimiento

Para diagnosticar el error con la herramienta Trace, sigue estos pasos:

  1. Habilita la sesión de seguimiento y realiza una de estas acciones:
    • Espera a que aparezca el error 500 Internal Server Error con el código de error messaging.adaptors.http.flow.ErrorResponseCode.
    • Si puedes reproducir el problema, realiza la llamada a la API para reproducirlo 500 Internal Server Error

  2. Asegúrate de que la opción Show all FlowInfos esté habilitada:

  3. Selecciona una de las solicitudes con errores y examina el seguimiento.
  4. Navega por las diferentes fases del seguimiento y localiza dónde ocurrió la falla.

  5. Por lo general, encontrarás el error en un flujo después de la fase Respuesta recibida del servidor de destino, como se muestra a continuación:

    ( ver imagen más grande)

  6. Navega a la fase AX (datos de Analytics registrados) en el seguimiento y haz clic en ella.

  7. Desplázate hacia abajo hasta la sección Encabezados de respuesta de los detalles de la fase y determina los valores de X-Apigee-fault-code y X-Apigee-fault-source, y X-Apigee-Message-ID como se muestra a continuación:

    ( ver imagen más grande)

  8. Ten en cuenta los valores de X-Apigee-fault-code, X-Apigee-fault-source y X-Apigee-Message-ID:
    9. Encabezados de respuesta Valor
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Procedimiento n.o 3: Usa los registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, sigue estos pasos:

  1. Si eres un usuario de la nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave de 500 Internal Server Error de HTTP.

  2. Verifica los registros de acceso de NGINX:

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

  3. Busca para ver si hay errores 500 con el código de error messaging.adaptors.http.flow.ErrorResponseCode durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con 500.

  4. Si encuentras algún error 500 en el que X-Apigee-fault-code coincida con el valor deX-Apigee-fault-code , determina el valor de X-Apigee-fault-code

    Ejemplo de error 500 del registro de acceso de NGINX:

    ( ver imagen más grande)

    La entrada de ejemplo anterior del registro de acceso de NGINX tiene los siguientes valores para X-Apigee-fault-code y X-Apigee-fault-code

    Encabezados Valor
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Causa: error en el servidor de backend

Diagnóstico

La 500 Internal Server Error que respondió el servidor de backend puede deberse a varios motivos. Deberás diagnosticar cada situación de forma independiente.

  1. Determina el código y la fuente de fallas del error observado con la supervisión de la API, la herramienta de Trace o los registros de acceso de NGINX, como se explica en Pasos comunes de diagnóstico.
  2. Si la Fuente de errores es target y el Código de fallas es messaging.adaptors.http.flow.ErrorResponseCode, eso indica que el servidor de backend muestra el error.
  3. Puedes realizar uno de los siguientes pasos para diagnosticar la causa del problema:

    Trace

    Con Trace:

    Si tienes una sesión de Trace para el error, sigue estos pasos:

    1. En Trace, selecciona la solicitud a la API que falló con 500 Internal Server Error.

    2. Selecciona la fase Respuesta recibida del servidor de destino de la solicitud a la API fallida, como se muestra en la siguiente figura:

      ( ver imagen más grande)

    3. Desplázate hacia abajo hasta la sección Detalles de la fase y verifica el Contenido de la respuesta,que contiene la respuesta del servidor de backend.

      Ejemplo de contenido de la respuesta:

      <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>

      En la respuesta anterior, ten en cuenta que el mensaje de error del servidor de backend es No autorizado. Esto indica que es posible que el usuario haya pasado credenciales no válidas y que es por eso que recibe este error.

    Llamar al servidor de backend

    Realizando llamadas directas al servidor de backend:

    Puedes realizar una llamada directa al servidor de backend y hacer lo siguiente:

    • Valida si obtienes la misma respuesta 500 Internal Server Error que la que recibiste cuando se realizó la solicitud a través de Apigee Edge.
    • Verifica el mensaje de error (respuesta) recibido del servidor de backend

    Realiza los siguientes pasos para realizar la llamada directa al servidor de backend:

    1. Asegúrate de tener todos los encabezados, parámetros de consulta y credenciales que se deben pasar al servidor de backend como parte de la solicitud.
    2. Si el servicio de backend es de acceso público, puedes usar el comando curl, Postman o cualquier otro cliente de REST y, luego, invocar directamente la API del servidor de backend.

    3. Si solo se puede acceder al servidor de backend desde Message Processor, puedes usar el comando curl, Postman o cualquier otro cliente de REST y, luego, invocar la API del servidor de backend directamente desde Message Processor.

    4. Valida si el servicio de backend realmente muestra 500 Internal Server Error y verifica el mensaje de error (respuesta) que muestra el servidor de backend y determina la causa de este error.

    Registros del servidor de backend

    Usa registros del servidor de backend

    1. Revisa los registros del servidor de backend y, luego, intenta obtener más detalles sobre el error y su causa.
    2. Si es posible, habilita el modo de depuración en el servidor de backend para obtener más detalles sobre el error y la causa.

  4. Verifica si estás usando encadenamiento de proxy en el extremo de destino específico del proxy de API que falla; es decir, si el servidor o extremo de destino está invocando otro proxy en Apigee Edge. Para determinarlo, sigue estos pasos:

    1. Si tienes el seguimiento de la solicitud que falla, navega a la fase Solicitud enviada al servidor de destino y haz clic en Show Curl.

    2. Se abrirá la ventana Curl for Request Sent to Target Server, desde la cual puedes determinar el alias del host del servidor de destino.
    3. Revisa el extremo de destino del proxy de API y verifica si la URL del servidor de backend o el nombre de host en el servidor de destino apunta a otro proxy o a tu propio servidor de backend.
    4. Si el alias del host del servidor de destino apunta a un alias de host virtual, es un encadenamiento de proxy. En este caso, debes repetir todos los pasos anteriores para el proxy en cadena hasta determinar qué está causando el 500 Internal Server Error. En estos casos, 500 Internal Server Error puede ocurrir en otros proxies en cadena en otras etapas, lo que se puede diagnosticar y resolver con las instrucciones que se proporcionan en esta guía o en la guía 500 Internal Server Error.
    5. Si el alias del host del servidor de destino apunta a tu servidor de backend, ve a Resolución.

Resolución

Si se determina que el error 500 proviene del servidor de backend, trabaja con el equipo del servidor de backend para solucionar el problema de manera adecuada.

En el ejemplo anterior, es posible que debas solicitar a los usuarios que pasen credenciales válidas para solucionar este problema.

Puntos clave para tener en cuenta

  1. El mensaje de error real que muestra el servidor de backend para 500 Internal Server Error solo se puede ver si capturaste la sesión de seguimiento para las solicitudes con errores.
  2. Por motivos de seguridad, la respuesta del servidor de backend no se registrará en la supervisión de la API, en los registros de acceso de NGINX ni en los registros del procesador de mensajes.
  3. Puedes revisar los registros del servidor de backend o habilitar el modo de depuración en el backend para obtener más detalles sobre 500 Internal Server Error o ver el mensaje de error que muestra el servidor de backend.

Se debe recopilar información de diagnóstico

Si el problema persiste, incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y comunícate con el equipo de asistencia de Apigee Edge.

Si eres un usuario de la nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre del proxy de API
  • Completa el comando curl para reproducir el error 500
  • Archivo de seguimiento que contiene las solicitudes con 500 Internal Server Error
  • Si los errores 500 no se producen actualmente, proporciona el período con la información de la zona horaria cuando se produjeron errores 500 en el pasado.

Si eres un usuario de la nube privada, proporciona la siguiente información:

  • Mensaje de error completo observado para las solicitudes con errores
  • Organización, nombre del entorno y nombre del proxy de la API para los que observas errores 500
  • Paquete de proxy de API
  • Archivo de seguimiento que contiene las solicitudes con 500 Internal Server Error
  • Registros de acceso de NGINX/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Dónde: Se reemplazan ORG, ENV y PORT# por valores reales.

  • Registros del sistema del procesador de mensajes /opt/apigee/var/log/edge-message-processor/logs/system.log
  • El período con la información de la zona horaria en el que se produjeron los errores 500.