502 Error de puerta de enlace inesperado EOF

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

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 502 con el mensaje. Bad Gateway como respuesta a las llamadas a la API

El código de estado HTTP 502 significa que el cliente no está recibiendo una respuesta válida del los servidores de backend que deben cumplir con la solicitud.

Mensajes de error

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

HTTP/1.1 502 Bad Gateway

Además, puedes observar el siguiente mensaje de error:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Causas posibles

Una de las causas típicas de 502 Bad Gateway Error es Unexpected EOF. de errores, que puede deberse a los siguientes motivos:

Pasos comunes de diagnóstico

Para diagnosticar el error, puedes usar cualquiera de los siguientes métodos:

• Supervisión de API
• Herramienta Trace
• Registros de acceso de NGINX

Causa: El servidor de destino configurado es incorrecto

El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL.

Diagnóstico

1. Usas la supervisión de API, la herramienta Trace o Registros de acceso de NGINX para determinar el ID del mensaje el código y la fuente del error 502.
2. Habilita el seguimiento en la IU de la API afectada.
3. Si el seguimiento de la solicitud a la API con errores muestra lo siguiente:
   1. El error 502 Bad Gateway se muestra en cuanto se inicia la solicitud de flujo de destino.
   2. El elemento error.class muestra messaging.adaptors.http.UnexpectedEOF.

      Es muy probable que este problema se deba a un servidor de destino incorrecto. configuración.

4. Obtén la definición del servidor de destino mediante la llamada a la API de Edge Management:
   1. Si eres un usuario de la nube pública, usa esta API:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. Si eres un usuario de la nube privada, usa esta API:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      Ejemplo de definición de TargetServer defectuosa:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. La definición ilustrada de TargetServer es un ejemplo de una de las opciones de configuración incorrecta, que se explica de la siguiente manera:

   Supongamos que se configuró el servidor de destino mocktarget.apigee.net para aceptar conexiones seguras (HTTPS) en el puerto 443. Sin embargo, si observas la definición del servidor de destino, no hay otros atributos o marcas que indiquen que está para conexiones seguras. Esto hace que Edge trate las solicitudes a la API que se dirigen al servidor de destino específico como solicitudes HTTP (no seguras). Por lo tanto, Edge no iniciar el proceso de protocolo de enlace SSL con este servidor de destino.

   Dado que el servidor de destino está configurado para aceptar solo solicitudes HTTPS (SSL) en 443, rechazar la solicitud de Edge o cerrar la conexión. Como resultado, obtienes un Se produjo un error UnexpectedEOFAtTarget en el procesador de mensajes. El procesador de mensajes enviará 502 Bad Gateway como respuesta al cliente.

Solución

Siempre asegúrate de que el servidor de destino esté configurado correctamente según tus requisitos.

En el ejemplo anterior, si quieres realizar solicitudes a un destino seguro (HTTPS/SSL) debes incluir los atributos SSLInfo con la marca enabled configurada a true. Si bien se permite agregar los atributos SSLInfo para un servidor de destino en el destino definición del extremo, se recomienda agregar los atributos SSLInfo como parte del destino del servidor web para evitar confusiones.

1. Si el servicio de backend requiere comunicación SSL unidireccional, haz lo siguiente:
   1. Debes habilitar TLS/SSL en la definición TargetServer. Para ello, incluye el SSLInfo atributos en los que la marca enabled se establece en true, como se muestra a continuación:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. Si quieres validar el certificado del servidor de destino en Edge, también debes incluir el almacén de confianza (que contiene el certificado del servidor de destino), como se muestra a continuación:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. Si el servicio de backend requiere comunicación SSL bidireccional, entonces:
   1. Debes tener atributos SSLInfo con ClientAuthEnabled, Keystore, KeyAlias y Las marcas Truststore se configuraron correctamente, como se muestra a continuación:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

Referencias

Balanceo de cargas en servidores de backend

Causa: EOFException del servidor de backend

Es posible que el servidor de backend envíe EOF (fin de archivo) de manera abrupta.

Diagnóstico

1. Usas la supervisión de API, la herramienta Trace o Registros de acceso de NGINX para determinar el ID del mensaje el código y la fuente del error 502.
2. Revisa los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) y busca para ver si Tener eof unexpected para la API específica o si tienes el messageid único para la API la solicitud, puedes buscarla.

   Ejemplo de seguimiento de pila de excepciones del registro de Message Processor

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   En el ejemplo anterior, puedes ver que el error java.io.EOFException: eof unexpected se produjo mientras el procesador de mensajes intentaba leer una respuesta de el servidor de backend. Esta excepción indica el final del archivo (EOF) o de la transmisión se haya alcanzado de forma inesperada.

   Es decir, Message Processor envió la solicitud a la API al servidor de backend y esperó o leer la respuesta. Sin embargo, el servidor backend finalizó la conexión de forma abrupta antes de que el procesador de mensajes recibiera la respuesta o pudiera leer la respuesta completa.

3. Revisa los registros del servidor de backend y fíjate si hay algún error o información que pueda que hicieron que el servidor de backend finalizara la conexión de forma abrupta. Si encuentras información o errores, ve a Resolución. y solucionar el problema correctamente en tu servidor de backend.
4. Si no encuentras ningún error ni información en tu servidor de backend, recopila el resultado de tcpdump en Message Processor:
   1. Si el host de tu servidor de backend tiene una sola dirección IP, usa el siguiente comando:

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

   2. Si el host de tu servidor de backend tiene varias direcciones IP, usa el siguiente comando:

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

      Generalmente, este error se produce porque el servidor de backend responde con [FIN,ACK] tan pronto como el Message Processor envíe la solicitud al servidor de backend.

5. Considera el siguiente ejemplo de tcpdump.

   Muestra de tcpdump tomada cuando 502 Bad Gateway Error (UnexpectedEOFAtTarget) ocurrió

   

6. En el resultado de TCPDump, observas la siguiente secuencia de eventos:
   1. En el paquete 985, Message Processor envía la solicitud a la API al servidor de backend.
   2. En el paquete 986, el servidor de backend responde de inmediato con [FIN,ACK].
   3. En el paquete 987, Message Processor responde con [FIN,ACK] al backend servidor.
   4. Eventualmente, las conexiones se cierran con [ACK] y [RST] en ambos lados.
   5. Dado que el servidor de backend envía [FIN,ACK], obtendrás la excepción Excepción java.io.EOFException: eof unexpected en el mensaje Procesador.
7. Esto puede suceder si hay un problema de red en el servidor backend. Interactúa con tu red con el equipo de operaciones de analizar el problema en profundidad.

Solución

Soluciona el problema en el servidor de backend de manera adecuada.

Si el problema persiste y necesitas asistencia para solucionar el problema 502 Bad Gateway Error o tú Si sospechas que se trata de un problema en Edge, comunícate con el equipo de asistencia de Apigee Edge.

Causa: Tiempo de espera de keep alive configurado de forma incorrecta

Antes de diagnosticar si esta es la causa de los errores 502, lee detenidamente los siguientes conceptos.

Conexiones persistentes en Apigee

De forma predeterminada, Apigee (y en adelante con el estándar HTTP/1.1) usa conexiones persistentes cuando se comunica con el servidor backend de destino. Las conexiones persistentes pueden aumentar el rendimiento permitiendo que se reutilice una conexión TCP y (si corresponde) TLS/SSL ya establecida, lo que reduce las sobrecargas de latencia. Se controla el tiempo de persistencia de una conexión a través de un tiempo de espera keep alive de la propiedad (keepalive.timeout.millis)

Tanto el servidor backend como el Apigee Message Processor usan tiempos de espera de keep alive para mantener conexiones abiertas unas con otras. Una vez que no se reciben datos dentro del tiempo de espera de keep alive el servidor backend o Message Processor puede cerrar la conexión con el otro.

Los proxies de API implementados en un procesador de mensajes en Apigee, de forma predeterminada, tienen un tiempo de espera de keep alive establecido en 60s a menos que se anule. Una vez que no se reciban datos de 60s, Apigee y cerrar la conexión con el servidor backend. El servidor backend también mantendrá un tiempo de espera de keep alive Cuando esto ocurra, el servidor backend cerrará la conexión con Message Processor.

Implicación de una configuración incorrecta del tiempo de espera de keep alive

Si Apigee o el servidor de backend se configuran con tiempos de espera incorrectos de keep alive, da como resultado una condición de carrera que hace que el servidor de backend envíe un End Of File (FIN) inesperado en respuesta a la solicitud de un recurso.

Por ejemplo, si el tiempo de espera de keep alive se configura dentro del proxy de API o en el campo Message Procesador con un valor mayor o igual que el tiempo de espera del servidor de backend upstream y, luego, puede ocurrir la siguiente condición de carrera. Es decir, si el Encargado del tratamiento de datos no recibe muy cerca del umbral del tiempo de espera de keep alive del servidor de backend y, luego, se envía y se envía al servidor de backend con la conexión existente. Esto puede producir 502 Bad Gateway debido a un error inesperado de EOF como se explica a continuación:

1. Supongamos que se estableció el tiempo de espera de keep alive en Message Processor y en el servidor de backend es de 60 segundos y no hay nuevas la solicitud llegó hasta 59 segundos después de que el responsable Message Processor.
2. El Message Processor continúa y procesa la solicitud que llegó en el segundo 59. mediante la conexión existente (ya que aún no transcurrió el tiempo de espera de keep alive) y envía al servidor de backend.
3. Sin embargo, antes de que la solicitud llegue al servidor de backend, el tiempo de espera de keep alive se superó el umbral en el servidor de backend.
4. La solicitud del procesador de mensajes para un recurso está en tránsito, pero el servidor backend intenta cerrar la conexión enviando un paquete FIN al mensaje Procesador.
5. Mientras el procesador de mensajes espera a que se reciban los datos, recibe el FIN inesperado, y la conexión finaliza.
6. Esto da como resultado una Unexpected EOF y, luego, una 502. que muestra Message Processor al cliente.

En este caso, observamos que se produjo el error 502 porque el mismo tiempo de espera de keep alive de 60 segundos se configuró en el Message Processor y en el servidor backend. De forma similar, este problema también puede ocurrir si se configura un valor más alto para el tiempo de espera de keep alive en el mensaje más reciente que en el servidor de backend.

Diagnóstico

1. Si eres un usuario de la nube pública, ten en cuenta lo siguiente:
   1. Utiliza la herramienta Trace o Monitoring de API (como se explica en Pasos comunes del diagnóstico) y verifique que cumple con los siguientes dos requisitos: configuración:
      • Código de error: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Fuente del error: target
   2. Para obtener más información, ve a Cómo usar tcpdump.
2. Si eres un usuario de la nube privada, ten en cuenta lo siguiente:
   1. Usa la herramienta Trace o los registros de acceso de NGINX para determinar el ID del mensaje el código y la fuente del error 502.
   2. Busca el ID del mensaje en el registro de Message Processor.
      (/opt/apigee/var/log/edge-message-processor/logs/system.log)
   3. Verás el java.io.EOFEXception: eof unexpected como se muestra a continuación:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. El error java.io.EOFException: eof unexpected indica que El procesador de mensajes recibió un EOF mientras aún esperaba leer un respuesta del servidor de backend.
   5. El atributo useCount=7 en el mensaje de error anterior indica que el El procesador de mensajes volvió a usar esta conexión unas siete veces y el atributo bytesWritten=159 indica que Message Processor envió la solicitud de 159 bytes al servidor de backend. Sin embargo, recibió cero bytes cuando se produjo el EOF inesperado.

   6. Aquí se muestra que Message Processor volvió a usar la misma conexión varias veces y, en esta ocasión, envió datos, pero poco tiempo después recibió una EOF antes de recibir los datos. Esto significa que hay una alta probabilidad de que el backend que el tiempo de espera de keep alive del servidor sea menor o igual que el establecido en el proxy de API.

      Puedes investigar más a fondo con la ayuda de tcpdump, como se explica a continuación.

Cómo usar tcpdump

1. Captura un tcpdump en el servidor de backend con el siguiente comando:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Analiza el tcpdump capturado:

   Este es un resultado de tcpdump de muestra:

   

   En el tcpdump de muestra anterior, puedes ver lo siguiente:

   1. En el paquete 5992,, el servidor de backend recibió una solicitud GET.
   2. En el paquete 6064, responde con 200 OK..
   3. En el paquete 6084, el servidor de backend recibió otra solicitud GET.
   4. En el paquete 6154, responde con 200 OK.
   5. En el paquete 6228, el servidor de backend recibió una tercera solicitud GET.
   6. Esta vez, el servidor de backend muestra un FIN, ACK al Message Processor (paquete 6285) que inicia el cierre de la conexión.

   En este ejemplo, la misma conexión se reutilizó dos veces, pero en la tercera solicitud, el servidor de backend inicia un cierre de la conexión, mientras que Message Processor que espera los datos del servidor backend. Esto sugiere que la clave del servidor tiempo de espera de vida activa sea más corto o igual al valor establecido en el proxy de API. Para validar Consulta Comparación del tiempo de espera de keep alive en Apigee y el servidor de backend.

Compara el tiempo de espera de keep alive en Apigee y el servidor de backend

1. De forma predeterminada, Apigee usa un valor de 60 segundos para la propiedad de tiempo de espera de keep alive.

2. Sin embargo, es posible que haya anulado el valor predeterminado en el proxy de API. Para comprobarlo, revisa la definición de TargetEndpoint específica en el Proxy de API con fallas que arrojan errores 502.

   Ejemplo de configuración de TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   En el ejemplo anterior, la propiedad de tiempo de espera de mantenimiento de funcionamiento se anula con un valor de 30 segundos (30000 milisegundos).

3. A continuación, verifica la propiedad de tiempo de espera de keep alive configurada en tu servidor de backend. Digamos Tu servidor de backend está configurado con un valor de 25 seconds.
4. Si determinas que el valor de la propiedad de tiempo de espera de keep alive en Apigee es mayor que el valor de la propiedad de tiempo de espera de keep alive en el servidor de backend, como en el ejemplo anterior por ejemplo, esa es la causa de los errores 502.

Solución

Asegúrate de que la propiedad de tiempo de espera de keep alive sea siempre menor en Apigee (en el proxy de API y el componente Message Processor) en comparación con el del servidor de backend.

1. Determina el valor establecido para el tiempo de espera de keep alive en el servidor de backend.
2. Configura un valor adecuado para la propiedad de tiempo de espera keep alive en el proxy de API. Message Processor, de modo que la propiedad de tiempo de espera keep alive sea menor que el valor establecido en de backend, con los pasos que se describen en Configura el tiempo de espera de keep alive en los procesadores de mensajes.

Si el problema persiste, consulta Recopila información de diagnóstico.

Práctica recomendada

Se recomienda que los componentes downstream siempre tengan un tiempo de espera menor de keep alive que los configurados en los servidores ascendentes para evitar este tipo de condiciones de carrera y 502 de errores. Cada salto descendente debe ser menor que cada salto upstream. En Apigee Edge, se recomienda usar los siguientes lineamientos:

1. El tiempo de espera de mantenimiento activo del cliente debe ser menor que el del router perimetral.
2. El tiempo de espera de mantenimiento del router perimetral debe ser menor que el del procesador de mensajes.
3. El tiempo de espera de keep alive del procesador de mensajes debe ser menor que el tiempo de espera de keep alive del servidor de destino.
4. Si tienes otros saltos delante o detrás de Apigee, se debe aplicar la misma regla. Siempre debes dejar la responsabilidad del cliente downstream para cerrar la con el upstream.

Se debe recopilar información de diagnóstico

Si el problema persiste, incluso después de seguir las instrucciones anteriores, reúne la siguiente información de diagnóstico y, luego, comunícate con el equipo de 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
• Completa el comando curl para reproducir el error 502
• Archivo de registro que contiene las solicitudes con el error 502 Bad Gateway - Unexpected EOF
• Si los errores 502 no se producen actualmente, proporciona el período con la información de la zona horaria cuando se produjeron errores 502 en el pasado.

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

• Mensaje de error completo observado para las solicitudes fallidas
• Organización, nombre del entorno y nombre del proxy de API que está observando 502 de errores
• Paquete de proxy de API
• Archivo de registro que contiene las solicitudes con el error 502 Bad Gateway - Unexpected EOF
• Registros de acceso de NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Registros del procesador de mensajes
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• El período con la información de la zona horaria en el que se produjeron los errores 502
• Tcpdumps recopilados en los procesadores de mensajes o en el servidor backend, o en ambos cuando se produce ocurrió