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 de tráfico del balanceador de cargas para que se base en métricas específicas de los requisitos de tu aplicación o infraestructura, en lugar de las métricas de uso estándar o basadas en la tasa de Google Cloud. Definir métricas personalizadas para tu balanceador de cargas te brinda la flexibilidad para enrutar las solicitudes de la aplicación a las instancias y los extremos de backend que sean más óptimos para tu carga de trabajo.

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

Selecciona qué grupo de instancias de VM de backend o grupo de extremos de red debe recibir el tráfico.
Selecciona qué instancia de VM o extremo debe recibir tráfico

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

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

Maximiza el uso de tu capacidad de procesamiento global tomando decisiones de balanceo de cargas según las 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 tengan latencias de procesamiento de backend de segundos, puedes usar tu capacidad de procesamiento global de manera más eficiente si balanceas las cargas en función de métricas personalizadas en lugar de la latencia de red.
Maximiza la eficiencia del procesamiento tomando decisiones de balanceo de cargas en función de combinaciones de métricas únicas para tu implementación. Por ejemplo, imagina una situación en la que tus solicitudes tienen tiempos de procesamiento y requisitos de procesamiento muy variables. En tal caso, el balanceo de cargas basado únicamente en la tasa de solicitudes por segundo generaría una distribución de carga desigual. En ese caso, te recomendamos que definas una métrica personalizada que equilibre la carga en función de una combinación de la tasa de solicitudes y el uso de CPU o GPU para usar tu flota de procesamiento de manera más eficiente.
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 escalar automáticamente tus instancias de backend cuando tu métrica personalizada configurada supere el 80%. Esto se logra mediante el uso de métricas de ajuste de escala automático basado 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 son compatibles 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 de tráfico según 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 deseas usar, configura tus backends para que comiencen a informar un flujo constante de estas métricas a tu balanceador de cargas. Google Cloud 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 agregación de costos de solicitudes abiertas (ORCA).

Las métricas se pueden configurar en dos niveles:

En el nivel del backend, para influir en la selección del backend (MIG o NEG)
A nivel del servicio de 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 deben influir en las decisiones de balanceo de cargas

Determinar qué métricas personalizadas deben influir en las decisiones de balanceo de cargas es muy subjetivo y se basa en las necesidades de tus aplicaciones. Por ejemplo, si tus aplicaciones tienen latencias de procesamiento de backend del orden de segundos, te recomendamos que balances las cargas de las solicitudes en función de otras métricas personalizadas en lugar de las latencias de red estándar.

Una vez que hayas determinado qué métricas deseas usar, también debes determinar el umbral de utilización máximo para cada métrica. Por ejemplo, si quieres 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 uso 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 que informa el backend por debajo de 0.8, en la medida de lo posible.

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

Métricas reservadas. Hay 5 nombres de métricas reservados, que se reservan porque 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
Métricas con nombre: Son métricas únicas 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.

Métricas obligatorias

Para permitir que el balanceador de cargas use métricas personalizadas para el grupo de instancias de VM de backend o la selección de grupos de extremos de red, debes especificar al menos una de las siguientes métricas de utilización de la siguiente lista en el informe de carga de ORCA que se envía al balanceador de cargas:

orca.cpu_utilization o
orca.application_utilization o
orca.mem_utilization o
orca.named_metrics, que es un mapa de métricas definidas por el usuario en forma de pares nombre-valor.

Además, para permitir que el 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 pesos calculados a partir de estas métricas informadas para asignar cargas a backends individuales.

orca.rps_fractional (solicitudes por segundo)
orca.eps (errores por segundo) y
una métrica de uso con el siguiente orden de prioridad:
- orca.application_utilization
- orca.cpu_utilization
- métricas definidas por el usuario en el mapa orca.named_metrics

Notas adicionales:

Hay un límite de 2 métricas personalizadas por backend. Sin embargo, puedes realizar pruebas dryRun con un máximo de 3 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 trata de forma independiente. Si un backend se ejecuta a un nivel de uso alto en términos de custom-metric-util1, el balanceador de cargas evita enviar tráfico a este backend. Por lo general, el balanceador de cargas intenta mantener todos los backends en ejecución con aproximadamente la misma carga. La plenitud se calcula como currentUtilization / maxUtilization. En este caso, el balanceador de cargas usa el valor más alto de los dos valores de nivel de carga que informan las dos métricas para tomar decisiones de balanceo de cargas.
Existe un límite de 2 métricas personalizadas por servicio de backend. Sin embargo, puedes realizar pruebas dryRun con un máximo de 3 métricas personalizadas. Este límite no incluye las métricas orca.eps y orca.rps_fractional obligatorias. 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, se puede proporcionar orca.cpu_utilization = 0.5 y una métrica personalizada, como orca.named_metrics.queue_depth_util = 0.2, en un solo informe de carga.
Los nombres de las métricas personalizadas no deben contener información regulada, sensible, de identificación ni cualquier otra información confidencial que no deba ver ninguna persona externa a tu organización.

Codificación disponible para la especificación de métricas personalizadas

JSON

Codificación JSON de muestra 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, este es un protobuf OrcaLoadReport serializado binario 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 con 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, configurarás tu backend para compilar las métricas personalizadas requeridas en un informe de carga de ORCA y registrar 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 paquete que se envía al balanceador de cargas. 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 de distribución de tráfico, debes establecer el modo de balanceo de cada backend en CUSTOM_METRICS y la política de localidad de 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 informar. Si se configuran varias métricas personalizadas por backend, el balanceador de cargas intenta distribuir el tráfico de modo que todas las métricas permanezcan por debajo de los límites de utilización máximos 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 la misma carga.
Política de balanceo de cargas de la localidad de WEIGHTED_ROUND_ROBIN. La política de localidad de 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.

Cómo configurar métricas personalizadas

Seguirás los pasos que se indican a continuación para permitir que los balanceadores de cargas de aplicaciones tomen decisiones de balanceo de cargas según métricas personalizadas:

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 las decisiones de balanceo de cargas. Estas métricas deben compilarse y codificarse en un informe de carga de ORCA y, luego, informarse al balanceador de cargas mediante encabezados de respuesta HTTP.
Configura 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 según las necesidades de tus propias aplicaciones. Una vez que hayas determinado qué métricas deseas usar, también debes determinar el umbral de utilización máximo para cada métrica. Por ejemplo, si quieres 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 continuar con la configuración del 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 en la sección Cómo funcionan las métricas personalizadas.

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 mediante el estándar ORCA. En esta sección, se muestra cómo compilar las métricas personalizadas en un informe de carga de ORCA y generar informes de estas métricas en cada encabezado de respuesta HTTP que se envía al balanceador de cargas.

Por ejemplo, si usas 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.

Este es un fragmento de código en el que se 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 base64. Ten en cuenta que, en este ejemplo, los valores de customUtilA y customUtilB se codifican de forma fija solo para simplificar. Tu balanceador de cargas debe recibir los valores de las métricas que determinaste que deben influir 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 selecciones un backend, debes configurar 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, configura la política de localidad de 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 lo agregas 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_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 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 muestra en la sección Configura backends para que informen métricas al balanceador de cargas), usarás el siguiente comando para configurar el 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 las métricas se informan sin afectar al 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 se configura una métrica con dryRun establecido en true, la métrica se informa a Monitoring, pero el balanceador de cargas no la usa.

Para revertir esto, actualiza el servicio de backend con la marca dryRun set a 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 tendrá 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 para que use las métricas personalizadas para influir en la selección de extremos, establece 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, configura 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.