Error interno del servidor: Servidor de backend

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Videos

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

Síntoma

La aplicación cliente obtiene un código de estado HTTP 500 con el mensaje Internal Server Error como respuesta para 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ó cumplir con la solicitud. Por lo general, el servidor devuelve este error cuando no es adecuado ningún otro código de error.

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 observes un mensaje de error similar al que se muestra a continuación:

Ejemplo 1

Respuesta del servidor de backend de muestra 1

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

Ejemplo 2

Respuesta del servidor de backend de muestra 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 500 Internal Server Error puede ser devuelto por el servidor de backend debido a un número de causas. En este manual, se explica cómo solucionar problemas con 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 1: Uso de la supervisión de API

Para diagnosticar el error con la supervisión de API, haz lo siguiente:

  1. Accede a la IU de Apigee Edge como usuario con una función adecuada.

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

  3. Navega a la página Analizar > Supervisión de API > Investigar.
  4. Selecciona el período específico en el que observaste los errores.

  5. Traza el Código de falla en función del Tiempo.

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

    ( aumentar el tamaño de la imagen)

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

    ( aumentar el tamaño de la imagen)

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

    ( aumentar el tamaño de la imagen)

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

Trace

Procedimiento 2: Uso de la herramienta Trace

Para diagnosticar el error con la herramienta Trace, haz lo siguiente:

  1. Habilita la sesión de Trace y haz lo siguiente:
    • Espera a que se produzca 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 reproducir el problema 500 Internal Server Error

  2. Asegúrate de que Mostrar todos los FlowInfos esté habilitado:

  3. Selecciona una de las solicitudes fallidas y examina el seguimiento.
  4. Navega por las diferentes fases del seguimiento y ubica dónde se produjo 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:

    ( aumentar el tamaño de la imagen)

  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 detalles de 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:

    ( aumentar el tamaño de la imagen)

  8. Anota 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 3: Uso de los registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, haz lo siguiente:

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

  2. Consulta 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 aún hay solicitudes que fallan con 500.

  4. Si encuentras errores 500 con el X-Apigee-fault-code que coincida con el valor de messaging.adaptors.http.flow.ErrorResponseCode, entonces determina el valor de X-Apigee-fault-source.

    Ejemplo de error 500 del registro de acceso de NGINX:

    ( aumentar el tamaño de la imagen)

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

    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

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

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

    Trace

    Usa Trace:

    Si tienes una sesión de Trace para la falla, 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:

      ( aumentar el tamaño de la imagen)

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

      Contenido de respuesta de muestra:

      <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, por lo tanto, reciba este error.

    Llama al servidor de backend

    Realiza una llamada directa al servidor de backend:

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

    • Valida si obtienes la misma 500 Internal Server Error respuesta 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, los parámetros de consulta y las credenciales necesarios que se deben pasar al servidor de backend como parte de la solicitud.
    2. Si se puede acceder al servicio de backend de forma pública, puedes usar el curl comando, Postman o cualquier otro cliente de REST y, luego, invocar la API del servidor de backend directamente.

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

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

    Registros del servidor de backend

    Usa los registros del servidor de backend

    1. Revisa los registros del servidor de backend y trata de 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 usas el encadenamiento de proxy en el extremo de destino específico del proxy de API fallido; es decir, si el servidor de destino o el extremo de destino invoca otro proxy en Apigee Edge. Para determinar esto, haz lo siguiente:

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

    2. Se abrirá la ventana Curl para la solicitud enviada al servidor de destino , desde la que puedes determinar el alias de host del servidor de destino.
    3. Revisa el extremo de destino de tu 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 de host del servidor de destino apunta a un alias de host virtual, entonces se trata de encadenamiento de proxy. En este caso, debes repetir todos los pasos anteriores para el proxy encadenado hasta que determines qué causa realmente el 500 Internal Server Error. En estos casos, 500 Internal Server Error también puede ocurrir en otros proxies encadenados en otras etapas, que se pueden diagnosticar y resolver con las instrucciones que se indican en este manual o en el manual de 500 Internal Server Error.
    5. Si el alias de host del servidor de destino apunta a tu servidor de backend, ve a Solución.

Solución

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

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

Consideraciones clave

  1. El mensaje de error real que devuelve el servidor de backend para 500 Internal Server Error solo se puede ver si capturaste la sesión de seguimiento de las solicitudes fallidas.
  2. La respuesta del servidor de backend no se registrará en la supervisión de API, los registros de acceso de NGINX ni Message Processor logs por motivos de seguridad.
  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 el 500 Internal Server Error o ver el mensaje de error que devuelve 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 Asistencia de Apigee Edge.

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

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

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

  • Mensaje de error completo observado para las solicitudes fallidas
  • Organización, nombre del entorno y nombre del proxy de API para los que observas 500 errores
  • 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

    Donde: ORG, ENV y PORT# se reemplazan por valores reales.

  • Registros del sistema de Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log
  • El período con la información de la zona horaria cuando ocurrieron los errores 500.