503 Service AVAILABLE - Cierre prematuro por servidor de backend

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

Síntoma

La aplicación cliente obtiene un estado de respuesta HTTP 503 con el mensaje Service Unavailable después de una llamada al proxy de API.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 503 Service Unavailable

Además, es posible que observes el siguiente mensaje de error:

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

Causas posibles

Pasos comunes de diagnóstico

Determina el ID del mensaje de la solicitud con errores

Causa: El servidor de destino cierra la conexión antes de tiempo

Diagnóstico

1. Si eres usuario de la nube pública o la nube privada , haz lo siguiente:
   1. Usa la herramienta de Trace (como se explica en Pasos comunes de diagnóstico) y verifica que tengas configurados los siguientes elementos en el panel Analytics Data Recorded:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Usa la herramienta de Trace (como se explica en Pasos comunes de diagnóstico) y verifica que tengas configurados los siguientes elementos en el panel Error inmediatamente después de la propiedad TARGET_REQ_FLOW state:
      • error.class: com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      

   3. Consulta Usa tcpdump para realizar una investigación más detallada.
2. Si eres usuario de la nube privada , haz lo siguiente:
   • Determina el ID del mensaje de la solicitud con errores.
   • Busca el ID del mensaje en el registro del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   • Verás una de las siguientes excepciones:

     Excepción n.° 1: java.io.IOException: Se produjo una canalización interrumpida mientras se escribía en el canal ClientOutputChannel

     2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
     rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
     INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
     Exception java.io.IOException: Broken pipe occurred while writing to channel
     ClientOutputChannel(ClientChannel[Connected:
     Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
     bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)

     o

     Excepción n.° 2: onExceptionWrite exception: {}
     java.io.IOException: Broken pipe

     2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
     rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
     NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
     ClientChannel[Connected: Remote:IP:PORT
     Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
     ms  isOpen=false.onExceptionWrite exception: {}
     java.io.IOException: Broken pipe

   • Ambas excepciones indican que, mientras el Message Processor aún escribía la carga útil de la solicitud en el servidor de backend, este último cerró la conexión antes de tiempo. Por lo tanto, el Message Processor arroja la excepción java.io.IOException: Broken pipe.
   • El Remote:IP:PORT indica la dirección IP y el número de puerto resueltos del servidor de backend.
   • El atributo bytesWritten=76295 en el mensaje de error anterior indica que el Message Processor había enviado una carga útil de 76295 bytes al servidor de backend cuando se cerró la conexión antes de tiempo.
   • El atributo bytesRead=0 indica que el Message Processor no ha recibido ningún dato (respuesta) del servidor de backend.
   • Para investigar más a fondo este problema, recopila un tcpdump en el servidor de backend o en el Message Processor y analízalo como se explica a continuación.

Cómo usar tcpdump

1. Captura un tcpdump en el servidor de backend o en el Message Processor con los siguientes comandos:

   Comando para recopilar tcpdump en el servidor de backend:

   tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
   

   Comando para recopilar tcpdump en el Message Processor:

   tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
   

2. Analiza el tcpdump capturado:

   Resultado de tcpdump de muestra (recopilado en el Message Processor):

   

   En el tcpdump anterior, puedes ver lo siguiente:

   1. En el paquete 4, el Message Processor envió una solicitud POST a el servidor de backend.
   2. En los paquetes 5, 8, 9, 10, 11 el Message Processor continuó enviando la carga útil de la solicitud al servidor de backend.
   3. En los paquetes 6 y 7,el servidor de backend respondió con ACK para una parte de la carga útil de la solicitud recibida del Message Processor.
   4. Sin embargo, en el paquete 12, en lugar de responder con un ACK para los paquetes de datos de la aplicación recibidos y, luego, con la carga útil de la respuesta , el servidor de backend responde con un FIN ACK que inicia el cierre de la conexión.
   5. Esto muestra claramente que el servidor de backend cierra la conexión antes de tiempo mientras el Message Processor aún enviaba la carga útil de la solicitud.
   6. Esto hace que el Message Processor registre un IOException: Broken Pipe error y muestre un 503 al cliente.

Solución

1. Trabaja con tu equipo de aplicaciones o de redes (o ambos) para analizar y solucionar el problema de las desconexiones prematuras en el servidor de backend.
2. Asegúrate de que la aplicación del servidor de backend no agote el tiempo de espera ni restablezca la conexión antes de recibir toda la carga útil de la solicitud.
3. Si tienes algún dispositivo o capa de red intermediario entre Apigee y el servidor de backend, asegúrate de que no agoten el tiempo de espera antes de que se reciba toda la carga útil de la solicitud.

Si el problema persiste, consulta Se debe recopilar información de diagnóstico.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee Edge:

Si eres usuario de la nube pública, proporciona la siguiente información:

• Nombre de la organización
• Nombre del entorno
• Nombre del proxy de API
• Comando curl completo para reproducir el error 503
• Archivo de seguimiento que contiene la solicitud con el error 503 Service Unavailable
• Si los errores 503 no ocurren actualmente, proporciona el período con la información de la zona horaria en la que ocurrieron los errores 503 en el pasado.

Si eres usuario de la nube privada, proporciona la siguiente información:

• Mensaje de error completo observado para las solicitudes con errores
• Organización, nombre del entorno y nombre del proxy de API para los que observas 503 errores
• Paquete de proxy de API
• Archivo de seguimiento que contiene las solicitudes con el error 503 Service Unavailable
• Registros de acceso de NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Registros del Message Processor
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• El período con la información de la zona horaria en la que ocurrieron los errores 503
• Tcpdumps recopilados en los Message Processors y el servidor de backend cuando se produjo el error