503 Service AVAILABLE - Cierre prematuro por servidor de backend

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Síntoma

La aplicación cliente obtiene un estado de respuesta HTTP 503 con el mensaje Service Unavailable después de una llamada de proxy a la 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 veas el siguiente mensaje de error:

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

Causas posibles

Causa	Descripción	Instrucciones de solución de problemas aplicables para
El servidor de destino cierra la conexión de forma prematura	El servidor de destino finaliza la conexión de forma prematura mientras el Message Processor aún envía la carga útil de la solicitud.	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

Causa: El servidor de destino cierra la conexión de forma prematura

Diagnóstico

1. Si eres usuario de una nube pública o una nube privada, haz lo siguiente:
   1. Usa la herramienta Trace (como se explica en Pasos comunes para el diagnóstico) y verifica que las siguientes opciones estén configuradas en el panel Datos de Analytics registrados:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Usa la herramienta de seguimiento (como se explica en Pasos comunes de diagnóstico) y verifica que las dos opciones siguientes estén configuradas en el panel Error justo después de la propiedad state TARGET_REQ_FLOW:
      • error.class: com.apigee.errors.http.server.ServiceUnavailableException.
      • error.cause: Broken pipe

      

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

     Excepción 1: java.io.IOException: Se produjo un error en la canalización 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.o 2: Excepción onExceptionWrite: {}
     java.io.IOException: Canal roto

     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 Message Processor aún estaba escribiendo la carga útil de la solicitud en el servidor de backend, el servidor de backend cerró la conexión de forma prematura. Por lo tanto, Message Processor arroja la excepción java.io.IOException: Broken pipe.
   • El Remote:IP:PORT indica el número de puerto y la dirección IP del servidor de backend resuelto.
   • El atributo bytesWritten=76295 del mensaje de error anterior indica que el procesador de mensajes envió una carga útil de 76295 bytes al servidor de backend cuando la conexión se cerró de forma prematura.
   • El atributo bytesRead=0 indica que Message Processor no recibió ningún dato (respuesta) del servidor de backend.
   • Para investigar este problema con más detalle, recopila un tcpdump en el servidor de backend o en el procesador de mensajes y analízalo como se explica a continuación.

Usa 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 reunir tcpdump en el procesador de mensajes:

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

2. Analiza los tcpdump capturados:

   Resultado de ejemplo de tcpdump (recopilado en Message Processor):

   

   En el tcpdump anterior, podrás ver lo siguiente:

   1. En el paquete 4, Message Processor envió una solicitud POST al servidor de backend.
   2. En los paquetes 5, 8, 9, 10 y 11, el procesador de mensajes 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 una ACK para los paquetes de datos de aplicación recibidos y, luego, responder con la carga útil de la respuesta, el servidor de backend responde con una FIN ACK que inicia el cierre de la conexión.
   5. Esto muestra con claridad que el servidor de backend cierra la conexión de forma prematura mientras el Message Processor aún estaba enviando la carga útil de la solicitud.
   6. Esto hace que Message Processor registre un error IOException: Broken Pipe y muestre un 503 al cliente.

Resolución

1. Trabaja con tus equipos de aplicaciones y redes, o con ambos, para analizar y solucionar el problema de las desconexiones prematuras del 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 una capa o un dispositivo de red intermedio entre Apigee y el servidor de backend, asegúrate de que no se agote el tiempo de espera antes de que se reciba toda la carga útil de la solicitud.

Si el problema persiste, consulta Recopila 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 el equipo de asistencia de Apigee Edge:

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

• Nombre de la organización
• Nombre del entorno
• Nombre del proxy de API
• Completa el comando curl para reproducir el error 503
• Archivo de seguimiento que contiene la solicitud con el error 503 Service Unavailable
• Si en este momento no se producen los errores 503, proporciona el período con la información de la zona horaria cuando se produjeron errores 503 en el pasado.

Si eres un 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 errores 503
• 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 de Message Processor
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• El período con la información de zona horaria en el que se produjeron los errores 503
• Se recopilaron Tcpdumps en los procesadores de mensajes y el servidor de backend cuando se produjo el error.