Usar métricas de Cloud Load Balancing

En esta página se revisan los tipos de balanceadores de carga disponibles en Cloud Load Balancing y se describe cómo usar las métricas de Cloud Monitoring que exponen como indicadores de nivel de servicio.

Los servicios de Cloud Load Balancing suelen ser el primer punto de entrada de las aplicaciones alojadas en Google Cloud. Los balanceadores de carga se instrumentan automáticamente para proporcionar información sobre el tráfico, la disponibilidad y la latencia de los Google Cloud servicios que exponen. Por lo tanto, los balanceadores de carga suelen ser una fuente excelente de métricas de SLI sin necesidad de instrumentación de aplicaciones.

Al empezar, puede centrarse en la disponibilidad y la latencia como dimensiones principales de la fiabilidad y crear SLIs y SLOs para medir esas dimensiones y recibir alertas sobre ellas. En esta página se ofrecen ejemplos de implementación.

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

Indicadores y objetivos de nivel de servicio de disponibilidad

En el caso de las aplicaciones que no son UDP, el SLI de disponibilidad basado en solicitudes es el más adecuado, ya que las interacciones de servicio se corresponden con las solicitudes.

Para expresar un SLI de disponibilidad basado en solicitudes, usa la estructura TimeSeriesRatio para configurar una proporción de solicitudes correctas con respecto al total de solicitudes, tal como se muestra en los siguientes ejemplos de disponibilidad. Para llegar a la determinación que prefieras de "bueno" o "válido", filtra la métrica usando las etiquetas disponibles.

Balanceador de carga externo de capa 7 (HTTP/S)

Los balanceadores de carga HTTP/S se usan para exponer aplicaciones a las que se accede a través de HTTP/S y para distribuir el tráfico a recursos ubicados en varias regiones.

Los balanceadores de carga de aplicaciones externos escriben datos de métricas en Monitoring mediante el tipo de recurso monitorizado https_lb_rule y los tipos de métricas con el prefijo loadbalancing.googleapis.com. El tipo de métrica más relevante para los SLOs de disponibilidad es https/request_count, que puedes filtrar con la etiqueta de métrica response_code_class.

Si decides no contabilizar como "válidas" las solicitudes que dan como resultado un código de respuesta de error 4xx porque pueden indicar errores del cliente en lugar de errores del servicio o de la aplicación, puedes escribir el filtro de "total" de la siguiente manera:

"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 debe determinar cómo contabilizar las solicitudes "buenas". Por ejemplo, si quiere contabilizar solo las que devuelven un código de respuesta de estado correcto 200 OK, puede escribir el filtro de "buenas" de la siguiente manera:

"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\"",

A continuación, puedes expresar un indicador de nivel de servicio 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 las aplicaciones en las que el tráfico se sirve desde varios backends, puedes definir SLIs para un backend específico. Para crear un SLI de disponibilidad de 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 carga interno de capa 7 (HTTP/S)

Los balanceadores de carga de aplicación internos escriben datos de métricas en Monitoring mediante el tipo de recurso monitorizado internal_http_lb_rule y los tipos de métricas con el prefijo loadbalancing.googleapis.com. El tipo de métrica más relevante para los objetivos de nivel de servicio de disponibilidad es https/internal_request_count, que puede filtrar mediante la etiqueta de métrica response_code_class.

A continuación, se muestra un ejemplo de 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 carga de capa 3 (TCP)

Los balanceadores de carga TCP no proporcionan métricas de solicitudes porque las aplicaciones que los usan pueden no basarse en el modelo de solicitud-respuesta. Ninguna de las métricas de loadbalancing.googleapis.com que proporcionan estos balanceadores de carga se presta a buenos SLIs de disponibilidad.

Para crear indicadores de nivel de servicio de disponibilidad de estos balanceadores de carga, debe crear métricas personalizadas o basadas en registros. Para obtener más información, consulta Usar métricas personalizadas o Usar métricas basadas en registros.

Indicadores y objetivos de nivel de servicio de latencia

En el caso de las aplicaciones de solicitud-respuesta, hay dos formas de escribir SLOs de latencia:

  • Como los SLOs basados en solicitudes.
  • Como objetivos de nivel de servicio basados en periodos.

Objetivos de nivel de servicio de latencia basados en solicitudes

Un SLO basado en solicitudes aplica un umbral de latencia y cuenta la fracción de solicitudes que se completan por debajo del umbral en un periodo de cumplimiento determinado. Un ejemplo de SLO basado en solicitudes es "el 99% de las solicitudes se completan en menos de 100 ms en un periodo de una hora".

Para expresar un indicador de nivel de servicio de latencia basado en solicitudes, se usa una estructura DistributionCut, como se muestra en los siguientes ejemplos de latencia.

Un SLO basado en una sola solicitud no puede reflejar tanto el rendimiento habitual como la degradación de la experiencia del usuario, en la que las solicitudes más lentas o de la "cola" experimentan tiempos de respuesta cada vez más largos. Un SLO de rendimiento típico no permite comprender la latencia de cola. Para obtener más información sobre la latencia de cola, consulta la sección "Worrying About Your Tail" (Preocuparse por la cola) del capítulo 6: Monitoring Distributed Systems (Monitorización de sistemas distribuidos) del libro Site Reliability Engineering.

Para mitigar esta limitación, puedes escribir un segundo SLO que se centre específicamente en la latencia de cola.Por ejemplo, "el 99,9% de las solicitudes se completan en menos de 1000 ms en un periodo de 1 hora". La combinación de los dos SLOs registra las degradaciones tanto en la experiencia de usuario habitual como en la latencia de cola.

Objetivos de nivel de servicio de latencia basados en ventanas

Un objetivo de nivel de servicio basado en ventanas define un criterio de corrección para el periodo de tiempo de las mediciones y calcula la proporción de intervalos "correctos" con respecto al número total de intervalos. Un ejemplo de objetivo de nivel de servicio basado en periodos es "La métrica de latencia del percentil 95 es inferior a 100 ms en al menos el 99% de los periodos de un minuto, durante un periodo acumulado de 28 días":

  • Un periodo de medición "bueno" 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 esos periodos "buenos". El servicio cumple los requisitos si esta fracción es de al menos 0,99, calculada durante el periodo de cumplimiento.

Debes usar un SLO basado en periodos si la métrica sin procesar que tienes disponible es un percentil de latencia, es decir, cuando se cumplan las dos condiciones siguientes:

  • Los datos se agrupan en periodos (por ejemplo, en intervalos de un minuto).
  • Los datos se expresan en grupos de percentiles (por ejemplo, p50, p90, p95 y p99).

En este tipo de datos, cada grupo de percentiles 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 p95 de 89 ms indica que, durante ese minuto, el servicio respondió al 95% de las solicitudes en 89 ms o menos.

Balanceador de carga de aplicación externo

Los balanceadores de carga de aplicaciones externos usan los siguientes tipos de métricas principales para registrar la latencia:

  • https/total_latencies: distribución de la latencia calculada desde que el proxy recibe la solicitud hasta que el proxy recibe el ACK del cliente en el último byte de la respuesta. Úsala cuando la experiencia de usuario general sea lo más importante.

  • https/backend_latencies: distribución de la latencia calculada desde que el proxy envió la solicitud al backend hasta que el proxy recibió del backend el último byte de la respuesta. Se usa para medir las latencias de backends específicos que sirven tráfico detrás del balanceador de carga.

Estas métricas se escriben en el tipo de recurso monitorizado https_lb_rule.

Latencia total

Este ejemplo de SLO espera que el 99% de las solicitudes tengan una latencia total de entre 0 y 100 ms en un periodo continuo de una hora:

{
  "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

Este SLO de ejemplo espera que el 98% de las solicitudes al backend "my-app-backend" tengan una latencia de entre 0 y 100 ms en un periodo 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 carga de aplicación interno

Los balanceadores de carga de aplicaciones internos usan dos tipos de métricas principales para registrar la latencia:

  • https/internal/total_latencies: distribución de la latencia calculada desde que el proxy recibe la solicitud hasta que obtiene la confirmación del cliente sobre el último byte de la respuesta. Úsala cuando la experiencia de usuario general sea lo más importante.

  • https/internal/backend_latencies: distribución de la latencia calculada desde que el proxy envió la solicitud al backend hasta que el proxy recibió del backend el último byte de la respuesta. Se usa para medir las latencias de backends específicos que sirven tráfico detrás del balanceador de carga.

Estas métricas se escriben en el tipo de recurso monitorizado internal_http_lb_rule.

Latencia total

Este SLO de ejemplo espera que el 99% de las solicitudes tengan una latencia total de entre 0 y 100 ms en un periodo de una hora:

{
  "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 tengan una latencia total de entre 0 y 100 ms en un periodo continuo de una hora.

Latencia de backend

Este SLO espera que el 98% de las solicitudes al backend "my-internal-backend" tengan una latencia de entre 0 y 100 ms en un periodo de una hora:

{
  "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 carga externo de capa 3 (TCP)

Los balanceadores de carga 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 las conexiones TCP de los flujos del balanceador de carga externo.

Esta métrica se escribe en el recurso tcp_lb_rule.

Este SLO de ejemplo espera que el 99% de las solicitudes tengan una latencia total de entre 0 y 100 ms en un periodo de una hora:

{
  "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 carga interno de capa 3 (TCP)

Los balanceadores de carga 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 las conexiones TCP de los flujos del balanceador de carga interno.

Esta métrica se escribe en el recurso internal_tcp_lb_rule.

Este SLO de ejemplo espera que el 99% de las solicitudes tengan una latencia total de entre 0 y 100 ms en un periodo de una hora:

{
  "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"
}