Es posible que parte de la información de esta página (o toda) no se aplique a Cloud de Confiance de S3NS. Consulta Diferencias con Google Cloud para obtener más detalles.

Se usó la API de Cloud Translation para traducir esta página.

Métricas personalizadas para balanceadores de cargas de aplicaciones

En esta página, se describe cómo usar métricas personalizadas con tus balanceadores de cargas de aplicaciones. Las métricas personalizadas te permiten configurar el comportamiento de distribución del tráfico de tu balanceador de cargas en función de métricas específicas para los requisitos de tu aplicación o infraestructura, en lugar de las métricas estándar de utilización o basadas en la tasa de Cloud de Confiance. Definir métricas personalizadas para tu balanceador de cargas te brinda la flexibilidad de enrutar las solicitudes de aplicaciones a las instancias y los extremos de backend que son más óptimos para tu carga de trabajo.

En el caso de GKE, también puedes usar métricas personalizadas que provienen del servicio o la aplicación que ejecutas. Para obtener más detalles, consulta Cómo exponer métricas personalizadas.

El balanceador de cargas usa los valores de las métricas personalizadas para tomar las siguientes decisiones:

Selecciona qué grupo de instancias de máquina virtual (VM) o grupo de extremos de red del backend recibirá tráfico.
Selecciona qué instancia de VM o extremo recibirá tráfico.

Balanceo de cargas con métricas personalizadas (haz clic para ampliar)

Estos son algunos ejemplos de casos de uso de las métricas personalizadas:

Maximiza el uso de tu capacidad de procesamiento global tomando decisiones de balanceo de cargas basadas en métricas personalizadas que sean más relevantes para tu aplicación, en lugar de los criterios predeterminados, como la afinidad regional o la latencia de red.

En caso de que tus aplicaciones suelan tener latencias de procesamiento de backend del orden de segundos, puedes usar tu capacidad de procesamiento global de manera más eficiente balanceando las solicitudes según métricas personalizadas en lugar de la latencia de red.
Maximiza la eficiencia de procesamiento tomando decisiones de balanceo de cargas basadas en combinaciones de métricas exclusivas de tu implementación. Por ejemplo, considera una situación en la que tus solicitudes tienen tiempos de procesamiento y requisitos de procesamiento muy variables. En este caso, el balanceo de cargas basado únicamente en la tasa de solicitudes por segundo genera una distribución de carga desigual. En ese caso, tal vez quieras definir una métrica personalizada que equilibre la carga en función de una combinación de la tasa de solicitudes y el uso de la CPU o la GPU para usar tu flota de procesamiento de la manera más eficiente posible.
Ajusta automáticamente la escala de los backends según las métricas personalizadas que sean más relevantes para los requisitos de tu aplicación. Por ejemplo, puedes definir una política de ajuste de escala automático para ajustar automáticamente la escala de tus instancias de backend cuando la métrica personalizada configurada supere el 80%. Esto se logra con métricas de ajuste de escala automático basadas en el tráfico (autoscaling.googleapis.com|gclb-capacity-fullness). Para obtener más información, consulta Ajuste de escala automático basado en el tráfico del balanceador de cargas.

Balanceadores de cargas y backends compatibles

Las métricas personalizadas son compatibles con los siguientes balanceadores de cargas de aplicaciones:

Balanceador de cargas de aplicaciones externo global
Balanceador de cargas de aplicaciones externo regional
Balanceador de cargas de aplicaciones interno entre regiones
Balanceador de cargas de aplicaciones interno regional

Las métricas personalizadas se admiten con los siguientes tipos de backend:

Grupos de instancias administrados
NEG zonales (con extremos GCE_VM_IP_PORT)
NEG de conectividad híbrida

Cómo funcionan las métricas personalizadas

Para permitir que tu balanceador de cargas tome decisiones de distribución del tráfico basadas en métricas personalizadas, primero debes determinar cuáles son las métricas más relevantes para tu aplicación específica. Cuando sepas qué métricas quieres usar, configura tus backends para que comiencen a informar un flujo constante de estas métricas a tu balanceador de cargas. Cloud de Confiance te permite informar métricas como parte del encabezado de cada respuesta HTTP que se envía desde los backends a tu balanceador de cargas. Estas métricas se encapsulan en un encabezado de respuesta HTTP personalizado y deben seguir el estándar de Open Request Cost Aggregation (ORCA).

Las métricas se pueden configurar en dos niveles:

A nivel del servicio de backend, para influir en la selección del backend (MIG o NEG)
A nivel del backend, para influir en la selección de instancias de VM o extremos

En las siguientes secciones, se describe cómo funcionan las métricas personalizadas.

Determina qué métricas personalizadas influyen en las decisiones de balanceo de cargas

Determinar qué métricas personalizadas influyen en las decisiones de balanceo de cargas es muy subjetivo y depende de las necesidades de tus aplicaciones. Por ejemplo, si tus aplicaciones tienen latencias de procesamiento de backend del orden de segundos, es posible que desees balancear las solicitudes de carga en función de otras métricas personalizadas en lugar de las latencias de red estándar.

Después de determinar qué métricas deseas usar, también debes determinar el umbral máximo de utilización para cada métrica. Por ejemplo, si deseas usar el uso de memoria como métrica, también debes determinar el umbral máximo de uso de memoria para cada backend.

Por ejemplo, si configuras una métrica llamada example-custom-metric, con su umbral de utilización máximo establecido en 0.8, el balanceador de cargas ajusta de forma dinámica la distribución del tráfico entre los backends para mantener la métrica example-custom-metric informada por el backend en menos de 0.8, en la medida de lo posible.

Existen dos tipos de métricas personalizadas que puedes usar:

Métricas reservadas. Hay cinco nombres de métricas reservados, ya que corresponden a campos predefinidos de nivel superior en la API de ORCA.
- orca.cpu_utilization
- orca.mem_utilization
- orca.application_utilization
- orca.eps
- orca.rps_fractional
Las métricas mem_utilization, cpu_utilization y application_utilization esperan valores en el rango de 0.0 - 1.00, pero pueden superar 1.00 en situaciones en las que el uso de recursos supera el presupuesto.
Métricas con nombre. Son métricas exclusivas de tu aplicación que especificas con el campo named_metrics de ORCA en el siguiente formato:
```
orca.named_metrics.METRIC_NAME
```
Todas las métricas personalizadas definidas por el usuario se especifican con este mapa named_metrics en el formato de pares nombre-valor.

Las métricas con nombre definidas para el modo de balanceo CUSTOM_METRICS deben incluir valores en el rango de 0 - 100. Las métricas con nombre definidas para la política de localidad de balanceo de cargas WEIGHTED_ROUND_ROBIN no tienen un rango esperado.

Métricas obligatorias

Para habilitar tu balanceador de cargas para que use métricas personalizadas en la selección de grupos de instancias de VM de backend o grupos de extremos de red, debes especificar una o más de las siguientes métricas de utilización en el informe de carga de ORCA que se envía al balanceador de cargas. orca.named_metrics es un mapa de métricas definidas por el usuario en forma de pares nombre-valor.

orca.cpu_utilization
orca.application_utilization
orca.mem_utilization
orca.named_metrics

Además, para permitir que tu balanceador de cargas use métricas personalizadas para influir aún más en la selección de la instancia o el extremo de la VM de backend, debes proporcionar todas las siguientes métricas en el informe de carga de ORCA que se envía al balanceador de cargas. El balanceador de cargas usa los pesos calculados a partir de estas métricas informadas para asignar carga a los backends individuales.

orca.rps_fractional (solicitudes por segundo)
orca.eps (errores por segundo)
Una métrica de uso con el siguiente orden de prioridad:
1. orca.application_utilization
2. orca.cpu_utilization
3. Métricas definidas por el usuario en el mapa de orca.named_metrics

Límites y requisitos

Hay un límite de dos métricas personalizadas por backend. Sin embargo, puedes realizar pruebas de dryRun con un máximo de tres métricas personalizadas.

Si se proporcionan dos métricas, el balanceador de cargas las trata de forma independiente. Por ejemplo, si defines dos dimensiones: custom-metric-util1 y custom-metric-util2, el balanceador de cargas las tratará de forma independiente. Si un backend se ejecuta con un nivel de uso alto en términos de custom-metric-util1, el balanceador de cargas evita enviar tráfico a este backend. En general, el balanceador de cargas intenta mantener todos los backends en ejecución con aproximadamente el mismo nivel de carga. La plenitud se calcula como currentUtilization / maxUtilization. En este caso, el balanceador de cargas usa el mayor de los dos valores de plenitud que informan las dos métricas para tomar decisiones de balanceo de cargas.
Hay un límite de dos métricas personalizadas por servicio de backend. Sin embargo, puedes realizar pruebas de dryRun con un máximo de tres métricas personalizadas. Este límite no incluye las métricas obligatorias orca.eps y orca.rps_fractional. Este límite también es independiente de las métricas configuradas a nivel del backend.
Las métricas reservadas y las métricas con nombre se pueden usar juntas. Por ejemplo, tanto orca.cpu_utilization = 0.5 como una métrica personalizada, como orca.named_metrics.queue_depth_util = 0.2, se pueden proporcionar en un solo informe de carga.
Los nombres de las métricas personalizadas no deben contener información regulada, sensible, identificable ni ningún otro tipo de información confidencial que no deba ver ninguna persona ajena a tu organización.

Codificaciones disponibles para la especificación de métricas personalizadas

JSON

Ejemplo de codificación JSON de un informe de carga:

endpoint-load-metrics-json: JSON {"cpu_utilization": 0.3, "mem_utilization": 0.8, "rps_fractional": 10.0, "eps": 1, "named_metrics": {"custom-metric-util": 0.4}}.

Protobuf binario

Para el código compatible con Protocol Buffers, se trata de un protobuf de OrcaLoadReport serializado de forma binaria y codificado en base64 en endpoint-load-metrics-bin o en endpoint-load-metrics: BIN.
HTTP nativo

Pares clave-valor separados por comas en endpoint-load-metrics. Esta es una representación de texto aplanada del OrcaLoadReport:
```
endpoint-load-metrics: TEXT cpu_utilization=0.3, mem_utilization=0.8, rps_fractional=10.0, eps=1, named_metrics.custom_metric_util=0.4
```
gRPC

La especificación de gRPC requiere que las métricas se proporcionen con metadatos finales que usen la clave endpoint-load-metrics-bin.

Configuración del backend para informar métricas personalizadas

Después de determinar las métricas que deseas que use el balanceador de cargas, configura tus backends para que compilen las métricas personalizadas requeridas en un informe de carga de ORCA y registren sus valores en cada encabezado de respuesta HTTP que se envíe al balanceador de cargas.

Por ejemplo, si elegiste orca.cpu_utilization como métrica personalizada para un backend, ese backend debe informar el uso actual de la CPU al balanceador de cargas en cada respuesta que se le envíe. Para obtener instrucciones, consulta la sección Cómo informar métricas al balanceador de cargas en esta página.

Configuración del balanceador de cargas para admitir métricas personalizadas

Para permitir que el balanceador de cargas use los valores de métricas personalizadas que informan los backends para tomar decisiones sobre la distribución del tráfico, debes establecer el modo de balanceo de cada backend en CUSTOM_METRICS y la política de localidad del balanceo de cargas del servicio de backend en WEIGHTED_ROUND_ROBIN.

Cómo funcionan las métricas personalizadas con los balanceadores de cargas de aplicaciones (haz clic para ampliar).

Modo de balanceo CUSTOM_METRICS. Cada uno de tus backends en un servicio de backend debe configurarse para usar el modo de balanceo CUSTOM_METRICS. Cuando un backend se configura con el modo de balanceo CUSTOM_METRICS, el balanceador de cargas dirige el tráfico a los backends según el umbral de utilización máximo configurado para cada métrica personalizada.

Cada backend puede especificar un conjunto diferente de métricas para generar informes. Si se configuran varias métricas personalizadas por backend, el balanceador de cargas intenta distribuir el tráfico de manera que todas las métricas permanezcan por debajo de los límites máximos de utilización configurados.

El tráfico se balancea entre los backends según el algoritmo de balanceo de cargas que elijas. Por ejemplo, el algoritmo WATERFALL_BY_REGION predeterminado intenta mantener todos los backends en ejecución con el mismo nivel de carga.
WEIGHTED_ROUND_ROBIN política de balanceo de cargas de la localidad. La política de localidad del balanceo de cargas del servicio de backend debe establecerse en WEIGHTED_ROUND_ROBIN. Con esta configuración, el balanceador de cargas también usa las métricas personalizadas para seleccionar la instancia o el extremo óptimos dentro del backend para entregar la solicitud.

Configura métricas personalizadas

Para habilitar tus balanceadores de cargas de aplicaciones para que usen métricas personalizadas, haz lo siguiente:

Determina las métricas personalizadas que deseas usar.
Configura los backends para que informen métricas personalizadas al balanceador de cargas. Debes establecer un flujo de datos que se pueda enviar al balanceador de cargas para que se use en el balanceo de cargas. Estas métricas deben compilarse y codificarse en un informe de carga de ORCA, y luego informarse al balanceador de cargas a través de los encabezados de respuesta HTTP.
Configurar el balanceador de cargas para que use los valores de métricas personalizadas que informan los backends

Determina las métricas personalizadas

Este paso es muy subjetivo y depende de las necesidades de tus aplicaciones. Después de determinar qué métricas deseas usar, también debes determinar el umbral máximo de utilización para cada métrica. Por ejemplo, si deseas usar el uso de memoria como métrica, también debes determinar el umbral máximo de uso de memoria para cada backend.

Antes de configurar el balanceador de cargas, asegúrate de haber revisado los tipos de métricas personalizadas disponibles (reservadas y con nombre) y los requisitos para la selección de métricas, que se describen en la sección Cómo funcionan las métricas personalizadas de esta página.

Configura los backends para que informen métricas al balanceador de cargas

Las métricas personalizadas se informan a los balanceadores de cargas como parte de cada respuesta HTTP de los backends de tu aplicación a través del estándar de ORCA.

Cuando usas Google Kubernetes Engine, también tienes la opción de usar métricas personalizadas para los balanceadores de cargas.

En esta sección, se muestra cómo compilar las métricas personalizadas en un informe de carga de ORCA y cómo informar estas métricas en cada encabezado de respuesta HTTP que se envía al balanceador de cargas.

Por ejemplo, si usas la codificación de texto HTTP, el encabezado debe informar las métricas en el siguiente formato.

endpoint-load-metrics: TEXT BACKEND_METRIC_NAME_1=BACKEND_METRIC_VALUE_1,BACKEND_METRIC_NAME_2=BACKEND_METRIC_VALUE_2

Independientemente del formato de codificación que se use, asegúrate de quitar el prefijo orca. del nombre de la métrica cuando compiles el informe de carga.

A continuación, se incluye un fragmento de código que muestra cómo agregar dos métricas personalizadas (customUtilA y customUtilB) a tus encabezados HTTP. Este fragmento de código muestra la codificación de texto HTTP nativa y la codificación en base64. Ten en cuenta que este ejemplo codifica de forma rígida los valores de customUtilA y customUtilB solo para simplificar. Tu balanceador de cargas recibe los valores de las métricas que determinaste que influyen en el balanceo de cargas.

...
type OrcaReportType int

const (
        OrcaText OrcaReportType = iota
        OrcaBin
)

type HttpHeader struct {
        key   string
        value string
}

const (
        customUtilA = 0.2
        customUtilB = 0.4
)

func GetBinOrcaReport() HttpHeader {
        report := &pb.OrcaLoadReport{
                NamedMetrics: map[string]float64{"customUtilA": customUtilA, "customUtilB": customUtilB}}
        out, err := proto.Marshal(report)
        if err != nil {
                log.Fatalf("failed to serialize the ORCA proto: %v", err)
        }
        return HttpHeader{"endpoint-load-metrics-bin", base64.StdEncoding.EncodeToString(out)}
}

func GetHttpOrcaReport() HttpHeader {
        return HttpHeader{
                "endpoint-load-metrics",
                fmt.Sprintf("TEXT named_metrics.customUtilA=%.2f,named_metrics.customUtilB=%.2f",
                        customUtilA, customUtilB)}
}

func GetOrcaReport(t OrcaReportType) HttpHeader {
        switch t {
        case OrcaText:
                return GetHttpOrcaReport()
        case OrcaBin:
                return GetBinOrcaReport()
        default:
                return HttpHeader{"", ""}
        }
}
...

Configura el balanceador de cargas para que use métricas personalizadas

Para que el balanceador de cargas use estas métricas personalizadas cuando seleccione un backend, debes establecer el modo de balanceo de cada backend en CUSTOM_METRICS. Además, si deseas que las métricas personalizadas también influyan en la selección de extremos, debes establecer la política de localidad del balanceo de cargas en WEIGHTED_ROUND_ROBIN.

En los pasos que se describen en esta sección, se supone que ya implementaste un balanceador de cargas con backends de NEG zonales. Sin embargo, puedes usar las mismas marcas --custom-metrics que se muestran aquí para actualizar cualquier backend existente con el comando gcloud compute backend-services update.

Puedes establecer el modo de balanceo de un backend en CUSTOM_METRICS cuando agregues el backend al servicio de backend. Usas la marca --custom-metrics para especificar tu métrica personalizada y el umbral que se usará para las decisiones de balanceo de cargas.
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    [--global | region=REGION] \
    --balancing-mode=CUSTOM_METRICS \
    --custom-metrics='name="BACKEND_METRIC_NAME_1",maxUtilization=MAX_UTILIZATION_FOR_METRIC_1' \
    --custom-metrics='name="BACKEND_METRIC_NAME_2",maxUtilization=MAX_UTILIZATION_FOR_METRIC_2'
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: es el nombre del servicio de backend.
- NEG_NAME: El nombre del NEG híbrido o zonal
- NEG_ZONE: Es la zona en la que se creó el NEG.
- REGION: Para los balanceadores de cargas regionales, es la región en la que se creó el balanceador de cargas.
- BACKEND_METRIC_NAME: Los nombres de las métricas personalizadas que se usan aquí deben coincidir con los nombres de las métricas personalizadas que informa el informe de ORCA del backend.
- MAX_UTILIZATION_FOR_METRIC: Es el uso máximo al que deben apuntar los algoritmos de balanceo de cargas para cada métrica.
Por ejemplo, si tus backends registran dos métricas personalizadas, customUtilA y customUtilB (como se demostró en la sección Configura los backends para que registren métricas en el balanceador de cargas), usa el siguiente comando para configurar tu balanceador de cargas para que use estas métricas:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    [--global | region=REGION] \
    --balancing-mode=CUSTOM_METRICS \
    --custom-metrics='name="customUtilA",maxUtilization=0.8' \
    --custom-metrics='name="customUtilB",maxUtilization=0.9'
```
Como alternativa, puedes proporcionar una lista de métricas personalizadas en un archivo JSON estructurado:
```
{
"name": "METRIC_NAME_1",
"maxUtilization": MAX_UTILIZATION_FOR_METRIC_1,
"dryRun": true
}
{
"name": "METRIC_NAME_2",
"maxUtilization": MAX_UTILIZATION_FOR_METRIC_2,
"dryRun": false
}
```
Luego, adjunta el archivo de métricas en formato JSON al backend de la siguiente manera:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    [--global | region=REGION] \
    --balancing-mode=CUSTOM_METRICS \
    --custom-metrics-file='BACKEND_METRIC_FILE_NAME'
```
Si quieres probar si se registran las métricas sin afectar realmente el balanceador de cargas, puedes establecer la marca dryRun en true cuando configures la métrica de la siguiente manera:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    [--global | region=REGION] \
    --balancing-mode=CUSTOM_METRICS \
    --custom-metrics 'name="BACKEND_METRIC_NAME",maxUtilization=MAX_UTILIZATION_FOR_METRIC,dryRun=true'
```
Cuando una métrica se configura con dryRun establecida en true, se informa a Monitoring, pero el balanceador de cargas no la usa.

Para revertir esto, actualiza el servicio de backend con la marca dryRun establecida en false.
```
gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    [--global | region=REGION] \
    --balancing-mode=CUSTOM_METRICS \
    --custom-metrics 'name="BACKEND_METRIC_NAME",maxUtilization=MAX_UTILIZATION_FOR_METRIC_,dryRun=false'
```
Si todas tus métricas personalizadas están configuradas con dryRun establecido en true, establecer el modo de balanceo en CUSTOM_METRICS o la política de localidad del balanceo de cargas en WEIGHTED_ROUND_ROBIN no tiene ningún efecto en el balanceador de cargas.

Nota: Para ver otras marcas compatibles con el comando gcloud compute backend-services update-backend, como --clear-custom-metrics, consulta la página de referencia de gcloud compute backend-services update-backend.
Para configurar el balanceador de cargas de modo que use las métricas personalizadas para influir en la selección de extremos, debes establecer la política de localidad de balanceo de cargas del servicio de backend en WEIGHTED_ROUND_ROBIN.

Por ejemplo, si tienes un servicio de backend que ya está configurado con los backends adecuados, puedes configurar la política de localidad de balanceo de cargas de la siguiente manera:
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    [--global | region=REGION] \
    --custom-metrics='name=BACKEND_SERVICE_METRIC_NAME,dryRun=false' \
    --locality-lb-policy=WEIGHTED_ROUND_ROBIN
```
Como se demostró anteriormente para las métricas a nivel del backend, también puedes proporcionar una lista de métricas personalizadas en un archivo JSON estructurado a nivel del servicio de backend. Usa el campo --custom-metrics-file para adjuntar el archivo de métricas al servicio de backend.