Administra métricas de GKE

Google Kubernetes Engine (GKE) facilita el envío de métricas a Cloud Monitoring. Cuando estén en Cloud Monitoring, las métricas pueden propagar paneles personalizados, generar alertas, crear objetivos de nivel de servicio, o los servicios de supervisión de terceros los recuperan mediante la API de Monitoring.

GKE proporciona varias fuentes de métricas:

Métricas del sistema: métricas de componentes esenciales del sistema, que describen recursos de bajo nivel, como CPU, memoria y almacenamiento.
El servicio administrado para Prometheus: te permite supervisar y crear alertas en tus cargas de trabajo mediante Prometheus, sin tener que administrar y operar de forma manual Prometheus a gran escala.
Métricas del plano de control: métricas exportadas desde ciertos componentes del plano de control como el servidor de la API y el programador.
Métricas de cargas de trabajo: métricas expuestas por cualquier carga de trabajo de GKE (como un CronJob o una implementación para una aplicación).

Métricas del sistema

De forma predeterminada, GKE recopila ciertas métricas emitidas por los componentes del sistema cuando se crea un clúster.

Tienes la opción de enviar métricas desde tu clúster de GKE a Cloud Monitoring. Si eliges enviar métricas a Cloud Monitoring, debes enviar métricas del sistema.

Todas las métricas del sistema de GKE se transfieren a Cloud Monitoring con el prefijo kubernetes.io.

Precios

Cloud Monitoring no cobra por la transferencia de las métricas del sistema de GKE. Obtén más información sobre los precios de Cloud Monitoring.

Configura la recopilación de métricas del sistema

Para habilitar la recopilación de métricas del sistema, pasa el valor SYSTEM a la marca --monitoring de los comandos gcloud container clusters create o gcloud container clusters update.

Para inhabilitar la recopilación de métricas del sistema, usa el valor NONE en la marca --monitoring. Si la recopilación de métricas del sistema está inhabilitada, la información básica como el uso de CPU, memoria y disco no está disponible para un clúster en la sección GKE de la consola de Google Cloud. Además, el panel de GKE de Cloud Monitoring no contiene información sobre el clúster.

Consulta Configura Cloud Operations para GKE a fin de obtener más detalles sobre la integración de Cloud Monitoring con GKE.

Lista de métricas del sistema

Las métricas del sistema incluyen métricas de componentes esenciales del sistema que son importantes para la funcionalidad principal de Kubernetes. Consulta una lista completa de las métricas del sistema.

Métricas del plano de control

Puedes configurar un clúster de G K E para enviar ciertas métricas emitidas por el servidor de la API de Kubernetes, Scheduler y el Administrador de controladores a Cloud Monitoring.

Requisitos

Para enviar métricas emitidas por los componentes del plano de control de Kubernetes a Cloud Monitoring, se requiere la versión 1.23.6 o posterior del plano de control de G K E y se requiere que la recopilación de métricas del sistema esté habilitada.

Configura la recopilación de métricas del plano de control

Para habilitar las métricas del plano de control de Kubernetes en un clúster de G K E existente, sigue estos pasos:

CONSOLE

En la consola de Google Cloud, ve a la lista de clústeres de GKE.

Ir a Clústeres de Kubernetes
Haz clic en el nombre del clúster.
En la fila etiquetada Cloud Monitoring, haz clic en el ícono Editar.
En el cuadro de diálogo Editar Cloud Monitoring que aparecerá, confirma que esté seleccionada la opción Habilitar Cloud Monitoring.
En el menú desplegable Componentes, selecciona los componentes del plano de control del que deseas recopilar métricas: Servidor de la API, Programador o Administrador de controladores.
Haga clic en OK.
Haz clic en Save Changes.

GCLOUD

Abre una ventana de la terminal con el SDK de Google Cloud y Google Cloud CLI instalada. Una forma de hacerlo es mediante Cloud Shell:
En la consola, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Pasa uno o más de los valores API_SERVER, SCHEDULER o CONTROLLER_MANAGER a la marca --monitoring de los comandos gcloud container clusters create o gcloud container clusters update.

Por ejemplo, para recopilar métricas del servidor de la API, del programador y del administrador de controladores, ejecuta este comando:
```
gcloud container clusters update [CLUSTER_ID] \
  --zone=[ZONE] \
  --project=[PROJECT_ID] \
  --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER
```

Formato de métrica

Todas las métricas del plano de control de Kubernetes escritas en Cloud Monitoring usan el tipo de recurso prometheus_target. Cada nombre de métrica tiene el prefijo prometheus.googleapis.com/ y tiene un sufijo que indica el tipo de métrica de PromQL, como /gauge, /histogram o /counter. De lo contrario, cada nombre de métrica es idéntico al nombre de la métrica que expone Kubernetes de código abierto.

Precios

Las métricas del plano de control de G K E usan Google Cloud Managed Service para Prometheus a fin de transferir métricas a Cloud Monitoring. Cloud Monitoring cobra por la transferencia de las métricas del plano de control de G K E según la cantidad de muestras transferidas. Obtén más información sobre los precios de Cloud Monitoring.

Información sobre tu factura de Monitoring

Para identificar qué métricas del plano de control tienen la mayor cantidad de muestras que se transfieren, usa la métrica monitoring.googleapis.com/collection/attribution/write_sample_count:

En la consola, selecciona Monitoring:

Ir a Monitoring
En el panel de navegación de Monitoring, haz clic en Explorador de métricas (Metrics Explorer).
En el campo Métrica, selecciona monitoring.googleapis.com/collection/attribution/write_sample_count.
Haz clic en Agregar filtro.
En el campo Etiqueta, selecciona attribution_dimension.
En el campo Comparación, selecciona = (equals).
En el campo Valor, ingresa cluster.
Haga clic en Listo.
De manera opcional, filtra solo ciertas métricas. En particular, dado que todas las métricas del servidor de la API incluyen “apiserver” como parte del nombre de la métrica, y debido a que todas las métricas del programador incluyen “scheduler” como parte del nombre de la métrica, puedes restringir las métricas que contienen esas strings:
- Haz clic en Agregar filtro.
- En el campo Etiqueta, selecciona metric_type.
- En el campo Comparación, selecciona =~ (equals regex).
- En el campo Valor, ingresa .*apiserver.* o .*scheduler.*.
- Haga clic en Listo.
De manera opcional, agrupa la cantidad de muestras transferidas por región o proyecto de G K E:
- Haz clic en Agrupar por.
- Asegúrate de que esté seleccionado metric_type.
- Para agrupar por región de GKE, selecciona ubicación.
- Para agrupar por proyecto, selecciona project_id.
- Haga clic en OK.
De manera opcional, agrupa la cantidad de muestras transferidas por nombre del clúster de G K E:
- Haz clic en Agrupar por.
- Para agrupar por nombre del clúster de G K E, asegúrate de que estén seleccionados attribution_dimension y attribution_id.
- Haga clic en OK.
Para ordenar la lista de métricas en orden descendente, haz clic en el encabezado Valor de la columna sobre la lista de métricas.

En estos pasos, se muestran las métricas con la tasa más alta de muestras transferidas a Cloud Monitoring. Dado que las métricas del plano de control de G K E se cobran por la cantidad de muestras transferidas, presta atención a las métricas con la tasa más alta de muestras transferidas.

Exporta desde Cloud Monitoring

Las métricas del plano de control se pueden exportar desde Cloud Monitoring mediante la API de Cloud Monitoring. Debido a que todas las métricas del plano de control se transfieren mediante Managed Service para Prometheus, las métricas del plano de control se pueden consultar mediante PromQL o consultar mediante MQL.

Cuota

Las métricas del plano de control consumen la cuota de “solicitudes de transferencia de series temporales por minuto” de la API de Cloud Monitoring. Antes de habilitar las métricas del plano de control, es posible que desees verificar el uso máximo reciente de esa cuota. Si tienes muchos clústeres en el mismo proyecto o ya te acercas al límite de esa cuota, es posible que desees solicitar un aumento del límite de cuota antes de habilitar las métricas del plano de control.

Consulta métricas

Cuando consultas las métricas del plano de control, el nombre que usas depende de si usas funciones de PromQL o Cloud Monitoring, como el Explorador de métricas, MQL o paneles. En las tablas de las secciones Métricas del servidor de la API, Métricas del programador y Métricas del administrador de controladores que se muestran a continuación, aparecen dos versiones de cada nombre de métrica:

Nombre de la métrica PromQL: cuando se usa PromQL en la página Prometheus administrado de la consola o en la API de Cloud Monitoring, usa el nombre de métrica de PromQL.
Nombre de la métrica de Cloud Monitoring: Cuando uses otras funciones de Monitoring, usa el nombre de la métrica de Cloud Monitoring en las tablas que aparecen a continuación. Este nombre debe tener el prefijo prometheus.googleapis.com/, que se omitió en las entradas de la tabla.

Métricas del servidor de la API

Cuando las métricas del servidor de la API están habilitadas, todas las métricas que se muestran en la siguiente tabla se exportan a Cloud Monitoring en el mismo proyecto que el clúster de G K E.

Los nombres de las métricas de Cloud Monitoring en esta tabla deben tener el prefijo prometheus.googleapis.com/. Este prefijo se omitió en las entradas de la tabla.

Nombre de la métrica de PromQL ^{Etapa de lanzamiento} Nombre de la métrica de Cloud Monitoring
Categoría, tipo, unidad Recursos supervisados Versión de GKE requerida	Descripción Etiquetas
`apiserver_current_inflight_requests` ^DG `apiserver_current_inflight_requests/gauge`
`Gauge`, `Double`, `1` prometheus_target 1.23.6+	Cantidad máxima del límite de solicitudes en curso usado actualmente de este apiserver por tipo de solicitud en el último segundo. `request_kind`
`apiserver_request_duration_seconds` ^DG `apiserver_request_duration_seconds/histogram`
`Cumulative`, `Distribution`, `s` prometheus_target 1.23.6+	Distribución de latencia de respuesta en segundos para cada verbo, valor de ejecución de prueba, grupo, versión, recurso, subrecurso, alcance y componente. `component` `dry_run` `group` `resource` `scope` `subresource` `verb` `version`
`apiserver_request_total` ^DG `apiserver_request_total/counter`
`Cumulative`, `Double`, `1` prometheus_target 1.23.6+	Contador de solicitudes de apiserver desglosadas para cada verbo, valor de ejecución de prueba, grupo, versión, recurso, permiso, componente y código de respuesta HTTP. `code` `component` `dry_run` `group` `resource` `scope` `subresource` `verb` `version`
`apiserver_response_sizes` ^DG `apiserver_response_sizes/histogram`
`Cumulative`, `Distribution`, `1` prometheus_target 1.23.6+	Distribución de tamaño de las respuestas en bytes para cada grupo, versión, verbo, recurso, subrecurso, alcance y componente. `component` `group` `resource` `scope` `subresource` `verb` `version`
`apiserver_storage_objects` ^DG `apiserver_storage_objects/gauge`
`Gauge`, `Double`, `1` prometheus_target 1.23.6+	Cantidad de objetos almacenados en el momento de la última verificación dividida por tipo. `resource`
`apiserver_admission_controller_admission_duration_seconds` ^DG `apiserver_admission_controller_admission_duration_seconds/histogram`
`Cumulative`, `Distribution`, `s` prometheus_target 1.23.6+	Histograma de latencia del controlador de admisión en segundos, identificado por nombre y desglosado para cada operación y recurso y tipo de API (validación o admisión). `name` `operation` `rejected` `type`
`apiserver_admission_step_admission_duration_seconds` ^DG `apiserver_admission_step_admission_duration_seconds/histogram`
`Cumulative`, `Distribution`, `s` prometheus_target 1.23.6+	Histograma de latencia de paso secundario de admisión en segundos, desglosado para cada operación y recurso de API y tipo de paso (validar o admitir). `operation` `rejected` `type`
`apiserver_admission_webhook_admission_duration_seconds` ^DG `apiserver_admission_webhook_admission_duration_seconds/histogram`
`Cumulative`, `Distribution`, `s` prometheus_target 1.23.6+	Histograma de latencia de webhook de admisión en segundos, identificado por nombre y desglosado para cada operación y recurso de API y tipo (validación o admisión). `name` `operation` `rejected` `type`

Métricas del programador

Cuando las métricas del programador están habilitadas, todas las métricas que se muestran en la siguiente tabla se exportan a Cloud Monitoring en el mismo proyecto que el clúster de G K E.

Los nombres de las métricas de Cloud Monitoring en esta tabla deben tener el prefijo prometheus.googleapis.com/. Este prefijo se omitió en las entradas de la tabla.

Nombre de la métrica de PromQL ^{Etapa de lanzamiento} Nombre de la métrica de Cloud Monitoring
Categoría, tipo, unidad Recursos supervisados Versión de GKE requerida	Descripción Etiquetas
`scheduler_pending_pods` ^DG `scheduler_pending_pods/gauge`
`Gauge`, `Double`, `1` prometheus_target 1.23.6+	Cantidad de Pods pendientes, por tipo de cola. “activos” se refiere a la cantidad de Pods en activeQ; “retirados” se refiere a la cantidad de Pods en backoffQ; “no programable” se refiere a la cantidad de Pods unschedulablePods. `queue`
`scheduler_preemption_attempts_total` ^DG `scheduler_preemption_attempts_total/counter`
`Cumulative`, `Double`, `1` prometheus_target 1.23.6+	Total de intentos de interrupción en el clúster hasta ahora
`scheduler_preemption_victims` ^DG `scheduler_preemption_victims/histogram`
`Cumulative`, `Distribution`, `1` prometheus_target 1.23.6+	Cantidad de víctimas de interrupciones seleccionadas
`scheduler_scheduling_attempt_duration_seconds` ^DG `scheduler_scheduling_attempt_duration_seconds/histogram`
`Cumulative`, `Distribution`, `1` prometheus_target 1.23.6+	Latencia de los intentos de programación en segundos (algoritmo de programación + vinculación). `profile` `result`
`scheduler_schedule_attempts_total` ^DG `scheduler_schedule_attempts_total/counter`
`Cumulative`, `Double`, `1` prometheus_target 1.23.6+	Cantidad de intentos de programación de Pods, por resultado. “no programable” se refiere a un Pod que no se pudo programar, mientras que “error” se refiere a un problema interno del programador. `profile` `result`

Métricas del Administrador de controladores

Cuando las métricas del administrador de controladores están habilitadas, todas las métricas que se muestran en la siguiente tabla se exportan a Cloud Monitoring en el mismo proyecto que el clúster de G K E.

Los nombres de las métricas de Cloud Monitoring en esta tabla deben tener el prefijo prometheus.googleapis.com/. Este prefijo se omitió en las entradas de la tabla.

Nombre de la métrica de PromQL ^{Etapa de lanzamiento} Nombre de la métrica de Cloud Monitoring
Categoría, tipo, unidad Recursos supervisados Versión de GKE requerida	Descripción Etiquetas
`node_collector_evictions_total` ^DG `node_collector_evictions_total/counter`
`Cumulative`, `Double`, `1` prometheus_target 1.24+	Cantidad de expulsiones de nodos que ocurrieron desde que se inició la instancia actual de NodeController. `zone`

Métricas de cargas de trabajo

Si tu clúster de GKE usa métricas de carga de trabajo, migra al servicio administrado para Prometheus antes de actualizar tu clúster a GKE 1.24, ya que las métricas de carga de trabajo compatibles se quitan en GKE 1.24.

GKE 1.20.8-gke.2100 o posterior y las versiones GKE anteriores a 1.24 ofrecen una canalización de recopilación de métricas completamente administrada para recopilar métricas de estilo Prometheus expuestas por las cargas de trabajo GKE (como un CronJob o una implementación para una aplicación) y envían esas métricas a Cloud Monitoring.

Todas las métricas que recopila la canalización de métricas de cargas de trabajo de GKE se transfieren a Cloud Monitoring con el prefijo workload.googleapis.com.

Los beneficios de las métricas de cargas de trabajo de GKE incluyen lo siguiente:

Configuración sencilla: Puedes comenzar a recopilar métricas con un solo comando de kubectl para implementar un recurso personalizado de PodMonitor. No se requiere la instalación manual de un agente.
Alto grado de configuración: Ajusta los extremos de recopilación, la frecuencia y otros parámetros.
Completamente administrado: Google mantiene la canalización para que puedas enfocarte en tus aplicaciones.
Controla los costos: Administra los costos de Cloud Monitoring con facilidad mediante el filtrado flexible de métricas.
Estándar abierto: Configura las métricas de cargas de trabajo con el recurso personalizado PodMonitor, que se modela después del recurso PodMonitor del operador de Prometheus.
Mejor precio: Precios más intuitivos, predecibles y más bajos.
Compatibilidad con Autopilot: Admite clústeres de GKE Standard y GKE Autopilot.

Requisitos

Las métricas de cargas de trabajo de GKE requieren la versión del plano de control de GKE 1.20.8-gke.2100 o posterior y no son compatibles con las cargas de trabajo de GKE Windows.

Si habilitas la canalización de métricas de cargas de trabajo, también debes habilitar la recopilación de métricas del sistema.

Paso 1: Habilita la canalización de las métricas de carga de trabajo

Para habilitar la canalización de recopilación de métricas de cargas de trabajo en un clúster de GKE existente, sigue estos pasos:

CONSOLE

En la consola de Google Cloud, ve a la lista de clústeres de GKE.

Ir a Clústeres de Kubernetes
Haz clic en el nombre del clúster.
En la fila etiquetada “Cloud Monitoring”, haz clic en el ícono Editar.
En el cuadro de diálogo “Editar Cloud Monitoring” que aparecerá, confirma que esté seleccionada la opción Habilitar Cloud Monitoring.
En el menú desplegable, selecciona Cargas de trabajo.
Haga clic en OK.
Haz clic en Save Changes.

GCLOUD

Abre una ventana de la terminal con la CLI de Google Cloud instalada. Una forma de hacerlo es mediante Cloud Shell:
En la consola, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Ejecuta este comando:
```
gcloud beta container clusters update [CLUSTER_ID] \
  --zone=[ZONE] \
  --project=[PROJECT_ID] \
  --monitoring=SYSTEM,WORKLOAD
```
Incluir el valor WORKLOAD de la marca --monitoring de los comandos gcloud beta container clusters create o gcloud beta container clusters update habilita la canalización de recopilación de métricas de carga de trabajo.

Nota: Las métricas de cargas de trabajo de GKE actualmente son una vista previa, así que asegúrate de usar los comandos gcloud beta.

Cuando se habilita la canalización de recopilación de métricas de cargas de trabajo, se implementa un agente de recopilación de métricas en cada nodo que puede recopilar métricas de aplicaciones que emiten las cargas de trabajo de Kubernetes.

Consulta Configura operaciones en la nube para GKE a fin de obtener más detalles sobre la integración de Cloud Monitoring en GKE.

Paso 2: Configura qué métricas se recopilan

1) Crea un recurso personalizado PodMonitor llamado my-pod-monitor.yaml:


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2) Inicializa la credencial mediante la CLI de Google Cloud para configurar kubectl:

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3) Implementa el recurso personalizado PodMonitor:

kubectl apply -f my-pod-monitor.yaml

Precios

Cloud Monitoring cobra por la transferencia de las métricas de la carga de trabajo de GKE según la cantidad de muestras transferidas. Obtén más información sobre los precios de Cloud Monitoring.

Administra costos

Para administrar los costos, comienza por determinar qué métricas de cargas de trabajo son más valiosas para tus necesidades de supervisión. La canalización de métricas de cargas de trabajo de GKE proporciona controles detallados para lograr la compensación adecuada entre la captura de métricas detalladas y la conservación del costo bajo.

Muchas aplicaciones exponen una amplia variedad de métricas de Prometheus y, de forma predeterminada, la canalización de métricas de cargas de trabajo de GKE recopila todas las métricas de cada pod seleccionado cada 60 segundos.

Puedes usar las siguientes técnicas para reducir el costo de las métricas:

Ajuste de la frecuencia de recopilación: Para reducir el costo de las métricas, recomendamos reducir la frecuencia de recopilación cuando corresponda. Por ejemplo, es posible que un KPI relevante para el negocio cambie lo suficientemente lento como a fin de que se pueda recopilar cada diez minutos. En el PodMonitor, configura el interval para controlar la frecuencia de recopilación.
Filtra métricas: Identifica las métricas que no se usen en Cloud Monitoring y usa metricRelabelings para garantizar que solo las métricas útiles para los paneles, las alertas o los SLO se envíen a Cloud Monitoring.

Este es un ejemplo concreto de un recurso personalizado PodMonitor que usa ambas técnicas:

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

Para identificar qué métricas tienen la mayor cantidad de muestras transferidas, usa la métrica monitoring.googleapis.com/collection/attribution/write_sample_count:

En la consola, selecciona Monitoring:

Ir a Monitoring
En el panel de navegación de Monitoring, haz clic en Explorador de métricas (Metrics Explorer).
En el campo Métrica, selecciona monitoring.googleapis.com/collection/attribution/write_sample_count.
De manera opcional, filtra solo las métricas de carga de trabajo de GKE:
- Haz clic en Agregar filtro.
- En el campo Etiqueta, selecciona metric_domain.
- En el campo Valor, ingresa workload.googleapis.com.
- Haga clic en Listo.
De manera opcional, agrupa la cantidad de muestras transferidas por el espacio de nombres de Kubernetes, la región de GKE, el proyecto de Google Cloud o el tipo de recurso supervisado:
- Haz clic en Agrupar por.
- Para agrupar por espacio de nombres de Kubernetes, selecciona attribution_dimension y attribution_id.
- Para agrupar por región de GKE, selecciona ubicación.
- Para agrupar por proyecto de Cloud, selecciona resource_container.
- Para agrupar por tipo de recurso supervisado, selecciona resource_type.
Para ordenar la lista de métricas en orden descendente, haz clic en el encabezado Valor de la columna sobre la lista de métricas.

En estos pasos, se muestran las métricas con la tasa más alta de muestras transferidas a Cloud Monitoring. Dado que las métricas de carga de trabajo de GKE se cobran por la cantidad de muestras transferidas, presta atención a las métricas con la tasa de muestreo más alta. Considera si puedes reducir la frecuencia de recopilación de cualquiera de estas métricas o si puedes dejar de recopilar cualquiera de ellas.

Por último, hay muchos recursos disponibles para comprender el costo de las métricas de GKE transferidas a Cloud Monitoring y optimizar esos costos. Consulta la guía de optimización de costos para conocer más formas de reducir el costo de Cloud Monitoring.

Versiones anteriores de GKE

Para recopilar las métricas de la aplicación en un clúster con una versión del plano de control de GKE inferior a 1.20.8-gke.2100, usa el sidecar de Stackdriver Prometheus.

Soluciona problemas

Si las métricas no están disponibles en Cloud Monitoring como se espera, usa los pasos de las siguientes secciones para solucionar problemas.

Soluciona problemas del sistema de métricas

Si las métricas del sistema no están disponibles en Cloud Monitoring como se espera, aquí hay algunos pasos que puedes seguir para solucionar el problema.

Confirma que el agente de métricas tenga suficiente memoria

En la mayoría de los casos, la asignación predeterminada de recursos al agente de métricas de GKE es suficiente. Sin embargo, si el DaemonSet falla de forma repetida, puedes verificar el motivo de la finalización con las siguientes instrucciones:

Obtén los nombres de los Pods del agente de métricas de GKE:

kubectl get pods -n kube-system -l component=gke-metrics-agent

Busca el Pod con el estado CrashLoopBackOff.

El resultado es similar a este:

NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

Describe el Pod que tiene el estado CrashLoopBackOff:

kubectl describe pod POD_NAME -n kube-system

Reemplaza POD_NAME por el nombre del Pod del paso anterior.

Si el motivo de finalización del Pod es OOMKilled, el agente necesita memoria adicional.

El resultado es similar a este:

  containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"

Agrega una etiqueta de nodo temporal al nodo con el agente de métricas con errores. Esta etiqueta no se mantendrá después de una actualización.
```
kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite
```
Reemplaza ADDITIONAL_MEMORY_NODE_LABEL por uno de los siguientes valores:
- Para agregar 10 MB adicionales, ejecuta este comando: cloud.google.com/gke-metrics-agent-scaling-level=10
- Para agregar 20 MB adicionales, ejecuta este comando: cloud.google.com/gke-metrics-agent-scaling-level=20
Reemplaza NODE_NAME por el nombre del nodo del agente de métricas afectado.

Como alternativa, puedes crear un nuevo grupo de nodos con una etiqueta de nodo persistente y usar taints de nodos para migrar tus cargas de trabajo al nuevo grupo de nodos.

Para crear un grupo de nodos con una etiqueta persistente, ejecuta el siguiente comando:
```
gcloud container node-pools create NODEPOOL_NAME \
 --cluster=CLUSTER_NAME  \
 --node-labels=ADDITIONAL_MEMORY_NODE_LABEL
```
Reemplaza lo siguiente:
- CLUSTER_NAME: es el nombre del clúster existente.
- NODEPOOL_NAME: el nombre del grupo de nodos nuevo
- ADDITIONAL_MEMORY_NODE_LABEL: Una de las etiquetas de nodo de memoria adicionales del paso anterior, que agrega 10 MB o 20 MB de memoria adicional.

Soluciona problemas de métricas de cargas de trabajo

Si las métricas de cargas de trabajo no están disponibles en Cloud Monitoring como se espera, aquí hay algunos pasos que puedes seguir para solucionar el problema.

Confirma que tu clúster cumple con los requisitos mínimos

Asegúrate de que tu clúster de GKE ejecute la versión del plano de control 1.20.8-gke.2100 o posterior. De lo contrario, actualiza el plano de control de tu clúster.

Confirma que las métricas de cargas de trabajo están habilitadas

Asegúrate de que tu clúster de GKE esté configurado para habilitar la canalización de recopilación de métricas de cargas de trabajo mediante los siguientes pasos:

CONSOLE

En la consola de Google Cloud, ve a la lista de clústeres de GKE.

Ir a Clústeres de Kubernetes
Haz clic en el nombre del clúster.
En el panel Detalles de tu clúster, confirma que “Workload” esté incluida en el estado de Cloud Monitoring. Si “Carga de trabajo” no se muestra aquí, habilita las métricas de carga de trabajo.

GCLOUD

Abre una ventana de la terminal con la CLI de gcloud instalada. Una forma de hacerlo es mediante Cloud Shell.
En la consola, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior de la consola de Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Ejecuta este comando:
```
gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
```
En el resultado de ese comando, busca la línea monitoringConfig:. Algunas líneas más tarde, confirman que la sección enableComponents: incluya WORKLOADS. Si WORKLOADS no se muestra aquí, habilita las métricas de cargas de trabajo.

Confirma que las métricas se recopilan de tu aplicación

Si no puedes ver las métricas de tu aplicación en Cloud Monitoring, los siguientes pasos pueden ayudarte a solucionar problemas. En estos pasos, se usa una app de ejemplo con fines de demostración, pero puedes aplicar los mismos pasos que se indican a continuación para solucionar problemas de cualquier aplicación.

En los primeros pasos que se indican a continuación, se implementa una app de ejemplo, que puedes usar para realizar pruebas. En los pasos restantes, se muestran los pasos que se deben seguir para solucionar problemas por los que las métricas de esa aplicación podrían no aparecer en Cloud Monitoring.

Crea un archivo llamado prometheus-example-app.yaml que contenga lo siguiente:

# This example application exposes prometheus metrics on port 1234.
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: prom-example
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: prom-example
  template:
    metadata:
      labels:
        app: prom-example
    spec:
      containers:
      - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
        name: prom-example
        ports:
        - name: metrics-port
          containerPort: 1234
        command:
        - "/main"
        - "--process-metrics"
        - "--go-metrics"

Inicializa la credencial mediante la CLI de Google Cloud para configurar kubectl:
```
gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
```
Crea el espacio de nombres gke-workload-metrics:
```
kubectl create ns gke-workload-metrics
```

Implementa la aplicación de ejemplo

kubectl apply -f prometheus-example-app.yaml

Para confirmar que la aplicación de ejemplo está en ejecución, ejecuta este comando:

kubectl get pod -n gke-workload-metrics -l app=prom-example

El resultado debe ser similar a este:

NAME                            READY   STATUS    RESTARTS   AGE
prom-example-775d8685f4-ljlkd   1/1     Running   0          25m

Confirma que tu aplicación expone métricas como se espera

Con uno de los pods que se muestran a partir del comando anterior, verifica que el extremo de métricas funcione de forma correcta:

POD_NAME=prom-example-775d8685f4-ljlkd
NAMESPACE=gke-workload-metrics
PORT_NUMBER=1234
METRICS_PATH=/metrics
kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH

Si usas la aplicación de ejemplo anterior, deberías recibir un resultado similar al siguiente:

# HELP example_random_numbers A histogram of normally distributed random numbers.
# TYPE example_random_numbers histogram
example_random_numbers_bucket{le="0"} 501
example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
...

Crea un archivo llamado my-pod-monitor.yaml que contenga lo siguiente:

# Note that this PodMonitor is in the monitoring.gke.io domain,
# rather than the monitoring.coreos.com domain used with the
# Prometheus Operator.  The PodMonitor supports a subset of the
# fields in the Prometheus Operator's PodMonitor.
apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: example
  namespace: gke-workload-metrics
# spec describes how to monitor a set of pods in a cluster.
spec:
  # selector determines which pods are monitored.  Required
  # This example matches pods with the `app: prom-example` label
  selector:
    matchLabels:
      app: prom-example
  podMetricsEndpoints:
    # port is the name of the port of the container to be scraped.
  - port: metrics-port
    # path is the path of the endpoint to be scraped.
    # Default /metrics
    path: /metrics
    # scheme is the scheme of the endpoint to be scraped.
    # Default http
    scheme: http
    # interval is the time interval at which metrics should
    # be scraped. Default 60s
    interval: 20s

Crea este recurso PodMonitor:
```
kubectl apply -f my-pod-monitor.yaml
```
Una vez que hayas creado el recurso PodMonitor, la canalización de métricas de cargas de trabajo de GKE detectará los pods adecuados y comenzará a recopilarlos de forma automática. La canalización enviará las métricas recopiladas a Cloud Monitoring.
Confirma que la etiqueta y el espacio de nombres estén configurados correctamente en tu PodMonitor. Actualiza los valores de NAMESPACE y SELECTOR a continuación para reflejar las namespace y matchLabels en tu recurso personalizado PodMonitor. Luego, ejecuta este comando:
```
NAMESPACE=gke-workload-metrics
SELECTOR=app=prom-example
kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
```
Deberías ver un resultado como el siguiente:
```
NAME                            READY   STATUS    RESTARTS   AGE
prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
```
Confirma que el PodMonitor esté en el estado Ready.

Ejecuta este comando para mostrar todos los PodMonitor que instalaste en tu clúster:
```
kubectl get podmonitor.monitoring.gke.io --all-namespaces
```
Deberías ver un resultado similar a este:
```
NAMESPACE              NAME      AGE
gke-workload-metrics   example   2m36s
```
Identifica el PodMonitor relevante del conjunto que se muestra y ejecuta este comando (reemplaza example en el comando que se muestra a continuación por el nombre del PodMonitor):
```
kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
```
Examina los resultados que muestra kubectl describe y confirma que la condición “Listo” sea Verdadera. Si la condición “Listo” es Falsa, busca eventos que indiquen por qué no está listo.
A continuación, confirmaremos que Cloud Monitoring recibe estas métricas. En la sección Cloud Monitoring de la consola de Google Cloud, ve al Explorador de métricas.
En el campo Métrica, escribe example_requests_total.
En el menú desplegable que aparece, selecciona workload.googleapis.com/example_requests_total.

Esta métrica example_requests_total es una de las métricas de Prometheus que emite la aplicación de ejemplo.

Si el menú desplegable no aparece o si no ves workload.googleapis.com/example_requests_total en el menú desplegable, vuelve a intentarlo en unos minutos.

Todas las métricas están asociadas con el recurso de contenedor de Kubernetes (k8s_container) del que se recopilan. Puedes usar el campo Tipo de recurso del Explorador de métricas para seleccionar k8s_container. También puedes agrupar por etiquetas, como namespace_name o pod_name.

Esta métrica se puede usar en cualquier lugar dentro de Cloud Monitoring o se puede consultar a través de la API de Cloud Monitoring. Por ejemplo, para agregar este gráfico a un panel existente o nuevo, haz clic en el botón Guardar gráfico en la esquina superior derecha y selecciona el panel deseado en una ventana de diálogo.

Comprueba los errores que se envían a la API de Cloud Monitoring

Las métricas enviadas a Cloud Monitoring deben permanecer dentro de los límites de métricas personalizadas. Los errores se mostrarán en los registros de auditoría de Cloud Monitoring.

Mediante el Explorador de registros de Cloud Logging, busca los registros con este filtro de registros (reemplaza PROJECT_ID por el nombre de tu proyecto):

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*-compute@developer.gserviceaccount.com"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

Ten en cuenta que esto mostrará errores para todas las operaciones de escritura en Cloud Monitoring del proyecto, no solo los de tu clúster.

Verifica tu cuota de transferencia de Cloud Monitoring

Ve a la página Cuotas de la API de Cloud Monitoring.
Selecciona el proyecto relevante.
Expande la sección Solicitudes de transferencia de series temporales.
Confirma que el Recuento de errores de superación de la cuota en “Solicitudes de transferencia de series temporales por minuto” sea 0. (Si este es el caso, el gráfico “Recuento de errores de superación de la cuota” indicará “No hay datos disponibles para el período seleccionado”).
Si el porcentaje de uso máximo excede el 100%, considera seleccionar menos pods, seleccionar menos métricas o solicitar un límite de cuota más alto para la cuota monitoring.googleapis.com/ingestion_requests.

Confirma que el DaemonSet está implementado

Asegúrate de que las métricas de carga de trabajo de DaemonSet se implementen en tu clúster. Puedes validar que esto funciona como se espera mediante kubectl:

Inicializa la credencial mediante la CLI de Google Cloud para configurar kubectl:
```
gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
```
Comprueba que el DaemonSet de métricas de cargas de trabajo esté presente y en buen estado. Ejecuta lo siguiente:
```
kubectl get ds -n kube-system workload-metrics
```
Si los componentes se implementaron de forma correcta, verás un resultado similar al siguiente:
```
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
workload-metrics   3         3         3       3            3           2m
```
La cantidad de réplicas anteriores debe coincidir con la cantidad de nodos de GKE de Linux en tu clúster. Por ejemplo, un clúster con 3 nodos tendrá DESIRED = 3. Después de unos minutos, los números READY y AVAILABLE deben coincidir con el número DESIRED. De lo contrario, es posible que haya un problema con la implementación.

Otras métricas

Además de las métricas del sistema y las métricas del plano de control en este documento, las métricas de Istio también están disponibles para los clústeres de G K E.