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 dos 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.
- 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 Cloud Console. 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 de cargas de trabajo
Las métricas de cargas de trabajo de GKE son la forma recomendada de Google de supervisar las aplicaciones de Kubernetes con Cloud Monitoring.
GKE 1.20.8-gke.2100 o posterior ofrece una canalización de recopilación de métricas completamente administrada para recopilar métricas de estilo Prometheus expuestas por cualquier carga de trabajo de GKE (como un CronJob o una implementación para una aplicación) y envía 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
kubectlpara 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.
- Compatibilidad con HPA: Compatible con el adaptador de métricas personalizadas de Stackdriver para habilitar el escalamiento horizontal en las métricas personalizadas.
- 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 Google Cloud Console, 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 el SDK de Cloud y la herramienta de línea de comandos de
gcloudinstalada. Una forma de hacerlo es mediante Cloud Shell:-
En Cloud Console, activa Cloud Shell.
En la parte inferior de Cloud Console, 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 que tiene el SDK de Cloud preinstalado, incluida la herramienta de línea de comandos de
gcloud, y valores ya establecidos para el proyecto actual. La inicialización de la sesión puede tomar unos minutos. Ejecuta este comando:
gcloud beta container clusters update [CLUSTER_ID] \ --zone=[ZONE] \ --project=[PROJECT_ID] \ --monitoring=SYSTEM,WORKLOAD
Incluir el valor
WORKLOADde la marca--monitoringde los comandosgcloud beta container clusters createogcloud beta container clusters updatehabilita 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 herramienta de línea de comandos de gcloud 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
Migrating
Si ya usas el sidecar de Stackdriver Prometheus, las métricas de cargas de trabajo de GKE proporcionan varias mejoras. Se recomienda que cambies a las métricas de cargas de trabajo de GKE para recopilar métricas emitidas por la aplicación. Consulta la guía de migración desde el archivo adicional de Stackdriver Prometheus a las métricas de carga de trabajo de GKE.
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
intervalpara controlar la frecuencia de recopilación.Filtra métricas: Identifica las métricas que no se usen en Cloud Monitoring y usa
metricRelabelingspara 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 Cloud Console, 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 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 Google Cloud Console, 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 el SDK de Cloud y
gcloudinstalado. Una forma de hacerlo es mediante Cloud Shell:-
En Cloud Console, activa Cloud Shell.
En la parte inferior de Cloud Console, 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 que tiene el SDK de Cloud preinstalado, incluida la herramienta de línea de comandos de
gcloud, y valores ya establecidos para el proyecto actual. La inicialización de la sesión puede tomar unos minutos. 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. SiWORKLOADSno 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.yamlque 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 herramienta de línea de comandos de
gcloudpara configurarkubectl:gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
Crea el espacio de nombres
gke-workload-metrics:kubectl create ns gke-workload-metricsImplementa la aplicación de ejemplo
kubectl apply -f prometheus-example-app.yamlPara confirmar que la aplicación de ejemplo está en ejecución, ejecuta este comando:
kubectl get pod -n gke-workload-metrics -l app=prom-exampleEl 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_PATHSi 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.yamlque 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: 20sCrea este recurso PodMonitor:
kubectl apply -f my-pod-monitor.yamlUna 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
NAMESPACEySELECTORa continuación para reflejar lasnamespaceymatchLabelsen tu recurso personalizado PodMonitor. Luego, ejecuta este comando:NAMESPACE=gke-workload-metrics SELECTOR=app=prom-example kubectl get pods --namespace $NAMESPACE --selector $SELECTORDeberías ver un resultado como el siguiente:
NAME READY STATUS RESTARTS AGE prom-example-7cff4db5fc-wp8lw 1/1 Running 0 39mConfirma 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-namespacesDeberías ver un resultado similar a este:
NAMESPACE NAME AGE gke-workload-metrics example 2m36sIdentifica el PodMonitor relevante del conjunto que se muestra y ejecuta este comando (reemplaza
exampleen el comando que se muestra a continuación por el nombre del PodMonitor):kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metricsExamina los resultados que muestra
kubectl describey 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 Google Cloud Console, 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_totales 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_totalen 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_nameopod_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 herramienta de línea de comandos de
gcloudpara configurarkubectl: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-metricsSi 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úmerosREADYyAVAILABLEdeben 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 de cargas de trabajo que se describieron antes, algunas métricas adicionales disponibles para un clúster de GKE son las siguientes:
- Las métricas de Istio están disponibles en Cloud Monitoring.