503 Service Unavailable

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

Video Descripción
Soluciona problemas y resuelve el error 503 de servicio no disponible debido a un problema de DNS Obtén información sobre lo siguiente:
  • Error 503 Servicio no disponible debido a problemas relacionados con la resolución de DNS y la red en Apigee Edge
  • Solución de problemas y resolución de un error 503 de servicio no disponible en tiempo real causado por un problema de resolución de DNS
Soluciona problemas y resuelve el error 503 de 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 de proxy de API.

Mensajes de error

Verás 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 Available con el código de error messaging.adaptors.http.flow.ServiceUnavailable se produce si el procesador de mensajes de Apigee Edge experimenta errores debido a que se agotó el tiempo de espera de la conexión, un nombre de host incorrecto o fallas del protocolo de enlace SSL mientras se comunica con el servidor de backend.

Las posibles causas de la respuesta 503 Service AVAILABLE 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 provocaron errores de conexión. Usuarios de la nube privada perimetral
Errores de conexión Los problemas de red o conectividad impiden que el cliente se conecte al servidor. Usuarios de la nube privada perimetral
Nombre de host del servidor de destino incorrecto El host del servidor de destino especificado es incorrecto o contiene caracteres no deseados (como espacios). Usuarios de la nube pública y privada de Edge
Fallas del protocolo de enlace SSL Se produjo un error en el protocolo de enlace TLS/SSL entre el cliente y el servidor. (La solución de problemas para esta clase de problema se trata en un tema aparte). Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

Determina el ID de mensaje de la solicitud con errores

Herramienta de seguimiento

Para determinar el ID del mensaje de la solicitud que falla con la herramienta Trace:

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

    ID de 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 mediante los registros de acceso de NGINX, sigue estos pasos:

También puedes consultar los registros de acceso de NGINX para determinar el ID del mensaje para los errores 503. 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 503 para el proxy de API específico durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con el 503.
  3. Si hay errores 503 con X-Apigee-fault-codemessaging.adaptors.http.flow.ServiceAVAILABLE, anota el ID del mensaje de una o más 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, el origen y el código de la 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 de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es posible que observes los siguientes errores:

    Un error onConnectTimeout indica que Message Processor no pudo conectarse al servidor de backend dentro del tiempo de espera de conexión predeterminado (valor 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. Anota la dirección IP resuelta en el error onConnectTimeout y verifica si es válida para tu servidor de backend. Si la dirección IP es válida, ve a Errores de conexión.
  4. Si la dirección IP no es válida, lo más probable es que se deba a problemas con la resolución de DNS.
  5. Repite los pasos 3 y 4 para algunas solicitudes más fallidas a la API y verifica si ves la misma dirección IP o alguna otra no válida.
  6. Busca en el registro del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log) los mensajes que contengan la palabra clave Actualización de DNS. Verifica de vez en cuando si se agregan direcciones IP incorrectas o no válidas a la caché de DNS en Message Processor.
    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 inconveniente con los servidores DNS autorizados o los servidores de nombres configurados en /etc/resolv.conf.

    Por lo general, podría haber uno o más servidores DNS autorizados configurados para realizar la resolución de DNS. Si no hay servidores DNS autorizados, recurre a la configuración de /etc/resolv.conf y realiza 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 se usarán para realizar la resolución de DNS.
  8. Si hay problemas 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. Las direcciones IP incorrectas o no válidas se almacenarán en la caché de DNS de Message Processor.
    1. Si el problema con los servidores DNS autorizados o los servidores de nombres especificados en /etc/resolv.conf es persistente, las direcciones IP incorrectas o no válidas permanecerán en la caché de DNS de Message Processor. Siempre que las direcciones IP incorrectas se almacenen en la caché de DNS de Message Processor, las solicitudes de todas esas APIs que usen el servidor de backend específico fallarán con el error 503.
    2. Si el problema con los servidores DNS autorizados o los servidores de nombres especificados en /etc/resolv.conf es intermitente, las direcciones IP correctas y incorrectas 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 fallas continuas. 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, se observan errores 503. Y cuando los nombres de host del servidor de backend se resuelvan en buenas direcciones IP, verás respuestas exitosas.

Resolución

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

  1. Si hay un problema con tus servidores DNS autorizados o con los servidores de nombres especificados en /etc/resolv.conf, corrígelo con el servidor adecuado para solucionarlo.
  2. Si hay algún problema con la configuración de /etc/resolv.conf en los sistemas que tienen Message Processors, soluciona ese problema.

Errores de conexión

Se produce un error de conexión cuando un procesador de mensajes de Apigee Edge intenta conectarse a un servidor de backend y se produce uno de estos problemas:

  • Message Processor no puede conectarse dentro del tiempo de espera de conexión predeterminado. (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 de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es posible que observes los siguientes errores:
    1. Un error onConnectTimeout indica que Message Processor no pudo conectarse al servidor de backend dentro del tiempo de espera de conexión predeterminado.
      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 denied 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. Verifica si puedes conectarte al servidor de backend específico directamente desde cada uno de los procesadores de mensajes 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 se deba a que las direcciones IP de Message Processors no están incluidas en la lista de entidades permitidas del servidor de backend específico.

Resolución

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

Si el problema persiste, comunícate con el administrador de red para determinarlo y corregirlo. Si necesitas más ayuda de Apigee, comunícate con el equipo de asistencia de Apigee.

Nombre de host del servidor de destino incorrecto

Diagnóstico

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

Herramienta de seguimiento

Para realizar un diagnóstico con la herramienta Trace, sigue estos pasos:

  1. Si el problema sigue activo, habilita la sesión de seguimiento para la API afectada.
  2. Realiza una llamada a la API y reproduce el problema - 503 Servicio no disponible 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 seguimiento y localiza dónde se produjo la falla.
  5. Selecciona la FlowInfo que tiene el error. Puedes encontrar más información en el campo error.cause que pueda indicarte la causa de la falla, como se muestra en el siguiente ejemplo:

    Solicitud de muestra que muestra error.Cause en el seguimiento

    Solicitud de muestra que muestra un error.Cause en el seguimiento
  6. Si observa que error.cause muestra error.cause, la causa probable del error es una de las siguientes:
    • El nombre de host especificado en la configuración del servidor o del extremo de destino es incorrecto o tiene espacios no deseados o caracteres especiales.

      Por ejemplo, hay un espacio no deseado en el nombre del host, como se muestra a continuación:
      "demo-target.apigee.net "
                        
    • El nombre de host reemplazado por la variable target.url en el proxy de API con la política AssignMessage o JavaScript es incorrecto o tiene un espacio o algún otro carácter especial no deseado.
  7. Verifica la configuración del extremo de destino o la definición del servidor de destino para verificar si el nombre de host del servidor de destino es incorrecto o si 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 correspondiente (por ejemplo, la política AssignMessage/JavaScript) que se usó para crearlo. Verifica si el nombre de host del servidor de destino es incorrecto o si 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 muestra 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 puede resolver el nombre de host, la causa de este 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 mediante los registros del procesador de mensajes, sigue estos pasos:

  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, Message Processor no pudo resolver el nombre de host. Dado que el mensaje se pospondrá, es posible que no veas este mensaje de advertencia para todos los IDs o solicitudes de mensajes.
    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 Message Processor quitará la dirección de la caché 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. Es posible que veas un mensaje en el que Message Processor falla con la excepción "Host not reachable". En ocasiones, 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. En ocasiones, puede mostrarse como null, ya que el nombre de host no se puede resolver ni acceder, 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. Por lo general, el error Host not reachable ocurre en uno de los siguientes casos:
    • El nombre de host especificado en la configuración del servidor o del extremo de destino es incorrecto o tiene espacios no deseados o caracteres especiales.

      Por ejemplo, hay un espacio no deseado en el nombre de 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 reemplazado por la variable target.url en el proxy de API con la política AssignMessage o JavaScript es incorrecto o tiene un espacio o algún otro carácter especial no deseado.
  8. Usa uno de los siguientes métodos para determinar el nombre de host del servidor de destino con el que Message Processor intenta comunicarse:
    1. Examina el mensaje de error que contiene Host not reachable con atención.
    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 muestra 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, verifica la definición de servidor de destino que se usa en el proxy de API con errores.
      2. Si el host del servidor de destino se crea de forma dinámica, verifica la política adecuada (por ejemplo, la política deAssignMessage/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.

Resolució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 cualquier política deAssignMessage/JavaScript para generar el nombre de host del servidor de destino de forma dinámica, 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.

Fallas de protocolo de enlace SSL

Se dedica toda una guía de solución de problemas a los errores de protocolo de enlace TLS/SSL. Consulta Fallas del protocolo de enlace SSL.

Determinar el origen del problema

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

Comprende las conexiones con dirección norte y sur

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

  • Conexión entrante (o con dirección norte): 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 hacen al sistema.
  • Conexión saliente (o con dirección sur): Es la conexión entre el procesador de mensajes perimetrales y el servidor de backend. El Message Processor es un componente de Apigee Edge que procesa las solicitudes a la API a los servidores de destino de backend.

Si eres usuario de la nube pública perimetral, es probable que no conozcas los componentes internos, como el router o el procesador de mensajes. Los usuarios de la nube pública no pueden ver estos componentes internos ni acceder a ellos. Siempre que sea posible, proporcionamos formas alternativas de investigar el problema que no requieren acceso directo a estos componentes.

En la siguiente figura, se ilustran las conexiones con dirección norte y sur para Apigee Edge.

Flujo de la aplicación cliente (conexión al norte) a través de Edge al servidor de backend (conexión con dirección sur)

Determina dónde ocurrió el error 503 Servicio no disponible

Usa uno de los siguientes procedimientos para determinar si el error 503 del servicio no disponible se produjo en la conexión con dirección norte o sur.

Seguimiento de la IU

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

  1. Si el problema sigue activo, habilita el seguimiento de IU para la API afectada.
  2. Si el seguimiento de la IU de la solicitud a la API que falla muestra que el error 503 Service no disponible se produce durante el flujo de solicitud de destino o lo envía el servidor de backend, el problema es southbound (es decir, entre el Message Processor y el servidor de backend).
  3. Si no obtienes el seguimiento para la llamada a la API específica, el problema es northbound, entre la aplicación cliente y el router.

Supervisión de API

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 quieras configurar una alerta para recibir una notificación cuando la cantidad de fallas messaging.adaptors.http.flow.ServiceUnavailable supere un umbral determinado.

Registros de acceso de NGINX

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

Si el problema ya 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 ese momento, el problema ocurrió en la conexión southbound (entre el Message Processor y el servidor de backend).
  4. De lo contrario, el problema ocurrió en la conexión northbound (entre la aplicación cliente y el router).