503 Service Unavailable

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 los errores 503:

Video Descripción
Soluciona problemas y resuelve el error 503 Service Unavailable debido a un problema de DNS Obtén más información sobre lo siguiente:
  • Error 503 Servicio no disponible causado por problemas relacionados con la resolución de DNS y la red en Apigee Edge
  • Solución de problemas y resolución de un error de servicio no disponible 503 en tiempo real causado por un problema de resolución de DNS
Cómo solucionar el error 503 Servicio no disponible debido a un problema de red Solución de problemas y resolución de un error 503 de servicio no disponible en tiempo real causado por un problema de red en Apigee Edge

Síntoma

La aplicación cliente recibe un estado de respuesta HTTP 503 con el mensaje Servicio no disponible después de una llamada al proxy de API.

Mensajes de error

Puedes ver el siguiente mensaje de error:

HTTP/1.1 503 Service Unavailable

También puedes ver el siguiente mensaje de error en la respuesta HTTP:

Servicio no disponible

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

Causas posibles

La respuesta HTTP 503 Service Unavailable con el código de error messaging.adaptors.http.flow.ServiceUnavailable se produce si el Message Processor de Apigee Edge experimenta errores debido a un tiempo de espera de conexión, un nombre de host incorrecto o fallas en el protocolo de enlace SSL mientras se comunica con el servidor de backend.

Las posibles causas de la respuesta 503 Service Unavailable son las siguientes:

Causa Descripción Quién puede realizar los pasos para solucionar problemas
Errores de conexión debido a una resolución de DNS incorrecta La resolución de DNS del servidor de destino dio como resultado direcciones IP incorrectas que generan errores de conexión. Usuarios de la nube privada de Edge
Errores de conexión Los problemas de red o conectividad impiden que el cliente se conecte al servidor. Usuarios de la nube privada de Edge
Nombre de host del servidor de destino incorrecto El host del servidor de destino especificado es incorrecto o tiene caracteres no deseados (como el espacio). Usuarios de la nube pública y privada de Edge
Errores de protocolo de enlace SSL Falló el protocolo de enlace TLS/SSL entre el cliente y el servidor. (La solución de problemas para esta clase de problema se aborda en un tema aparte). Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

Determina el ID del mensaje de la solicitud con errores

Herramienta de Trace

Para determinar el ID del mensaje de la solicitud con errores con la herramienta de seguimiento, haz lo siguiente:

  1. Si el problema persiste, habilita la sesión de registro para la API afectada.
  2. Realiza la llamada a la API y reproduce el problema: Servicio no disponible (503) con el código de error messaging.adaptors.http.flow.ServiceUnavailable.
  3. Selecciona una de las solicitudes con errores.
  4. Navega a la fase de AX y determina el ID del mensaje (X-Apigee.Message-ID) de la solicitud desplazándote hacia abajo en la sección Detalles de la fase, como se muestra en la siguiente figura.

    ID del mensaje en la sección Detalles de la fase

Registros de acceso de NGINX

Para determinar el ID del mensaje de la solicitud con errores a través de los registros de acceso de NGINX, haz lo siguiente:

También puedes consultar los registros de acceso de NGINX para determinar el ID del mensaje de los errores 503. Esto es particularmente útil si el problema ocurrió en el pasado o si el problema 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 503 para el proxy de API específico durante un período determinado (si el problema ocurrió en el pasado) o si aún hay solicitudes que fallan con el error 503.
  3. Si hay errores 503 con X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable, anota el ID del mensaje de una o más de esas solicitudes, como se muestra en el siguiente ejemplo:

    Entrada de ejemplo que muestra el error 503

    Entrada de ejemplo que muestra el código de estado, el ID del mensaje, la fuente de la falla y el código de falla

Errores de conexión debido a una resolución de DNS incorrecta

Diagnóstico

  1. Determina el ID del mensaje de la solicitud con errores.
  2. Busca el ID del mensaje de solicitud específico en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es posible que observes los siguientes errores:

    Un error onConnectTimeout indica que el Message Processor no pudo conectarse al servidor de backend dentro del período de tiempo de espera de conexión preestablecido (predeterminado: 3 segundos). 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22

2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
  3. Ten en cuenta la dirección IP resuelta en el error onConnectTimeout y verifica si la dirección IP es válida para tu servidor de backend. Si la dirección IP es válida, consulta Errores de conexión.
  4. Si la dirección IP no es válida, es muy probable que se deba a problemas con la resolución de DNS.
  5. Repite los pasos 3 y 4 para algunas solicitudes de API más que no se hayan realizado correctamente y verifica si ves las mismas direcciones IP no válidas o alguna otra.
  6. Busca en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) los mensajes que contengan la palabra clave DNS Refresh. Verifica si se agregan direcciones IP incorrectas o no válidas a la caché de DNS en el Message Processor de vez en cuando. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
  7. Este problema puede ocurrir si hay algún problema con los servidores DNS autorizados o los servidores de nombres configurados en /etc/resolv.conf.

    Por lo general, se pueden configurar uno o más servidores DNS autorizados para realizar la resolución de DNS. Si no hay servidores DNS autorizados, se recurrirá a la configuración establecida en /etc/resolv.conf y se realizará la resolución de DNS según corresponda. Por ejemplo, si /etc/resolv.conf está configurado para usar servidores de nombres específicos, esos servidores de nombres se usarán para realizar la resolución de DNS.
  8. Si hay algún problema con los servidores DNS autorizados o los servidores de nombres especificados en /etc/resolv.conf, los nombres de host del servidor de backend se resolverán en direcciones IP incorrectas o no válidas. Luego, las direcciones IP incorrectas o no válidas se almacenarán en la caché de DNS del Message Processor.
    1. Si el problema con los servidores DNS autoritativos o los servidores de nombres especificados en /etc/resolv.conf persiste, las direcciones IP incorrectas o no válidas seguirán en la caché de DNS del Message Processor. Mientras las direcciones IP incorrectas se almacenen en la caché de DNS del Message Processor, las solicitudes para todas las APIs que usen el servidor de backend específico fallarán con el error 503.
    2. Si el problema con los servidores DNS autoritativos o los servidores de nombres especificados en /etc/resolv.conf es intermitente, las direcciones IP buenas y malas se almacenarán de forma intermitente en la caché de DNS. En este caso, verás errores 503 de forma intermitente para todas las APIs que usen el servidor de backend específico.
  9. Si el problema con los servidores DNS persiste, verás errores continuos. Si el problema con los servidores DNS es intermitente, verás fallas intermitentes. Es decir, cada vez que el nombre de host del servidor de backend se resuelve en direcciones IP incorrectas, observas errores 503. Cuando los nombres de host del servidor de backend se resuelvan en direcciones IP correctas, observarás respuestas exitosas.

Solución

Trabaja con el administrador de tu sistema operativo y soluciona los problemas con los servidores DNS.

  1. Si hay un problema con tus servidores de nombres o servidores DNS autorizados especificados en /etc/resolv.conf, soluciona el problema con el servidor adecuado para abordarlo.
  2. Si hay algún problema con la configuración en /etc/resolv.conf en los sistemas que tienen procesadores de mensajes, corrige el problema de configuración.

Errores de conexión

Se produce un error de conexión cuando un Message Processor de Apigee Edge intenta conectarse a un servidor de backend y ocurre uno de los siguientes problemas:

  • El Message Processor no puede conectarse dentro del período de tiempo de espera de conexión preestablecido. (Valor predeterminado: 3 segundos)
  • El servidor de backend rechaza la conexión.

Diagnóstico

  1. Determina el ID del mensaje de la solicitud con errores.
  2. Busca el ID del mensaje de solicitud específico en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es posible que observes los siguientes errores:
    1. Un error de onConnectTimeout indica que el Message Processor no pudo conectarse al servidor de backend dentro del período de tiempo de espera de conexión preestablecido. 
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
    2. Un error java.net.ConnectException: Connection refused indica que el servidor de backend rechazó la conexión. 
      14:40:16.531 +0530
2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
  3. Comprueba si puedes conectarte al servidor de backend específico directamente desde cada uno de los Message Processors con el comando telnet:
    1. Si el servidor de backend se resuelve en una sola dirección IP, usa el siguiente comando: 
      telnet BackendServer-IPaddress 443
    2. Si el servidor de backend se resuelve en varias direcciones IP, usa el nombre de host del servidor de backend en el comando telnet, como se muestra a continuación: 
      telnet BackendServer-HostName 443
  4. Si puedes conectarte al servidor de backend, es posible que veas un mensaje como Connected to backend-server. Si no puedes conectarte al servidor de backend, es posible que las direcciones IP de los procesadores de mensajes no estén en la lista de entidades permitidas del servidor de backend específico.

Solución

Otorga acceso a las direcciones IP de Message Processor en el servidor de backend específico para permitir que el tráfico de los procesadores de mensajes de Edge acceda a tu servidor de backend. Por ejemplo, en Linux, puedes usar iptables para permitir el tráfico de las direcciones IP de Message Processor en el servidor de backend.

Si el problema persiste, trabaja con tu administrador de red para determinar y solucionar el problema. Si necesitas más ayuda de Apigee, comunícate con el equipo de asistencia de Apigee.

El nombre de host del servidor de destino es incorrecto

Diagnóstico

Si el nombre de host especificado en el servidor de destino es incorrecto, puedes obtener la respuesta 503 Service Unavailable con el código de error messaging.adaptors.http.flow.ServiceUnavailable.

Herramienta de Trace

Para realizar un diagnóstico con la herramienta Trace, haz lo siguiente:

  1. Si el problema persiste, habilita la sesión de registro para la API afectada.
  2. Realiza la llamada a la API y reproduce el problema: Servicio no disponible (503) con el código de error messaging.adaptors.http.flow.ServiceUnavailable.
  3. Selecciona una de las solicitudes con errores.
  4. Navega por las distintas fases del registro y ubica dónde se produjo la falla.
  5. Selecciona el FlowInfo que tiene el error. Puedes encontrar más información en el campo error.cause, que te indica el motivo del error, como se muestra en el siguiente ejemplo:

    Solicitud de muestra que muestra error.cause en el registro

    Solicitud de muestra que muestra error.cause en el registro
  6. Si observas que error.cause muestra Host not reachable, es probable que el error se deba a uno de los siguientes motivos:
    • El nombre de host especificado en la configuración del servidor de destino o del extremo de destino es incorrecto o tiene espacios o caracteres especiales no deseados.

      Por ejemplo, hay un espacio no deseado en el nombre de host, como se muestra a continuación:
      "demo-target.apigee.net "
    • El nombre de host que se reemplaza con la variable target.url en el proxy de API con la política AssignMessage o JavaScript es incorrecto o tiene un espacio o cualquier otro carácter especial no deseado.
  7. Verifica la configuración del extremo de destino o la definición del servidor de destino para ver si el nombre de host del servidor de destino es incorrecto o tiene espacios o caracteres especiales no deseados.
  8. Si el host del servidor de destino se crea de forma dinámica, verifica la política adecuada (por ejemplo, la política de AssignMessage/JavaScript) que se usó para crearlo. Verifica si el nombre del host del servidor de destino es incorrecto o tiene espacios o caracteres especiales no deseados.
  9. Una vez que hayas determinado el nombre de host del servidor de destino, ejecuta el comando nslookup/dig en el nombre de host para ver si se puede resolver.

    Por ejemplo, si ejecutas el comando nslookup en el nombre de host con un espacio no deseado, se mostrará el siguiente resultado:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Si el comando del sistema operativo nslookup tampoco resuelve el nombre de host, la causa del problema es el nombre de host incorrecto que se usó para el servidor de destino.

    Ve a Resolución.

Registros del procesador de mensajes

Para realizar un diagnóstico con los registros del Message Processor, haz lo siguiente:

  1. Determina el ID del mensaje de la solicitud con errores.
  2. Busca el ID del mensaje en el registro de Message Processor. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Si ves los siguientes mensajes de advertencia o error, significa que el Message Processor no pudo resolver el nombre de host. Como el mensaje se pospondrá, es posible que no veas este mensaje de advertencia para todos los IDs de mensaje o solicitudes. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. A continuación, se mostrará un mensaje de advertencia en el que el Message Processor quitará la dirección de la caché de DNS, ya que no se pudo acceder al host del servidor de destino. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. Luego, es posible que veas un mensaje en el que el Message Processor falla con la excepción "Host not reachable". A veces, se muestra el nombre de host como parte del mensaje de error: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. A veces, puede mostrarlo como nulo, ya que el nombre de host no se puede resolver ni alcanzar, como se muestra a continuación: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. El error Host not reachable suele ocurrir en uno de los siguientes casos:
    • El nombre de host especificado en la configuración del servidor de destino o del extremo de destino es incorrecto o tiene espacios o caracteres especiales no deseados.

      Por ejemplo, hay un espacio no deseado en el nombre del host "demo-target.apigee.net " en el siguiente mensaje de error: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • El nombre de host que se reemplaza con la variable target.url en el proxy de API con la política AssignMessage o JavaScript es incorrecto o tiene un espacio o cualquier otro carácter especial no deseado.
  8. Para determinar el nombre de host del servidor de destino con el que el Message Processor intenta comunicarse, usa una de las siguientes opciones:
    1. Examina cuidadosamente el mensaje de error que contiene Host not reachable .
    2. Si el mensaje de error muestra el nombre de host, cópialo, incluidos los espacios o los caracteres especiales.
    3. Si el mensaje de error muestra null para el nombre de host, como se ve en el siguiente mensaje de error, 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. Para determinar el nombre del host, revisa la definición del servidor de destino que se usa en el proxy de API que falló.
      2. Si el host del servidor de destino se crea de forma dinámica, verifica la política adecuada (por ejemplo, la política de AssignMessage/JavaScript) que se usó para crearlo.
  9. Una vez que hayas determinado el nombre de host del servidor de destino, ejecuta el comando nslookup/dig en el nombre de host y verifica si se puede resolver.

    Por ejemplo, ejecuta el comando nslookup en el nombre de host que tiene un espacio.

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Si el comando del sistema operativo nslookup tampoco resuelve el nombre de host, la causa de este problema es el nombre de host incorrecto que se usó para el servidor de destino.

Solución

  1. Asegúrate de que el nombre de host del servidor de destino especificado en la configuración del extremo de destino o en la definición del servidor de destino sea correcto y no tenga espacios ni caracteres especiales no deseados.
  2. Si usas alguna política AssignMessage o JavaScript para generar de forma dinámica el nombre de host del servidor de destino, investiga la definición de la política y el código, y asegúrate de que el nombre de host del servidor de destino se genere correctamente.

Errores de protocolo de enlace SSL

Se dedica un manual de soluciones de problemas completo a los errores de protocolo de enlace de TLS/SSL. Consulta Errores de protocolo de enlace SSL.

Cómo determinar el origen del problema

Ciertos tipos de errores pueden ocurrir en la conexión entrante (de norte a sur) o saliente (de sur a norte). Se produce un error entrante (norte) entre la aplicación cliente y Edge. Se produce un error saliente (dirección sur) entre Edge y el servidor de destino de backend. Para diagnosticar este tipo de problemas, tu primer trabajo es determinar si el error se produce en la conexión de norte a sur o de sur a norte.

Información sobre las conexiones de norte a sur y de sur a norte

En Edge, puedes encontrar un error 503 Service Unavailable en la conexión entrante o saliente:

  • Conexión entrante (o ascendente): Es la conexión entre la aplicación cliente y el router perimetral. El Router es el componente de Apigee Edge que controla las solicitudes entrantes que se realizan al sistema.
  • Conexión saliente (o de salida): Es la conexión entre el Message Processor de Edge y el servidor de backend. El Message Processor es un componente de Apigee Edge que envía solicitudes a la API a los servidores de destino de backend a través de un proxy.

Si eres usuario de la nube perimetral pública, es probable que no conozcas los componentes internos, como el Router o el Message Processor. Estos componentes internos no son visibles ni accesibles para los usuarios de la nube pública. Cuando es posible, proporcionamos formas alternativas de investigar el problema que no requieren acceso directo a estos componentes.

En la siguiente figura, se ilustran las conexiones ascendentes y descendentes de Apigee Edge.

Flujo de la aplicación cliente (conexión ascendente) a través de Edge hasta el servidor de backend (conexión descendente)

Cómo determinar dónde se produjo el error 503 Service Unavailable

Usa uno de los siguientes procedimientos para determinar si el error 503 Service Unavailable se produjo en la conexión de salida o de entrada.

Registro de la IU

Para determinar dónde ocurrió el error con el seguimiento de la IU, haz lo siguiente:

  1. Si el problema sigue activo, habilita el registro de IU para la API afectada.
  2. Si el seguimiento de la IU de la solicitud a la API con errores muestra que el error 503 Service Unavailable se produce durante el flujo de la solicitud de destino o lo envía el servidor de backend, el problema es de salida (es decir, entre el Message Processor y el servidor de backend).
  3. Si no obtienes el registro de la llamada a la API específica, el problema es norte-sur, entre la aplicación cliente y el enrutador.

Supervisión de API

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

Sigue un caso de ejemplo que muestra cómo solucionar problemas de 5xx con tus APIs usando API Monitoring. Por ejemplo, puedes configurar una alerta para recibir una notificación cuando la cantidad de fallas de messaging.adaptors.http.flow.ServiceUnavailable supere un umbral determinado.

Registros de acceso de NGINX

Para determinar dónde ocurrió el error con el seguimiento de la IU, haz lo siguiente:

Si el problema ocurrió en el pasado o si es intermitente y no puedes capturar el registro, sigue estos pasos:

  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 503 para un proxy de API específico.
  3. Si puedes identificar errores 503 para la API específica en el momento específico, el problema ocurrió en la conexión de salida (entre el Message Processor y el servidor de backend).
  4. De lo contrario, el problema se produjo en la conexión de salida (entre la aplicación cliente y el enrutador).