En esta página, se revisan los tipos de balanceadores de cargas disponibles en Cloud Load Balancing y se describe cómo usar las métricas de Cloud Monitoring que exponen como SLI.
Los servicios de Cloud Load Balancing a menudo proporcionan el primer punto de entrada para las aplicaciones alojadas en Google Cloud. Los balanceadores de cargas se instrumentan de forma automática para proporcionar información sobre el tráfico, la disponibilidad y la latencia de los servicios de Google Cloud que exponen. Por lo tanto, los balanceadores de cargas suelen actuar como una excelente fuente de métricas de SLI sin la necesidad de instrumentación de aplicaciones.
Cuando comiences, puedes elegir enfocarte en la disponibilidad y la latencia como las dimensiones principales de confiabilidad y crear SLI y SLO para medir y generar alertas sobre esas dimensiones. En esta página, se proporcionan ejemplos de implementación.
Para obtener información adicional, consulta las siguientes secciones:
- Conceptos de la supervisión del servicio
- Documentación de Cloud Load Balancing
- Lista de tipos de métricas de
loadbalancing.googleapis.com
SLI y SLO de disponibilidad
En las aplicaciones que no son UDP, un SLI de disponibilidad basado en solicitudes es el más apropiado, ya que las interacciones de servicio se asignan perfectamente a las solicitudes.
Debes expresar un SLI de disponibilidad basado en solicitudes mediante el uso de la estructura TimeSeriesRatio para configurar una proporción de solicitudes exitosas y totales, como se muestra en los siguientes ejemplos de disponibilidad.
Para llegar a la determinación preferida de “adecuada” o “válida”, debes filtrar la métrica con sus etiquetas disponibles.
Balanceador de cargas de la capa externa 7 (HTTP/S)
Los balanceadores de cargas HTTP/S se usan para exponer las aplicaciones a las que se accede a través de HTTP/S y distribuir el tráfico hacia los recursos ubicados en varias regiones.
Los balanceadores de cargas de aplicaciones externos escriben datos de métricas en Monitoring con
el tipo de recurso supervisado
https_lb_rule y los tipos de métricas con el prefijo
loadbalancing.googleapis.com. El tipo de métrica más
pertinente para los SLO de disponibilidad es
https/request_count, por el que
puedes filtrar usando la etiqueta de métrica response_code_class.
Si decides no contar esas solicitudes que generan un código de respuesta de error 4xx como “válido” porque pueden indicar errores de cliente, en lugar de errores de servicio o de aplicación, puedes escribir el filtro de “total”, como esta:
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
También debes determinar cómo contar las solicitudes "buenas". Por ejemplo, si eliges contar solo a aquellos que muestran un código de respuesta de estado de éxito OK 200, puedes escribir el filtro para “adecuada” como se muestra a continuación:
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
Luego, puedes expresar un SLI basado en solicitudes de la siguiente manera:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
En aplicaciones en las que varios backends entregan el tráfico, puedes elegir definir los SLI para un backend específico. Si quieres crear un SLI de disponibilidad para un
backend específico, usa la métrica
https/backend_request_count
con la etiqueta de recurso backend_target_name en tus filtros,
como se muestra en este ejemplo:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
Balanceador de cargas de capa interna 7 (HTTP/S)
El balanceador de cargas de aplicaciones interno escribe los datos de las métricas en Monitoring con el tipo de recurso supervisado internal_http_lb_rule y los tipos de métricas con el prefijo loadbalancing.googleapis.com. El tipo de métrica más
pertinente para los SLO de disponibilidad es
https/internal_request_count,
por el que puedes filtrar usando la etiqueta de métrica response_code_class.
A continuación, se muestra un ejemplo de un SLI de disponibilidad basado en solicitudes:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Balanceadores de cargas de capa 3 (TCP)
Los balanceadores de cargas TCP no proporcionan métricas de solicitud porque las aplicaciones que las usan pueden no estar basadas en el modelo de solicitud y respuesta. Ninguna de las métricas de loadbalancing.googleapis.com proporcionadas por estos balanceadores de cargas ofrece las desventajas a los SLI de buena disponibilidad.
Si deseas crear SLI de disponibilidad para estos balanceadores de cargas, debes crear métricas personalizadas o basadas en registros. Si buscas más información, consulta Usa métricas personalizadas o Usa métricas basadas en registros.
SLI y SLO de latencia
Hay dos formas de escribir SLO de latencia para las aplicaciones de solicitud y respuesta:
- Como los SLO basados en solicitudes
- Como los SLO basados en ventanas
SLO de latencia basados en solicitudes
Un SLO basado en solicitudes aplica un límite de latencia y cuenta la fracción de solicitudes que se completan dentro del límite dentro de un período de cumplimiento determinado. Un ejemplo de un SLO basado en solicitudes es del “99% de las solicitudes completadas en menos de 100 ms dentro de una ventana de una hora progresiva”.
Expresas un SLI de latencia basado en solicitudes con una estructura DistributionCut, como se muestra en los siguientes ejemplos de latencia.
Un solo SLO basado en solicitudes no puede capturar el rendimiento típico y la degradación de la experiencia del usuario, en la que las solicitudes en “cola” o “más lentas” ven tiempos de respuesta cada vez más extensos. Un SLO para el rendimiento típico no admite la comprensión de la latencia final. Si buscas un análisis sobre la latencia final, consulta la sección "Preocupaciones relacionadas con la latencia final" en el Capítulo 6: Supervisión de sistemas distribuidos del libro Ingeniería de confiabilidad de sitios.
A fin de mitigar esta limitación, puedes escribir un segundo SLO para enfocarte en la latencia final, por ejemplo, “99,9% de solicitudes completadas en menos de 1,000 ms durante un período progresivo de 1 hora”. La combinación de las dos capturas de pantalla de ambos SLO disminuye en la experiencia del usuario típica y en la latencia final.
SLO de latencia basados en ventanas
Un SLO basado en una ventana define un criterio de calidad para el período y calcula la proporción de intervalos de “adecuado” a la cantidad total de intervalos. Un ejemplo de un SLO basado en ventanas es “La métrica de latencia del percentil 95 es inferior a 100 ms durante, al menos, el 99% de las ventanas de un minuto, en un período progresivo de 28 días”:
- Un período de medición “adecuada” es un intervalo de un minuto en el que el 95% de las solicitudes tienen una latencia inferior a 100 ms.
- La medida de cumplimiento es la fracción de dichos períodos "adecuados". El servicio cumple con los requisitos si esta fracción es de al menos 0.99 y se calcula durante el período de cumplimiento.
Debes usar un SLO basado en ventana si la métrica sin procesar disponible es un percentil de latencia. Es decir, cuando se cumplen las siguientes condiciones:
- Los datos se agrupan en períodos (por ejemplo, en intervalos de un minuto).
- Los datos se expresan en grupos de percentiles (por ejemplo, p50, p90, p95 y p99).
Para este tipo de datos, cada grupo percentil indica el tiempo que divide los grupos de datos por encima y por debajo de ese percentil. Por ejemplo, un intervalo de un minuto con una métrica de latencia de p95 de 89 ms indica que, durante ese minuto, el servicio respondió al 95% de las solicitudes en 89 ms o menos.
Balanceador de cargas de aplicaciones externo
Los balanceadores de cargas de aplicaciones externos usan los siguientes tipos de métricas principales para capturar la latencia:
https/total_latencies: Una distribución de la latencia que se calcula desde que el proxy recibió la solicitud hasta que obtuvo la confirmación del cliente en el último byte de respuesta. Se usa cuando la experiencia general del usuario es de suma importancia.https/backend_latencies: Una distribución de la latencia que se calcula desde que el proxy envió la solicitud al backend hasta que el proxy recibió del backend el último byte de respuesta. Se usa para medir las latencias de backends específicos que entregan tráfico detrás del balanceador de cargas.
Estas métricas se escriben con el tipo de recurso supervisado
https_lb_rule.
Latencia total
Este SLO de ejemplo espera que el 99% de las solicitudes caigan entre 0 y 100 ms en latencia total en un período de una hora progresiva:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Latencia de backend
En este SLO de ejemplo, se espera que el 98% de las solicitudes al objetivo del backend “my-app-backend” estén entre 0 y 100 ms en latencia durante un período progresivo de una hora:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Balanceador de cargas de aplicaciones interno
Los balanceadores de cargas de aplicaciones internos usan dos tipos de métricas principales para capturar la latencia:
https/internal/total_latencies: Una distribución de la latencia que se calcula desde que el proxy recibió la solicitud hasta que obtuvo la confirmación del cliente en el último byte de respuesta. Se usa cuando la experiencia general del usuario es de suma importancia.https/internal/backend_latencies: Una distribución de la latencia que se calcula desde que el proxy envió la solicitud al backend hasta que el proxy recibió del backend el último byte de respuesta. Se usa para medir las latencias de backends específicos que entregan tráfico detrás del balanceador de cargas.
Estas métricas se escriben con el tipo de recurso supervisado
internal_http_lb_rule.
Latencia total
Este SLO de ejemplo espera que el 99% de las solicitudes caigan entre 0 y 100 ms en latencia total en un período de una hora progresiva:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Este SLO de ejemplo espera que el 99% de las solicitudes caigan entre 0 y 100 ms en latencia total en un período de una hora progresiva:
Latencia de backend
En este SLO de ejemplo, se espera que el 98% de las solicitudes al objetivo del backend “my-internal-backend” se encuentren entre 0 y 100 ms en latencia durante un período de una hora progresiva:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Balanceador de cargas de capa externa 3 (TCP)
Los balanceadores de cargas TCP externos usan un solo tipo de métrica, l3/external/rtt_latencies, que registra la distribución del tiempo de ida y vuelta medido en conexiones TCP para los flujos del balanceador de cargas externo.
Esta métrica se escribe con el recurso
tcp_lb_rule.
Este SLO de ejemplo espera que el 99% de las solicitudes caigan entre 0 y 100 ms en latencia total en un período de una hora progresiva:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Balanceador de cargas de capa interna 3 (TCP)
Los balanceadores de cargas TCP internos usan un solo tipo de métrica, l3/internal/rtt_latencies, que registra la distribución del tiempo de ida y vuelta medido en conexiones TCP para los flujos de balanceadores de cargas internos.
Esta métrica se escribe con el recurso
internal_tcp_lb_rule.
Este SLO de ejemplo espera que el 99% de las solicitudes caigan entre 0 y 100 ms en latencia total en un período de una hora progresiva:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}