503 Service Unavailable

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X.
información

Videos

Para obtener más información sobre los errores 503, consulta los siguientes videos:

Video Descripción
Soluciona problemas y resuelve el error 503 de servicio no disponible debido a un problema de DNS Obtén más información acerca de los siguientes temas:
  • Error 503 de 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 503 de servicio no disponible en tiempo real causado por un problema de resolución de DNS
Cómo solucionar problemas y resolver el error 503 de servicio no disponible debido a un problema de la 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 Service Unavailable. luego 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 Unavailable 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; es incorrecto nombre de host o fallas del protocolo de enlace SSL durante la comunicación 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 DNS del servidor de destino generó direcciones IP incorrectas que generaron 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
El nombre de host del servidor de destino es incorrecto El host del servidor de destino especificado es incorrecto o contiene caracteres no deseados (como el espacio). Usuarios perimetrales de nubes públicas y privadas
Fallas del protocolo de enlace SSL Falló el protocolo de enlace TLS/SSL entre el cliente y el servidor. (Solución de problemas para esta clase de el problema se aborda en un tema aparte). Usuarios perimetrales de nubes públicas y privadas

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 con errores mediante la Herramienta de seguimiento, haz lo siguiente:

  1. Si el problema aún está activo, habilita la sesión de seguimiento de la API afectada.
  2. Realiza la 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 fallidas.
  4. Navega a la fase AX y determina el ID del mensaje (X-Apigee.Message-ID) de la solicitud. Para ello, desplázate hacia abajo en la sección Fase Details, como se muestra en la siguiente imagen.

    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, haz lo siguiente:

También puedes consultar los registros de acceso de NGINX para determinar el ID de 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 solicitudes que aún fallan con 503.
  3. Si hay errores 503 con X-Apigee-fault-code Messaging.adaptors.http.flow.ServiceUnavailable, ten en cuenta 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, la fuente y el código del error

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 la dirección IP 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 a la API fallidas y verifica si ves la misma dirección IP o cualquier otra no válida.
  6. Busca mensajes con la palabra clave Actualización de DNS en el registro del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log). Comprueba de vez en cuando si se agregan direcciones IP incorrectas o no válidas a la caché 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 producirse si hay algún problema con los servidores DNS autorizados o con 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, se recurrirá a la configuración establecida en /etc/resolv.conf y realizará la resolución de DNS según corresponda. Por ejemplo, si /etc/resolv.conf está configurado para usar servidores de nombres específicos, se usarán esos servidores de nombres 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 como direcciones IP incorrectas o no válidas. Las direcciones IP incorrectas o no válidas se almacenarán en la caché DNS del 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 continuarán en la caché de DNS de Message Processor. Siempre que las direcciones IP incorrectas se almacenen en la caché DNS del Message Processor, las solicitudes para todas las APIs que usen el servidor de backend específico fallarán y se mostrará 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 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 esas APIs que usan el servidor de backend específico.
  9. Si el problema con los servidores DNS es persistente, 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 direcciones IP correctas, observarás respuestas exitosas.

Solución

Trabaja con el administrador de tu sistema operativo para solucionar los problemas de los servidores DNS.

  1. Si hay un problema con los servidores DNS autorizados o 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 Processor, soluciona el problema de configuración.

Errores de conexión

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

  • Message Processor no puede conectarse durante el tiempo de espera de conexión predeterminado. (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 de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Puedes observar 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 la conexión fue rechazada por el servidor backend.
      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 una de las 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, usar el nombre de host de el 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 backend, es posible que ya que la interfaz de los procesadores Las direcciones IP no están incluidas en la lista de entidades permitidas del backend específico servidor.

Solución

Otorga acceso a las direcciones IP del procesador de mensajes en el servidor de backend específico para permitir de los procesadores de mensajes de Edge para acceder al 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, trabaja con el administrador de red para determinar y solucionar el problema 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 seguimiento

Para diagnosticar con la herramienta Trace, sigue estos pasos:

  1. Si el problema aún está activo, habilita la sesión de seguimiento de la API afectada.
  2. Realiza la 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 fallidas.
  4. Navega por las diferentes fases del seguimiento y localiza dónde ocurrió la falla.
  5. Selecciona el elemento FlowInfo que tiene el error. Puedes encontrar más información en el campo error.cause que te puede decir la causa del error como se muestra en el siguiente ejemplo:

    Solicitud de muestra que muestra error.cause en el seguimiento

    Solicitud de muestra que muestra error.cause en el seguimiento
  6. Si observas que error.cause muestra Host not reachable, entonces la causa probable del error es una de las siguientes:
    • El nombre de host especificado en la configuración del servidor de destino/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 reemplazado por la variable target.url en el proxy de API con AssignMessage La política de JavaScript es incorrecta 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 ver si el nombre del 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 AssignMessage/JavaScript) que se usó para crearlo. Marcar para comprueba si el nombre de 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 del 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 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 diagnosticar con los registros del procesador de mensajes, 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, Message Processor no pudo resolver el nombre de host. Como el mensaje se pospondrá, es posible que no lo veas un mensaje de advertencia para todas las solicitudes o IDs 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. Luego, aparecerá un mensaje de advertencia, en el que 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. Es posible que veas un mensaje en el que falla el Procesador de mensajes, con la excepción “Host no accesible”. 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, es posible que aparezca como null, ya que el nombre de host no se puede resolver ni se puede 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 de destino/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 “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 por medio de la política AssignMessage o JavaScript es incorrecto o tiene un espacio o cualquier otro carácter especial no deseado.
  8. Determina el nombre de host del servidor de destino con el que el Message Processor intenta comunicarse mediante 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 del host, cópielo, incluidos los espacios o 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. Determina el nombre del host verificando la definición del servidor de destino utilizada 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, AssignMessage/JavaScript policy) 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 del 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 que se especifica en la configuración del extremo de destino o en el servidor de destino sea correcta y no contenga espacios ni caracteres especiales no deseados.
  2. Si usas cualquier política de AssignMessage/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.

Fallas del protocolo de enlace SSL

Se dedica toda la 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 tanto en el tráfico entrante (límite norte) como al tráfico saliente (dirección sur) conexión. Se produce un error entrante (límite norte) entre la aplicación cliente y Edge. Los El error saliente (hacia el sur) ocurre entre Edge y el servidor de destino de backend. Para diagnosticar tu primer trabajo es averiguar si el error ocurre en el sentido norte o conexión hacia el sur.

Comprende las conexiones hacia el norte y el sur

En Edge, puedes encontrar el error 503 Servicio no disponible en la conexión entrante o saliente:

  • Conexión entrante (o con dirección norte): la conexión entre el cliente y el router perimetral. El router es el componente de Apigee Edge que controla de las solicitudes entrantes realizadas al sistema.
  • Conexión saliente (o hacia el sur): la conexión entre el perímetro. Message Processor y el servidor de backend. Message Processor es un componente de Apigee Edge que procesa las solicitudes de la API a los servidores de destino del backend.

Si eres usuario de la nube pública de Edge, es probable que no conozcas los componentes internos, como el router o el procesador de mensajes. Estos componentes internos no son visibles ni accesibles para Usuarios de la nube pública Siempre que sea posible, brindamos maneras alternativas de investigar el problema que no requieren acceso directo a estos componentes.

En la siguiente figura, se ilustran las conexiones hacia el norte y el sur para Apigee Edge.

Flujo de la aplicación cliente (conexión hacia el norte) a través del perímetro al servidor de backend (conexión hacia el sur)

Determina dónde se produjo el error 503 Servicio no disponible

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

Seguimiento de la IU

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

  1. Si el problema aún está activo, habilita el seguimiento de la 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 Servicio no disponible ocurre durante el flujo de solicitud de destino o el servidor backend lo envía, entonces el problema southbound (es decir, entre Message Processor y el backend) servidor).
  3. Si no obtienes el registro de la llamada a la API específica, entonces el problema es northbound entre la aplicación cliente y el router.

Supervisión de API

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

Lee una situación de ejemplo que demuestra cómo solucionar problemas 5xx con tus APIs con la supervisión de API. Por ejemplo, es posible que quieras configurar una alerta para recibir una notificación cuando la cantidad de fallas de messaging.adaptors.http.flow.ServiceUnavailable supere un umbral en particular.

Registros de acceso de NGINX

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

Si el problema ocurrió en el pasado o si es intermitente y no puedes capturar el registro y, luego, seguir 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 se produjo en la conexión con dirección sur (entre Message Processor y el servidor de backend).
  4. De no ser así, el problema ocurrió en la conexión límite norte (entre la aplicación cliente y el router).