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.
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.
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
oCONTROLLER_MANAGER
a la marca--monitoring
de los comandosgcloud container clusters create
ogcloud 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:
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
DGapiserver_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
DGapiserver_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
DGapiserver_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
DGapiserver_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
DGapiserver_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
DGapiserver_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
DGapiserver_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
DGapiserver_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
DGscheduler_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
DGscheduler_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
DGscheduler_preemption_victims/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.23.6+ |
Cantidad de víctimas de interrupciones seleccionadas |
scheduler_scheduling_attempt_duration_seconds
DGscheduler_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
DGscheduler_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
DGnode_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.
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.
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 comandosgcloud beta container clusters create
ogcloud beta container clusters update
habilita la canalización de recopilación de métricas de carga de trabajo.
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:
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 nuevoADDITIONAL_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.
- Para agregar 10 MB adicionales, ejecuta este comando:
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.
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.
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ónenableComponents:
incluyaWORKLOADS
. SiWORKLOADS
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
ySELECTOR
a continuación para reflejar lasnamespace
ymatchLabels
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 seleccionark8s_container
. También puedes agrupar por etiquetas, comonamespace_name
opod_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úmerosREADY
yAVAILABLE
deben coincidir con el númeroDESIRED
. 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.