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 relacionados con 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.

Identifica la fuente 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ó, consulta el campo statusDetails en Cloud Logging.

Si statusDetails es response_sent_by_backend, el balanceador de cargas retransmitió la respuesta 5XX del 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 la adición o eliminación de un servicio de backend, pueden dar como resultado un breve período en el que ves 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 relacionados con errores 5XX, verifica que tus backends estén en buen estado y que las verificaciones de estado se realicen correctamente. Si los backends no están en buen estado, el GFE de segunda capa no puede reenviarles solicitudes, lo que puede provocar 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, fallan las verificaciones de estado 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 superan, pero sigues viendo errores 5XX, consulta el campo statusDetails en Cloud Logging para identificar la fuente del error, como se describe en la siguiente sección.

Soluciona errores según `statusDetails`

Si persisten los errores HTTP 5XX, 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 Bad Gateway 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 para enrutar la solicitud. Este error puede ocurrir por uno de los siguientes motivos: Todas las regiones están en su capacidad máxima o por encima de ella. 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: Verifica que tus backends estén en buen estado siguiendo los pasos que se describen en Verifica el estado del backend. Asegúrate de que las verificaciones de estado estén configuradas correctamente con el puerto, la ruta y el protocolo adecuados. Asegúrate de que las reglas de firewall de backend permitan el tráfico de verificación de estado de 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 están restringidos 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, agota 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 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 del GFE que le impide conectarse al backend, o a una interrupción regional o una interrupción de la red (como un corte de fibra) que impide que los GFEs de primera capa se comuniquen con los GFEs 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, conexiones) para detectar signos 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 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 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 se quite el extremo del NEG. `T_drain` es el tiempo de espera del 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 que permite que el pod se apague 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 provocar el cierre de la conexión. Verifica las métricas de la instancia de backend (CPU, memoria, conexiones) para detectar signos de agotamiento de recursos.
`backend_timeout`	Causa: El GFE de segunda capa estableció una conexión con el backend, pero el backend 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 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 URL antes de volver a agregarlas, o bien debido a problemas transitorios internos de la red o la configuración de Google durante los lanzamientos o las propagaciones de configuración. Solución: Si usas la automatización, verifica que realice actualizaciones in situ en lugar de actualizaciones de eliminación y creación para las reglas de mapas de URL. 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 a nivel 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 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 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 publican el contenido del sitio web para los dominios en los que el gateway de la etiqueta de Google está activo. Para configurar esto en la consola, navega a Balanceo de cargas > Editar > Configuración de backend. Google Cloud Para obtener más información, consulta Cómo habilitar el registro en un servicio de backend existente. Se debe establecer una frecuencia de muestreo de registros 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 intervalo de tiempo para abarcar el período en el que sospechas que ocurrieron 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.
Examina el campo jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus para identificar posibles errores. 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, 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 la 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 en la extensión de la puerta de enlace de etiquetas de Google: Un grpcStatus que no sea OK (en especial, en el evento RESPONSE_BODY) significa que el proceso de inserción de etiquetas encontró un error. El código gRPC específico proporciona pistas (por ejemplo, DEADLINE_EXCEEDED indica un tiempo de espera agotado).
- Impacto en la solicitud del usuario: Si el grpcStatus de la extensión de la puerta de enlace de la etiqueta de Google no es OK, verifica httpRequest.status y jsonPayload.statusDetails en la misma entrada de registro. Por ejemplo, un grpcStatus que no es de 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 hizo que el usuario recibiera un error de servidor.
- Frecuencia del problema: 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 la documentación no puede resolver, 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.