500 Internal Server Error

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

Videos

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

Video Descripción
Introducción Proporciona una introducción a 500 errores internos del servidor y las posibles causas. También muestra un error interno del servidor 500 en tiempo real junto con los pasos para solucionarlo.
Soluciona errores de solicitudes de servicio y extracción de variables Se muestran dos 500 errores internos del servidor causados por las políticas Service Highlights y Extract Variable, además de cómo solucionar y resolver estos errores.
Soluciona errores de las políticas de JavaScript Muestra un error interno del servidor 500 debido a una política de JavaScript y los pasos para solucionar este error.
Controla las fallas de los servidores de backend Se muestran ejemplos 500 de errores internos del servidor causados por una falla en el servidor de backend y 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 error 500 Internal Server puede deberse a un error durante la ejecución de cualquier política dentro de Edge o a 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ó 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

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. A continuación, se muestra un ejemplo de 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 por diversas causas. En Edge, las causas se pueden clasificar en dos categorías principales según dónde ocurrió el error:

Causa Detalles Se indican los pasos detallados para la solución de problemas.
Error de ejecución en una política perimetral Una Policy dentro del proxy de API puede fallar por algún motivo. Usuarios de la nube pública y privada de Edge
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

Error de ejecución en una política perimetral

Una Policy dentro del proxy de API puede fallar por algún motivo. En esta sección, se explica cómo solucionar el problema si el error 500 interno del servidor 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 que la causa del error sea la ejecución de una política. Consulta Determina el origen del problema para obtener más detalles.
  2. Si el error se produjo durante la ejecución de la política, continúa. Si el servidor de backend causó el error, ve a Error en el servidor de backend.
  3. Selecciona la solicitud a la API que falla con el error 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” que sigue inmediatamente a la política con errores en el seguimiento.
  5. Para obtener más detalles sobre el error, revisa el campo "error" en la sección Propiedades o el contenido del error.
  6. Usa los detalles que recopilaste sobre el error para tratar de determinar la causa.

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

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

  1. Verifica que el error se haya producido durante la ejecución de una política. Consulta Determina el origen del problema para obtener más detalles.
  2. Si la ejecución de la política causó el error, continúa. Si el error ocurrió durante la ejecución de la política, continúa. Si el servidor de backend causó el error, ve a 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 la API y también el ID del mensaje de solicitud único.
  4. Verifica los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) y busca el ID del mensaje de solicitud único en ellos.
  5. Si encuentras el ID del mensaje de solicitud único, consulta si puedes obtener más información sobre la causa de la falla.

Resolución

Si determinaste la causa del problema con la política, intenta corregirlo corrigiendo la política y volviendo a implementar el proxy.

En los siguientes ejemplos, se muestra cómo determinar la causa y la resolución de diferentes tipos de problemas.

Si necesitas más ayuda para solucionar problemas del error interno del servidor 500 o sospechas que es un problema de Edge, comunícate con el equipo de asistencia de Apigee.

Ejemplo 1: Falla en la política de Service Highlights debido a un error en el servidor de backend

Si la llamada al servidor de backend falla dentro de la política Service Featured con algún error, como 4XX o 5XX, se considerará como 500 Internal Server Error.

  1. A continuación, se muestra un ejemplo en el que el servicio de backend falla con un error 404 en la política de texto destacado del servicio. 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. En la siguiente sesión de la IU de seguimiento, se muestra el código de estado 500 debido a un error en la política Service Highlights:

  3. En este ejemplo, la propiedad “error” indica el motivo del error en la política de texto destacado de servicio, ya que "ResponseCode 404 se trata como error". Este error puede ocurrir si el recurso al que se accede a través de la URL del servidor de backend en la política Service Highlight no está disponible.
  4. Verifica la disponibilidad del recurso en el servidor de backend. Es posible que no esté disponible de forma temporal o permanente, o bien que se haya trasladado a otra ubicación.

Resolución de ejemplo 1

  1. Verifica la disponibilidad del recurso en el servidor de backend. Es posible que no esté disponible de forma temporal o permanente, o bien que se haya trasladado a otra ubicación.
  2. Corrige la URL del servidor de backend en la política Service Referencia para que apunte a un recurso válido y existente.
  3. Si el recurso no está disponible temporalmente, intenta realizar la solicitud a la API una vez que lo esté.

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

Ahora veamos otro ejemplo, en el que 500 Internal Server Error se produce debido a un error en la política de extracción de variables y veremos 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 la política de extracción de variables:

  2. Selecciona la política de extracción de variables que falla, desplázate hacia abajo y consulta la sección “Contenido del error” para obtener más detalles:

  3. El contenido de error indica que la variable "servicePrompt.oamCookieValidationResponse" no está disponible en la política Extraer variables. Como el nombre de la variable lo indica, debe contener la respuesta de la política Service Prompt anterior.
  4. Selecciona la política Service Prompt en el seguimiento. Es posible que notes que no se configuró la variable "serviceCallout.oamCookieValidationResponse". Esto indica que la llamada al servicio de backend falló, lo que generó una variable de respuesta vacía.
  5. Si bien la política de texto destacado de servicio falló, la ejecución de las políticas después de la política de solicitud de servicio continúa porque la marca "continueOnError" en la política de texto destacado de servicio está configurada como verdadera, 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. Toma nota del ID del mensaje único “X-Apigee.Message-ID” para esta solicitud a la API específica del seguimiento, como se muestra a continuación:
    1. Selecciona la fase "Datos de Analytics registrados" en la solicitud.
    2. Desplácese hacia abajo y anote el valor de X-Apigee.Message-ID.

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

    El error anterior indica que no se pudo aplicar la política Service Highlights debido a un error de tiempo de espera de conexión mientras se establecía la conexión con el servidor de backend.

  8. Para determinar la causa del error de tiempo de espera de la conexión, ejecuta el comando telnet en el servidor de backend desde el procesador de mensajes. El comando telnet mostró el error “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 de los procesadores de mensajes perimetrales.
    • Si el servidor de backend no escucha en el puerto específico.

    En el ejemplo ilustrado anterior, a pesar de que la política de extracción de variables falló, la causa real fue que Edge no pudo conectarse al servidor de backend en la política de solicitud de servicio. La causa de este error fue que el servidor final de backend no estaba configurado para permitir el tráfico de los procesadores de mensajes perimetrales.

    Tu propia política de extracción de variables se comportará de manera diferente y es posible que falle por otro motivo. Puedes solucionar el problema de forma adecuada según la causa de falla de la política de extracción de variables si verificas el mensaje en la propiedad error.

Resolución de ejemplo 2

  1. Corrige la causa del error o la falla en la política Extrae variables de forma adecuada.
  2. En el ejemplo ilustrado anterior, la solución era rectificar la configuración de red para permitir el tráfico de Edge Message Processor a tu servidor de backend. Para ello, incluyó las direcciones IP de Message Processors en la lista de entidades permitidas del servidor de backend específico. Por ejemplo, en Linux, puedes usar iptables para permitir el tráfico de las direcciones IP de Message Processor en el servidor de backend.

Ejemplo 3: Error en la política JavaHighlight

Veamos ahora un ejemplo más, en el que 500 Internal Server Error se produce debido a un error en la política Java Highlight y se explica 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 denominado "Error" seguido de la política de textos destacados 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 muestra que el error se debe a que se usó una contraseña vencida mientras se conectaba a la base de datos de Oracle desde la política JavaFeatured. Tu propio texto destacado de Java se comportará de manera diferente y se propagará con un mensaje distinto en la propiedad error.
  4. Verifica el código de la política JavaHighlight y confirma la configuración correcta que debe usarse.

Resolución de ejemplo 3

Corrige el código de llamada o la configuración de Java de forma adecuada para evitar la excepción del entorno de ejecución. En el ejemplo anterior de falla de texto destacado 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 de backend

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

Diagnóstico

Pasos de diagnóstico para todos los usuarios

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

  1. Verifica que el servidor de backend haya causado el error. Consulta Determina el origen del problema para obtener más detalles.
  2. Si el servidor de backend causó el error, continúa. Si el error ocurrió durante la ejecución de la política, ve a Error de ejecución en la política perimetral.
  3. Sigue los pasos que se indican a continuación en función de si tienes o no acceso 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 Trace para la llamada a la API que falló, haz lo siguiente:

  1. Si el seguimiento de la IU no está disponible para la solicitud que falla, verifica los registros del servidor de backend a fin de 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 error y la causa.

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

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

  1. En la herramienta de seguimiento, selecciona la solicitud a la API que falló con el error 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:

  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 de SOAP muestra la string con errores como mensaje "Not Authorized" (No autorizado). La causa más probable de este problema es que el usuario no pase las credenciales adecuadas (nombre de usuario/contraseña, token de acceso, etc.) al servidor de backend. Para solucionar este problema, pasa las credenciales correctas al 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 de Edge (los usuarios de la nube pública y privada pueden verificar los registros de Node.js). Si eres usuario de la nube privada de Edge, también puedes consultar los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para obtener más detalles sobre el error.

    Opción Registros de NodeJS en la IU de Edge: pestaña Descripción general del proxy de API

Solución

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

Si necesitas más ayuda para solucionar problemas del error interno del servidor 500 o sospechas que es un problema de Edge, comunícate con el equipo de asistencia de Apigee.

Determina el origen del problema

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

Cómo usar Trace en la IU

Nota: Los usuarios de la nube pública y de la nube privada pueden realizar los pasos de esta sección.

  1. Si el problema sigue activo, habilita el seguimiento en la IU de la API afectada.
  2. Una vez que hayas capturado el registro, selecciona la solicitud a la API que muestre el código de respuesta como 500.
  3. Navega por todas las fases de la solicitud a la API con errores y verifica qué fase muestra el error interno del servidor 500:
    1. Si se produce el error durante la ejecución de una política, procede con Error de ejecución en una política perimetral.
    2. Si el servidor de backend respondió con el servidor interno 500, procede a la sección Error en el servidor de backend.

Usa la supervisión de API

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

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

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

Usa registros de acceso de NGINX

Nota: Los pasos de esta sección son solo para usuarios de la nube privada perimetral.

También puedes consultar los registros de NGINX Access para determinar si el código de estado 500 se arrojó durante la ejecución de una política dentro del proxy de la API o del servidor de backend. Esto es muy útil si el problema ocurrió en el pasado o si es intermitente y no puedes capturar el registro en la IU. Sigue estos pasos para determinar esta información a partir de los 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 la duración específica.
  3. Si hay errores 500, verifica si se trata de un error de política o de servidor de destino, como se muestra a continuación:

    Entrada de ejemplo que muestra un error de política

    Entrada de ejemplo que muestra un error del servidor de destino

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