500, Internal Server Error

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

Videos

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

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 error interno del servidor 500 puede deberse a un error durante la ejecución de cualquier política en Edge o a un error en el servidor de destino o de 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ó 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

Es posible que recibas el siguiente mensaje de error:

HTTP/1.1 500 Internal Server Error

En algunos casos, es posible que observes otro mensaje de error que tenga más detalles. Este es un mensaje de error de ejemplo:

{
   "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 puede generarse debido a varias causas diferentes. En Edge, las causas se pueden clasificar en dos categorías principales según dónde ocurrió el error:

Error de ejecución en una política de Edge

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

Diagnóstico

Pasos de diagnóstico para usuarios de la nube pública y privada

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

1. Verifica que el error se haya causado por la ejecución de una política. Consulta Cómo determinar el origen del problema para obtener detalles.
2. Si el error ocurrió durante la ejecución de la política, continúa. Si el error fue causado por el servidor de backend, ve a Error en el servidor de backend.
3. Selecciona la solicitud a la API que falla con el error interno del servidor 500 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, consulta el campo "error" en la sección Propiedades o el contenido del error.
6. Con los detalles que recopilaste sobre el error, intenta determinar su causa.

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

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

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

Solución

Si determinaste la causa del problema con la política, intenta corregirlo arreglando 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 el error interno del servidor 500 o sospechas que es un problema en Edge, comunícate con el equipo de asistencia de Apigee.

Ejemplo 1: Falla en la política de texto destacado de servicios 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 4XX o 5XX, se tratará como un error interno del servidor 500.

1. Este es un ejemplo en el que el servicio de backend falla con un error 404 dentro de la política de texto destacado de servicios. 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 Trace muestra el código de estado 500 causado por un error en la política de texto destacado de servicios:

   

3. En este ejemplo, la propiedad "error" muestra el motivo de la falla de la política de texto destacado de servicios como "ResponseCode 404 is treated as 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 de texto destacado de servicios 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 que se haya movido a otra ubicación.

Solución del 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 que se haya movido a otra ubicación.
2. Corrige la URL del servidor de backend en la política de texto destacado de servicios para que apunte a un recurso válido y existente.
3. Si el recurso solo no está disponible de forma temporal, intenta realizar la solicitud a la API una vez que el recurso esté disponible.

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

Ahora, veamos otro ejemplo en el que el error interno del servidor 500 se produce debido a un error en la política de extracción de variables y veamos 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 con errores, desplázate hacia abajo y consulta la sección "Error Content" para obtener más detalles:
   
   
3. El contenido del error indica que la variable"serviceCallout.oamCookieValidationResponse" no está disponible en la política de extracción de variables. Como indica el nombre de la variable, debe contener la respuesta de la política de texto destacado de servicios anterior.
4. Selecciona la política de texto destacado de servicios en el seguimiento y es posible que descubras que no se configuró la variable "serviceCallout.oamCookieValidationResponse". Esto indica que falló la llamada al servicio de backend, lo que generó una variable de respuesta vacía.
5. Aunque falló la política de texto destacado de servicios, la ejecución de las políticas después de la política de texto destacado de servicios continúa porque la marca "continueOnError" en la política de texto destacado de servicios se establece en true, 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 "X-Apigee.Message-ID" para esta solicitud a la API específica del seguimiento, de la siguiente manera:
   1. Selecciona la fase "Analytics Data Recorded" de la solicitud.
   2. Desplázate hacia abajo y anota el valor de X-Apigee.Message-ID.

   

7. Consulta el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/system.log) y busca el ID de mensaje único que se anotó en el paso 6. Se observó el siguiente mensaje de error para la solicitud a la API específica:

   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 falló la política de texto destacado de servicios debido a un error de tiempo de espera de conexión mientras se conectaba al servidor de backend.

8. Para determinar la causa del error de tiempo de espera de conexión, ejecuta el telnet comando en el servidor de backend desde los Message Processors. El comando telnet mostró el error "Connection timed out", 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 Message Processors de Edge.
   • Si el servidor de backend no está escuchando en el puerto específico.

   En el ejemplo ilustrado anterior, aunque falló la política de extracción de variables, la causa real fue que Edge no pudo conectarse al servidor de backend en la política de texto destacado de servicios. Y la causa de esta falla fue que el servidor de backend no estaba configurado para permitir el tráfico de los Message Processors de Edge.

   Tu propia política de extracción de variables se comportará de manera diferente y puede fallar por un motivo diferente. Puedes solucionar el problema de forma adecuada según la causa de la falla de tu política de extracción de variables. Para ello, consulta el mensaje en la propiedad error .

Solución del ejemplo 2

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

Ejemplo 3: Falla en la política de JavaCallout

Ahora, veamos un ejemplo más en el que el error interno del servidor 500 se produce debido a un error en la política de JavaCallout y veamos 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 JavaCallout:

   

2. Selecciona el flujo llamado "Error" seguido de la política de JavaCallout 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 Propiedades revela que la falla se debe a que se usó una contraseña vencida mientras se conectaba a la base de datos de Oracle desde la política de JavaCallout. Tu propia llamada de código Java se comportará de manera diferente y propagará un mensaje diferente en la propiedad error.
4. Consulta el código de la política de JavaCallout y confirma la configuración correcta que se debe usar.

Solución del ejemplo 3

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

Error en el servidor de backend

Un error interno del servidor 500 también puede 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 mucho. Deberás diagnosticar cada situación de forma independiente.

1. Verifica que el error se haya causado por el servidor de backend. Consulta Cómo determinar el origen del problema para obtener detalles.
2. Si el error fue causado por el servidor de backend, continúa. Si el error ocurrió durante la ejecución de la política, ve a Error de ejecución en una política de Edge.
3. Sigue los pasos que se indican a continuación según si tienes 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 con errores:

1. Si el seguimiento de la IU no está disponible para la solicitud con errores, consulta los registros del 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 error y la causa.

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

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

1. En la herramienta de Trace, selecciona la solicitud a la API que falló con el error interno del servidor 500 Error.
2. Selecciona la fase "Response received from target server" de la solicitud a la API con errores como se muestra en la siguiente figura:

   

3. Consulta la sección "Response Content" 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 "Not Authorized" mensaje. La causa más probable de este problema es que el usuario no pasa las credenciales adecuadas (nombre de usuario o contraseña, token de acceso, etcétera) 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, consulta 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 consultar los registros de Node.js). Si eres un usuario de la nube privada de Edge, también puedes consultar los registros del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para obtener más detalles sobre el error.
   
   

   Opción de 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, corrige el problema en tu servidor de backend.
2. Si es un servidor de backend de Node.js, haz lo siguiente:
   1. Comprueba si el error se genera desde tu código personalizado y corrige el problema, si es posible.
   2. Si el error no se genera 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 el error interno del servidor 500 o sospechas que es un problema en Edge, comunícate con el equipo de asistencia de Apigee.

Cómo determinar el origen del problema

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

Usa Trace en la IU

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

1. Si el problema aún está activo, habilita el seguimiento en la IU para 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 verifica qué fase muestra el error interno del servidor 500:
   1. Si el error se genera durante la ejecución de una política, continúa con Error de ejecución en una política de Edge.
   2. Si el servidor de backend respondió con el error interno del servidor 500, continúa con Error en el servidor de backend.

Usa la supervisión de API

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

La supervisión de API te permite aislar las áreas con problemas rápidamente para diagnosticar problemas de errores, rendimiento y latencia, y su fuente, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Sigue un ejemplo que muestra cómo solucionar problemas 5xx con tus APIs mediante la supervisión de API. Por ejemplo, es posible que desees configurar una alerta para que se te notifique cuando la cantidad de códigos de estado 500 o fallas de steps.servicecallout.ExecutionFailed supere un umbral determinado.

Usa los registros de acceso de NGINX

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

También puedes consultar los registros de acceso de NGINX para determinar si el código de estado 500 se generó durante la ejecución de una política dentro del proxy de API o por el servidor de backend. Esto es particularmente útil si el problema ocurrió en el pasado o si el problema es intermitente y no puedes capturar el seguimiento en la IU. Sigue los siguientes pasos para determinar esta información de los registros de acceso de NGINX:

1. Consulta los registros de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
2. Busca si hay algún error 500 para el proxy de API específico durante la duración específica.
3. Si hay algún error 500, verifica si el error es una política o un error del servidor de destino, como se muestra a continuación:

   Entrada de muestra que muestra un error de política

   

   Entrada de muestra que muestra un error del servidor de destino

   

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