Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Soluciona problemas de balanceadores de cargas de aplicaciones externos

En esta guía se describe cómo solucionar problemas de configuración de balanceadores de cargas de aplicaciones externos. Antes de analizar los problemas, familiarízate con las siguientes páginas:

Los backends tienen modos de balanceo incompatibles

Cuando creas un balanceador de cargas, es posible que veas el siguiente error:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Esto sucede cuando intentas usar el mismo backend en dos balanceadores de cargas diferentes y los backends no tienen modos de balanceo compatibles.

Para obtener más información, consulta lo siguiente:

Soluciona problemas generales de conectividad

Errores "5XX" sin motivo

Un GFE de primera capa, un GFE de segunda capa o un backend pueden devolver un error "HTTP 5XX", según dónde se produzca la condición de error.

En esta sección, se describe cómo solucionar problemas de errores 5XX que pueden ocurrir en diferentes etapas del proceso de distribución de solicitudes para balanceadores de cargas de aplicaciones externos basados en GFE.

Identificar el origen de los errores "5XX" con Cloud Logging

Para las condiciones de error causadas por un problema de comunicación entre el proxy del balanceador de cargas y sus backends, el balanceador de cargas genera un código de respuesta de error HTTP (5XX) y lo muestra al cliente. El balanceador de cargas no genera todos los errores HTTP . Por ejemplo, si un backend envía una respuesta HTTP 5XX al balanceador de cargas y el balanceador retransmite esa respuesta a su cliente.

Para determinar si una respuesta HTTP 5XX se retransmitió desde un backend o si el proxy del balanceador de cargas la generó, verifica el campo statusDetails en Cloud Logging.

Si statusDetails es response_sent_by_backend, el balanceador de cargas retransmitió la respuesta 5XX desde el backend. Soluciona el problema en tus backends.
Si statusDetails es cualquier otro mensaje de error, el balanceador de cargas genera la respuesta 5XX.

Los cambios de configuración en el balanceador de cargas de aplicaciones externo global, como agregar o quitar un servicio de backend, pueden generar un período breve en el que veas respuestas HTTP 502 con statusDetails como failed_to_pick_backend. Esto es normal durante la propagación de los cambios de configuración a los GFE a nivel global.

Antes de comenzar a solucionar problemas, verifica el estado del backend

Antes de solucionar problemas de errores 5XX, verifica que tus backends estén en buen estado y que las verificaciones de estado se aprueben. Si los backends no están en buen estado, el GFE de segunda capa no puede reenviarles solicitudes, lo que puede causar errores 5XX, incluso si todo lo demás está configurado correctamente.

Comprueba que haya una regla de firewall configurada para permitir verificaciones de estado. Si no hay una, las verificaciones de estado fallan y los registros del balanceador de cargas pueden mostrar un statusDetails de failed_to_pick_backend.
Verifica que el tráfico de verificación de estado llegue a tus VM de backend. Para ello, habilita el registro de verificación de estado y busca entradas de registro exitosas. En el caso de los balanceadores de cargas nuevos, es posible que no veas entradas de registro de verificación de estado correctas de inmediato. Esto podría deberse a que el estado inicial del backend aún no cambió de UNHEALTHY a un estado diferente. Verás entradas de registro de verificaciones de estado exitosas solo después de que el sistema de sondeo de verificación de estado reciba una respuesta HTTP 200 OK del backend.

Si las verificaciones de estado fallan, soluciona los problemas de tu aplicación de backend y las reglas de firewall. Si las verificaciones de estado se aprueban, pero aún ves errores 5XX, verifica el campo statusDetails en Cloud Logging para identificar el origen del error, como se describe en la siguiente sección.

Soluciona errores según `statusDetails`

Si los errores HTTP 5XX persisten, usa el campo statusDetails en Cloud Logging para identificar la causa y solucionar el problema según corresponda.

El balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones externo regional generan códigos de estado HTTP significativos, como HTTP 503 Service Unavailable y HTTP 504 Gateway Timeout.
El balanceador de cargas de aplicaciones clásico siempre usa el código de estado HTTP 502 de puerta de enlace incorrecta para todos los errores que genera el balanceador de cargas.

statusDetails	Posible causa y solución
`failed_to_pick_backend` `failed_to_pick_backend_by_hash`	Causa: El GFE de segunda capa no pudo seleccionar un backend en buen estado al que enrutar la solicitud. Este error puede ocurrir por uno de los siguientes motivos: Todas las regiones están al límite de su capacidad o la superaron. El balanceador de cargas no puede encontrar ningún backend disponible según el hash calculado. El balanceador de cargas no puede encontrar ningún backend que coincida con la configuración del servicio. Solución: Sigue los pasos que se indican en Verifica el estado del backend para comprobar que tus backends estén en buen estado. Asegúrate de que las verificaciones de estado estén configuradas de forma correcta con el puerto, la ruta de acceso y el protocolo adecuados. Asegúrate de que las reglas de firewall de backend permitan el tráfico de verificación de estado desde los sistemas de sondeo de verificación de estado `35.191.0.0/16`. Si tienes algunos grupos de instancias de backend en mal estado, ten en cuenta que la conmutación por error o el desbordamiento se restringen a una cantidad limitada de grupos de instancias alternativos. Si observas `failed_to_pick_backend` o `failed_to_pick_backend_by_hash` a pesar de tener grupos de instancias en buen estado, vacía los grupos de instancias en mal estado estableciendo su capacidad en cero. Esto obliga al balanceador de cargas a reenviar el tráfico a los grupos de instancias en buen estado.
`failed_to_connect_to_backend`	Causa: El GFE de la segunda capa no pudo establecer una conexión con una instancia de backend (no pudo obtener un SYN-ACK). Este error también puede deberse a un error interno de GFE que impide que se conecte al backend, o a una interrupción regional o de red (como un corte de fibra) que impide que los GFE de primera capa se comuniquen con los GFE de segunda capa. Solución: Verifica que las reglas de firewall en tus VMs de backend o en tu red de VPC permitan el tráfico a tus backends desde los rangos de GFE de segunda capa `35.191.0.0/16`. Verifica que la aplicación en tus instancias de backend se esté ejecutando y escuchando en el puerto configurado en el servicio de backend. Verifica las métricas de la instancia de backend (CPU, memoria y conexiones) para detectar indicios de agotamiento de recursos.
`backend_connection_closed_before_data_sent_to_client`	Causa: La conexión entre el GFE de segunda capa y el backend se cerró de forma inesperada antes de que se pudiera enviar la respuesta al cliente. Este problema puede deberse al servidor web de backend o a un dispositivo intermedio. También puede ocurrir cuando usas GKE si los Pods se reducen la escala verticalmente o finalizan, y los backends del balanceador de cargas son de tipo NEG. Solución: Establece el tiempo de espera de keepalive de HTTP en el servidor web de backend (como Apache o Nginx) para que sea mayor que el tiempo de espera de 600 segundos del balanceador de cargas. El valor recomendado es de 620 segundos. Si usas GKE, esto ocurre cuando los Pods se reducen verticalmente o finalizan, y los backends del balanceador de cargas son NEG. Para resolver este problema, considera aumentar `terminationGracePeriodSeconds` en la configuración de tu Pod o implementación para permitir que las conexiones existentes se cierren correctamente. El valor ideal es el siguiente: `T_grace > T_preStop + T_drain + T_buffer` Aquí: `T_preStop` es la duración de la suspensión del hook `preStop` del contenedor, que suele ser de 120 segundos para permitir que el extremo se quite del NEG. `T_drain` es el tiempo de espera para el vaciado de conexiones del servicio de backend, que suele ser de 60 segundos. `T_buffer` es un búfer adicional de 30 a 45 segundos para permitir que el Pod se cierre de forma segura. Para las configuraciones estándar, el valor recomendado es de al menos 210 segundos (3.5 minutos). Verifica los registros de la aplicación de backend para detectar errores que puedan causar el cierre de la conexión. Verifica las métricas de la instancia de backend (CPU, memoria y conexiones) para detectar indicios de agotamiento de recursos.
`backend_timeout`	Causa: El GFE de segunda capa estableció una conexión con el backend, pero este no envió una respuesta dentro del tiempo de espera del servicio de backend configurado. Solución: Si tu aplicación necesita más tiempo para procesar las solicitudes, aumenta el tiempo de espera del servicio de backend. Verifica si hay problemas de rendimiento en tus instancias de backend (CPU, E/S, retrasos de la aplicación) que puedan impedir una respuesta oportuna. Si los backends están sobrecargados, considera escalar los recursos de backend o optimizar la aplicación.
`retriable_error`	Causa: Este error 503 puede ocurrir si las herramientas de infraestructura como código (como Terraform) actualizan las reglas del balanceador de cargas de una manera que quita temporalmente las reglas del mapa de URLs antes de volver a agregarlas, o debido a problemas internos transitorios de red o configuración de Google durante los lanzamientos o las actualizaciones de configuración. Solución: Si usas la automatización, verifica que realice actualizaciones en el lugar en vez de actualizaciones de eliminación y creación para las reglas del mapa de URLs. Si ves este error durante o después de un cambio de configuración, es posible que sea transitorio. Espera unos minutos para que la configuración se propague de forma global.

Resuelve errores HTTP `408`

Con el tráfico HTTP, la cantidad máxima de tiempo para que el cliente complete el envío de su solicitud es igual al tiempo de espera del servicio de backend. Si ves respuestas HTTP 408 con jsonPayload.statusDetail client_timed_out, esto significa que no hubo un progreso suficiente mientras la solicitud del cliente o la respuesta del backend se envió a través de un proxy. Si el problema se debe a clientes que tienen problemas de rendimiento, puedes resolverlo con el aumento del tiempo de espera del servicio de backend.

El tráfico con balanceo de cargas no tiene la dirección de origen del cliente original

La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa de Google Cloud del balanceador de cargas. Los balanceadores de cargas basados en proxy, como los balanceadores de cargas de aplicaciones externos, usan dos conexiones TCP para transmitir el tráfico del cliente a los backends:

Conexión 1, desde el cliente original hasta el balanceador de cargas (GFE o subred de solo proxy)
Conexión 2, desde el balanceador de cargas (GFE o subred de solo proxy) hasta el extremo o la VM de backend

Las direcciones IP de origen y destino de cada conexión difieren según el tipo de balanceador de cargas de aplicaciones externo que uses. Para obtener más información, consulta Direcciones IP de origen de paquetes de clientes.

Aparece un error de permisos cuando intento ver un objeto en mi bucket de Cloud Storage

Para entregar objetos mediante el balanceo de cargas, los objetos de Cloud Storage deben ser de acceso público. Actualiza los permisos de los objetos que necesitas entregar para que puedan leerse de forma pública.

La URL no entrega el objeto de Cloud Storage esperado

El objeto de Cloud Storage que se entrega se determina en función de tu mapeo de URL y la URL que solicitas. Si la ruta de solicitud se mapea a un bucket de backend en tu mapeo de URL, el objeto de Cloud Storage se determina agregando la ruta completa de la solicitud al bucket de Cloud Storage especificado en el mapeo de URL.

Por ejemplo, si mapeas /static/* a gs://[EXAMPLE_BUCKET], la solicitud a https://<GCLB IP or Host>/static/path/to/content.jpg intentará entregar gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Si ese objeto no existe, aparecerá el siguiente mensaje de error en lugar del objeto:


NoSuchKey
The specified key does not exist.

La compresión no funciona

El balanceador de cargas de aplicaciones externo no comprime ni descomprime las respuestas, pero puede entregar respuestas generadas por el servicio de backend comprimidas mediante herramientas como gzip o DEFLATE.

Si las respuestas que entrega el balanceador de cargas no están comprimidas, pero deberían estarlo, verifica si el software del servidor web que se ejecuta en tus instancias está configurado para comprimir las respuestas. De forma predeterminada, hay software de servidor web que inhabilita la compresión para las solicitudes que incluyen un encabezado Via, lo que indica que la solicitud se reenvió mediante un proxy. Dado que es un proxy, el balanceador de cargas de aplicaciones externo agrega un encabezado Via a cada solicitud según se requiere en la especificación HTTP. A fin de habilitar la compresión, es posible que tengas que anular la configuración predeterminada del servidor web para indicarle que comprima las respuestas, incluso si la solicitud tiene un encabezado Via.

Si deseas configurar los backends de NGINX para que entreguen respuestas comprimidas mediante un proxy a través de un balanceador de cargas de aplicaciones externo, haz lo siguiente:

Establece la directiva gzip_proxied de manera correcta (por ejemplo, como any).
También, establece la directiva gzip_vary como on.

Si deseas configurar los backends Apache para que entreguen respuestas comprimidas mediante un proxy a través de un balanceador de cargas de aplicaciones externo, haz lo siguiente:

Usa el filtro DEFLATE.
También, agrega Vary Accept-Encoding al encabezado de respuesta con el módulo mod_headers.

Solucionar problemas de backends en mal estado

Soluciona problemas de HTTP/2 en los backends

Asegúrate de que tu instancia de backend esté en buen estado y sea compatible con el protocolo HTTP/2. Para verificar esto, prueba la conectividad a la instancia de backend mediante HTTP/2. Cerciórate de que la VM utilice conjuntos de cifrado HTTP/2 que cumplan con las especificaciones. Por ejemplo, HTTP/2 no permite determinados conjuntos de cifrado de TLS 1.2. Consulta la lista negra de conjuntos de cifrado de TLS 1.2.

Una vez que hayas verificado que la VM utiliza el protocolo HTTP/2, asegúrate de que la configuración de tu firewall permita el paso del verificador de estado y el balanceador de cargas.

Si no hay problemas con la configuración del firewall, asegúrate de que el balanceador de cargas esté configurado para comunicarse con el puerto correcto de la VM.

Soluciona problemas de interrupciones de conexión para clientes que operan detrás de una NAT de nivel de operador

Cuando un cliente se conecta a un balanceador de cargas de aplicaciones externo a través de un dispositivo con estado intermedio, como una NAT de nivel de operador (CGNAT), la CGNAT hace un seguimiento de cada conexión TCP activa en una tabla de estado. Muchos CGNAT aplican un tiempo de espera de inactividad corto, más corto que el tiempo de espera de keepalive de HTTP del cliente del balanceador de cargas (610 segundos de forma predeterminada) y el tiempo de espera de conexión inactiva en el grupo de conexiones HTTP del cliente.

Si una conexión permanece inactiva durante más tiempo que el tiempo de espera de inactividad de CGNAT, CGNAT quita de forma silenciosa la entrada de conexión de su tabla de estado sin enviar un paquete TCP FIN o RST a ninguno de los extremos. Debido a que tanto el cliente como el balanceador de cargas aún consideran que la conexión está abierta, el CGNAT descarta o rechaza la siguiente solicitud HTTP que el cliente envía a través de esa conexión, lo que hace que la solicitud falle.

Para evitar que se interrumpan las conexiones de forma silenciosa para los clientes que operan detrás de CGNAT o de otros dispositivos con estado, realiza una de las siguientes acciones:

Reduce el tiempo de espera de conexión inactiva en el grupo de conexiones de tu cliente HTTP a un valor más corto que el tiempo de espera de inactividad de CGNAT y el tiempo de espera de keepalive de HTTP del cliente del balanceador de cargas para que el cliente cierre las conexiones inactivas de forma correcta antes de que venza el estado de NAT.
Configura keepalives a nivel de la aplicación (como marcos PING de HTTP/2 periódicos) en un intervalo más corto que el tiempo de espera de inactividad de CGNAT (pero al menos 30 segundos entre marcos PING en conexiones inactivas para evitar la límite de frecuencia). Si bien los marcos PING de HTTP/2 no restablecen el tiempo de espera de keepalive de HTTP del cliente del balanceador de cargas cuando no hay transmisiones activas, mantienen activa la asignación de NAT intermediaria para que la conexión siga siendo válida o se pueda cerrar de forma correcta.
Reduce el intervalo de keepalive de TCP del sistema operativo del cliente (por ejemplo, net.ipv4.tcp_keepalive_time en Linux) a un valor más corto que el tiempo de espera de inactividad de CGNAT, de modo que los sondeos de TCP salientes periódicos eviten que se agote el tiempo de espera de la asignación de NAT. Ten en cuenta que los sondeos de keepalive de TCP se procesan en la capa de transporte y no restablecen el tiempo de espera de keepalive de HTTP del cliente del balanceador de cargas.

Soluciona problemas de NEG de Internet y backend externo

Antes de analizar los problemas, familiarízate con las siguientes páginas:

El tráfico no llega a los extremos

Después de configurar un servicio, se puede acceder al extremo nuevo mediante el balanceador de cargas de aplicaciones externo en estas situaciones:

El extremo está conectado a NEG de Internet.
El FQDN asociado puede resolverse con DNS de forma adecuada (si usas el tipo de extremo FQDN).
Se puede acceder al extremo a través de Internet.

Si el tráfico no puede llegar al extremo, y se genera un código de error 502, consulta el registro TXT _cloud-eoips.googleusercontent.com del DNS con una herramienta como dig o nslookup. Toma nota de los CIDR (después de ip4:) y asegúrate de que se permitan esos rangos en el firewall o la lista de control de acceso (LCA) en la nube.

Después de configurar un backend externo, las solicitudes al backend externo fallaron con un error 5xx.

Comprueba Logging.
Verifica que el grupo de extremos de red esté configurado con la IP:Puerto o el FQDN:Puerto correcto para tu backend externo.
Si usas un FQDN, asegúrate de que se pueda resolver a través del DNS público de Google. Puedes verificar que el FQDN se pueda resolver a través del DNS público de Google mediante estos pasos o directamente desde la interfaz web.
Si accedes al balanceador de cargas de HTTP(S) solo en su IP externa, y tu servidor web de origen espera un nombre de host, asegúrate de enviar un encabezado HTTP de host válido a tu backend mediante la configuración de un encabezado de solicitud personalizado.
Si te comunicas con un backend mediante HTTPS o HTTP2 (como se establece en el campo protocol del servicio de backend) configurado como un extremo de backend externo INTERNET_FQDN_PORT, asegúrate de que tu origen presente un certificado TLS (SSL) válido y que el FQDN configurado coincida con un SAN (nombre alternativo del asunto) en la lista de SAN de los certificados. Un certificado válido se define como uno firmado por una autoridad certificada pública que no esté vencido.
Cuando se usan extremos de backend externos INTERNET_FQDN_PORT, el balanceador de cargas de HTTPS no acepta los certificados autofirmados y estos se rechazan.
Cuando se usa HTTPS o HTTP/2 con extremos de tipo INTERNET_IP_PORT, no se realiza ninguna validación de certificado SSL o verificación de SAN. Esto significa que se pueden usar certificados autofirmados. Cuando se usa SSL, nuestra recomendación es usar extremos INTERNET_FQDN_PORT para asegurarnos de que los certificados de servidor y los SAN se puedan validar.

Soluciona problemas relacionados con la inserción de la puerta de enlace de etiquetas de Google

La puerta de enlace de etiquetas de Google no inserta las etiquetas correctamente o genera errores.

Para resolver este problema, usa el Explorador de registros de la consola de Google Cloud para analizar los registros que genera tu balanceador de cargas. Los problemas de la puerta de enlace de etiquetas de Google no afectan el código de respuesta HTTP general ni el statusDetails de la solicitud de la página web. La respuesta HTTP se enviará sin modificaciones, incluso si falla la inserción de la etiqueta de Google. Para identificar los errores de la puerta de enlace, verifica el grpcStatus de la ejecución del complemento en la carga útil de JSON de tu balanceador de cargas.

Asegúrate de que Cloud Logging esté habilitado en los servicios de backend que entregan el contenido del sitio web para los dominios en los que la puerta de enlace de Google Tag está activa. Configura esto en la consola de Google Cloud navegando a Balanceo de cargas > Editar > Configuración de backend. Para obtener más información, consulta Habilita el registro en un servicio de backend existente. Se debe establecer una tasa de muestreo de registro superior a 0.0 para ese servicio de backend.

En la consola de Google Cloud , ve a la página Explorador de registros y selecciona el proyecto correcto.

Ve al Explorador de registros
Ajusta el período para que abarque el momento en el que sospechas que se produjeron los problemas. Para obtener más información, consulta Cómo usar el selector de período.
Para ver los registros de las solicitudes que controla el complemento de inserción de la puerta de enlace de etiquetas de Google, usa esta consulta:
```
resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"
```
Reemplaza PROJECT_ID con el ID del proyecto.
Identifica posibles errores examinando el campo jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Aquí se muestra el estado de la extensión de la puerta de enlace de etiquetas de Google.
- OK: La extensión completó su procesamiento sin un error de gRPC.
- Cualquier valor que no sea OK (por ejemplo, INTERNAL, UNAVAILABLE o DEADLINE_EXCEEDED): Indica un error en la ejecución de la extensión de la puerta de enlace de etiquetas de Google.

Para encontrar registros en los que la extensión de puerta de enlace de etiquetas de Google informó un error, usa la siguiente consulta:

resource.type="http_load_balancer" logName="projects/PROJECT_IDlogs/requests" \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway" NOT jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus="OK"

Cuando la consulta anterior devuelva resultados, examina toda la entrada de registro para correlacionar el estado de la extensión con el resultado de la solicitud:
- Falla de la extensión de la puerta de enlace de etiquetas de Google: Un grpcStatus que no sea OK (especialmente en el evento RESPONSE_BODY) significa que el proceso de inserción de etiquetas encontró un error. El código de gRPC específico proporciona pistas (por ejemplo, DEADLINE_EXCEEDED indica un tiempo de espera).
- Impacto en la solicitud del usuario: Si el grpcStatus de la extensión de puerta de enlace de la etiqueta de Google no es OK, verifica el httpRequest.status y el jsonPayload.statusDetails en la misma entrada de registro. Por ejemplo, un grpcStatus que no sea OK combinado con httpRequest.status: 500 y jsonPayload.statusDetails: service_extensions_error sugiere que la falla de la extensión de la puerta de enlace de etiquetas de Google provocó que el usuario recibiera un error de servidor.
- Frecuencia de los problemas: Analizar las marcas de tiempo y la frecuencia de estos registros de errores ayuda a determinar si los problemas de inserción de la puerta de enlace de etiquetas de Google son continuos, intermitentes o están vinculados a eventos específicos.

Si tienes problemas durante la configuración que no se pueden resolver con la documentación, comunícate con el equipo de Asistencia de Google Ads.

Soluciona problemas de balanceadores de cargas de aplicaciones externos Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.