El seguimiento distribuido para los balanceadores de cargas de aplicaciones proporciona visibilidad de extremo a extremo de las solicitudes a medida que viajan desde tus clientes, a través del balanceador de cargas y hasta tus servicios de backend.
Cloud Load Balancing se integra en Cloud Trace para generar intervalos de seguimiento de las solicitudes que procesa el balanceador de cargas. Debido a que el balanceador de cargas es el punto de entrada para el tráfico de tu aplicación, iniciar y propagar el contexto de seguimiento en el balanceador de cargas garantiza la visibilidad de diagnóstico en toda la ruta de la solicitud. Puedes usar estos seguimientos para identificar cuellos de botella de latencia, aislar saltos con errores y solucionar problemas en arquitecturas de varios niveles.
El balanceador de cargas genera seguimientos que cumplen con los estándares abiertos (contexto de seguimiento de W3C y OpenTelemetry). Los servicios de backend que se instrumentan con OpenTelemetry pueden continuar el seguimiento que inicia el balanceador de cargas.
Ventajas clave
El seguimiento distribuido con Cloud Trace proporciona los siguientes beneficios:
- Visibilidad de solicitudes de extremo a extremo: Realiza un seguimiento de la ruta de acceso de una solicitud en los balanceadores de cargas de aplicaciones internos y externos, y en los servicios de backend a los que enrutan el tráfico.
- Observabilidad perimetral: Captura intervalos de seguimiento en la regla de reenvío, antes de que el balanceador de cargas seleccione un backend, para que puedas ver los errores perimetrales y la latencia que la instrumentación del backend no puede detectar.
- Configuración de telemetría desacoplada: Define la configuración de seguimiento en
recursos
TelemetryPolicyindependientes sin cambiar la configuración de enrutamiento de tu balanceador de cargas. - Correlación de telemetría cruzada: Correlaciona los intervalos de seguimiento con los registros de solicitudes de Cloud Load Balancing y las métricas de Cloud Monitoring para identificar dónde se originan la latencia o los errores.
Balanceadores de cargas compatibles
En la siguiente tabla, se enumeran los balanceadores de cargas que admiten el seguimiento distribuido y los modos de muestreo que admite cada balanceador de cargas:
| Balanceador de cargas | Esquema de balanceo de cargas | Muestreo probabilístico | Muestreo basado en el elemento superior |
|---|---|---|---|
| Balanceador de cargas de aplicaciones externo global | EXTERNAL_MANAGED |
||
| Balanceador de cargas de aplicaciones externo regional | EXTERNAL_MANAGED |
||
| Balanceador de cargas de aplicaciones interno regional | INTERNAL_MANAGED |
||
| Balanceador de cargas de aplicaciones interno entre regiones | INTERNAL_MANAGED |
Los balanceadores de cargas de aplicaciones clásicos no admiten el seguimiento distribuido.
Cómo funciona el seguimiento distribuido
Para configurar el seguimiento distribuido, crea un recurso TelemetryPolicy en
la API de Network Services. Una política de telemetría especifica lo siguiente:
- Destinos: Son las reglas de reenvío de los balanceadores de cargas de los que deseas realizar un seguimiento.
- Configuración de seguimiento: Es la configuración de muestreo que determina qué solicitudes sigue el balanceador de cargas.
Cuando llega una solicitud a una regla de reenvío a la que se orienta una política de telemetría,
el balanceador de cargas decide si se debe muestrear la solicitud. Si se muestrea la solicitud,
el balanceador de cargas genera un intervalo de seguimiento, lo envía a
Cloud Trace y propaga el contexto de seguimiento al backend en el
encabezado de la solicitud traceparent de W3C.
Adjunto de regla de reenvío
Las políticas de telemetría se orientan a la regla de reenvío del balanceador de cargas, que representa el frontend del balanceador de cargas. Si se adjunta el seguimiento en la regla de reenvío, el balanceador de cargas puede hacer un seguimiento de todo el tráfico que ingresa a una dirección IP virtual (VIP) y un puerto, incluidas las solicitudes que fallan antes de que el balanceador de cargas seleccione un backend.
Las políticas de telemetría tienen las siguientes características:
- Ciclo de vida independiente: Las políticas de telemetría son independientes de los servicios de backend, los mapas de URLs y los proxies de destino. Puedes crear, modificar o borrar una política de telemetría sin cambiar la forma en que el balanceador de cargas enruta el tráfico.
- Reutilizable en varios frontends: Una sola política de telemetría puede orientarse a varias reglas de reenvío, por lo que puedes aplicar parámetros de configuración de seguimiento coherentes en varios frontends de balanceador de cargas.
- Permiso de ubicación: Crea una política de telemetría en la ubicación
globalpara orientar las reglas de reenvío globales, como las que usan los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones internos entre regiones. Crea una política de telemetría en una región para orientar las reglas de reenvío regionales en esa región, como las que usan los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales.
Modos de muestreo
El seguimiento distribuido admite los siguientes modos de muestreo. Para obtener más información sobre los modos de muestreo que admite cada balanceador de cargas, consulta Balanceadores de cargas compatibles en este documento.
- Muestreo probabilístico: El balanceador de cargas toma muestras de una proporción fija de
solicitudes, que estableces en el campo
samplingRate. Por ejemplo, un valor de0.01toma muestras del 1% de las solicitudes. El muestreo probabilístico es compatible con todos los balanceadores de cargas admitidos. Muestreo basado en el elemento superior: El balanceador de cargas respeta la decisión de muestreo en el encabezado
traceparententrante de un cliente o servicio ascendente. Configura el muestreo basado en el elemento superior en el campoparentBasedSampling. El muestreo basado en el elemento superior solo se admite en los balanceadores de cargas de aplicaciones internos.Cuando habilitas el muestreo basado en el elemento superior, el balanceador de cargas controla las solicitudes de la siguiente manera:
- Si el encabezado
traceparententrante tiene configurada la marca de muestreo, el balanceador de cargas muestrea la solicitud con la frecuencia especificada en el campoparentBasedSampling.samplingRate. Por ejemplo, establece este campo en1.0para hacer un seguimiento de todas las solicitudes que ya muestreó un servicio ascendente. - Si el encabezado
traceparententrante no tiene configurada la marca de muestreo, el balanceador de cargas no muestrea la solicitud. Este comportamiento respeta la decisión ascendente y sigue la especificación de OpenTelemetry, que evita que aparezcan seguimientos desconectados en Cloud Trace. - Si la solicitud no incluye un encabezado
traceparent, el balanceador de cargas aplica elsamplingRatede referencia.
- Si el encabezado
Control de encabezados de contexto de seguimiento
El balanceador de cargas controla el encabezado traceparent de W3C de la siguiente manera:
- El seguimiento no está habilitado o no se toma una muestra de la solicitud: El balanceador de cargas
reenvía el encabezado
traceparententrante al backend sin cambios. - La solicitud se muestrea y no incluye un encabezado
traceparent: El balanceador de cargas genera un ID de seguimiento y un ID de intervalo nuevos, y establece las marcas de seguimiento en03(aleatorio y muestreado). - La solicitud se muestrea y se incluye un encabezado
traceparent: El balanceador de cargas conserva el ID de seguimiento entrante y la marca aleatoria, genera un ID de intervalo nuevo y establece la marca de muestreo.
Los servicios de backend que usan un SDK de OpenTelemetry con el propagador de contexto de seguimiento de W3C
leen automáticamente el encabezado traceparent y continúan el seguimiento.
Para obtener más información, consulta
Contexto de seguimiento.
Casos de uso habituales
En esta sección, se describen situaciones comunes para el seguimiento distribuido.
Supervisa el perímetro de la tienda
Una tienda de comercio electrónico usa un balanceador de cargas de aplicaciones externo global para recibir el tráfico
de los clientes. Para supervisar la latencia perimetral y los errores, como las respuestas 404 y las fallas de TLS,
adjuntas una política de telemetría con muestreo probabilístico a la
regla de reenvío de la tienda. Una tasa de muestreo baja, como 0.01 (1%), mantiene
predecibles los costos de transferencia de Cloud Trace durante los eventos de tráfico máximo.
Mantener la continuidad de los seguimientos en los servicios de confirmación de la compra
Las solicitudes de confirmación de la compra viajan desde la tienda a través de un balanceador de cargas de aplicaciones interno hasta
los servicios internos de carrito, inventario y pago. Para asegurarte de que las solicitudes de confirmación de la compra
muestreadas en la tienda se tracen en cada salto interno, habilitas el muestreo basado en el elemento superior en el balanceador de cargas interno con un
parentBasedSampling.samplingRate de 1.0. El tráfico interno de rutina que
no lleva una decisión de muestreo ascendente se muestrea en el valor de referencia
samplingRate.
Aislar los cuellos de botella de latencia
Cuando aumenta la latencia de confirmación de la compra o aumentan los errores 5xx, comparas los intervalos del balanceador de cargas
en Cloud Trace con los registros de solicitudes y las métricas de latencia
del balanceador de cargas. Esta comparación te ayuda a determinar si el problema se origina en el
borde del balanceador de cargas, en un salto del balanceador de cargas interno o en un servicio de backend.
Precios
El balanceador de cargas no cobra por generar intervalos de seguimiento. Sin embargo, Cloud Trace cobra por la transferencia de intervalos de seguimiento según los precios de Cloud Trace.
Para administrar los costos de transferencia de las cargas de trabajo de producción con mucho tráfico, recomendamos un
samplingRate de 0.01 (1%) o 0.001 (0.1%).
Limitaciones
Durante la versión preliminar, el seguimiento distribuido para los balanceadores de cargas de aplicaciones tiene las siguientes limitaciones:
- El muestreo basado en el elemento superior no es compatible con los balanceadores de cargas de aplicaciones externos.
- No se admiten los atributos de intervalo personalizados.
- No puedes configurar el seguimiento distribuido con la API de Gateway de Google Kubernetes Engine ni Terraform.
- Una sola política de telemetría puede orientarse a un máximo de 50 recursos.
Seguimiento distribuido para Agent Gateway
Si usas Agent Gateway para administrar el tráfico de los agentes de IA, consulta Supervisa el tráfico a través de Agent Gateway para obtener información sobre la supervisión del tráfico de los agentes.