Google Kubernetes Engine (GKE) facilite l'envoi de métriques à Cloud Monitoring. Une fois dans Cloud Monitoring, les métriques peuvent permettre de renseigner des tableaux de bord personnalisés, générer des alertes et créer des objectifs de niveau de service, ou elles peuvent être récupérés par des services de surveillance tiers à l'aide de l'API Monitoring.
GKE fournit plusieurs sources de métriques :
- Métriques définies par le système : métriques issues des composants système essentiels, décrivant les ressources de bas niveau telles que le processeur, la mémoire et le stockage.
- Managed Service pour Prometheus vous permet de surveiller vos charges de travail et d'envoyer des alertes à l'aide de Prometheus, sans avoir à gérer et faire fonctionner manuellement Prometheus à grande échelle.
- Métriques du plan de contrôle : métriques exportées à partir de certains composants du plan de contrôle, tels que le serveur d'API et le programmeur.
- Métriques liées aux charges de travail (obsolète) : métriques exposées par n'importe quelle charge de travail GKE (telle qu'une tâche cron ou un déploiement pour une application).
Métriques système
Lorsqu'un cluster est créé, GKE collecte par défaut certaines métriques émises par les composants système.
Vous pouvez choisir d'envoyer ou non les métriques de votre cluster GKE à Cloud Monitoring. Si vous choisissez d'envoyer des métriques à Cloud Monitoring, vous devez envoyer des métriques système.
Toutes les métriques GKE définies par le système sont ingérées dans Cloud Monitoring avec le préfixe kubernetes.io
.
Tarifs
Cloud Monitoring ne facture pas l'ingestion de métriques système G K E. En savoir plus sur les tarifs de Cloud Monitoring.
Configurer la collecte de métriques définies par le système
Pour activer la collecte de métriques définies par le système, transmettez la valeur SYSTEM
à l'option --monitoring
de la commande gcloud container clusters create
ou gcloud container clusters update
.
Pour désactiver la collecte de métriques définies par le système, utilisez la valeur NONE
pour l'option --monitoring
. Si la collecte de métriques définies par le système est désactivée, les informations de base telles que l'utilisation du processeur, de la mémoire et du disque ne sont pas disponibles pour un cluster dans la section GKE de Google Cloud Console. De plus, le tableau de bord GKE de Cloud Monitoring ne contient pas d'informations sur le cluster.
Consultez la section Configurer Cloud Operations pour GKE pour obtenir plus d'informations sur l'intégration de Cloud Monitoring à GKE.
Liste des métriques définies par le système
Les métriques définies par le système incluent des métriques provenant des composants système essentiels pour les fonctionnalités principales de Kubernetes. Consultez la liste complète des métriques système.
Métriques du plan de contrôle
Vous pouvez configurer un cluster G K E pour envoyer certaines métriques émises par le serveur d'API Kubernetes, le programmeur et le gestionnaire de contrôleurs à Cloud Monitoring.
Exigences
L'envoi de métriques du plan de contrôle Kubernetes à Cloud Monitoring à Cloud Monitoring nécessite la version 1.23.6 ou ultérieure du plan de contrôle G K E et nécessite l'activation de la collecte de métriques système.
Configurer la collecte de métriques du plan de contrôle
Pour activer les métriques du plan de contrôle Kubernetes dans un cluster GKE existant, procédez comme suit :
CONSOLE
Dans Google Cloud Console, accédez à la liste des clusters GKE :
Cliquez sur le nom de votre cluster.
Sur la ligne intitulée Cloud Monitoring, cliquez sur l'icône Modifier.
Dans la boîte de dialogue Modifier Cloud Monitoring qui s'affiche, vérifiez que l'option Activer Cloud Monitoring est sélectionnée.
Dans le menu déroulant Composants sélectionnez les composants du plan de contrôle à partir desquels vous souhaitez collecter des métriques: Serveur d'API ,Programmeur ou Gestionnaire de contrôleurs.
Cliquez sur OK.
Cliquez sur Save Changes (Enregistrer les modifications).
GCLOUD
Ouvrez une fenêtre de terminal avec Google Cloud SDK et Google Cloud CLI installés. L'une des méthodes consiste à utiliser Cloud Shell :
-
Dans la console, activez Cloud Shell.
En bas de la fenêtre de la console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Transmettez une ou plusieurs des valeurs
API_SERVER
,SCHEDULER
ouCONTROLLER_MANAGER
à l'option--monitoring
des commandesgcloud container clusters create
ougcloud container clusters update
.Par exemple, pour collecter les métriques du serveur d'API, du programmeur et du gestionnaire de contrôleurs, exécutez la commande suivante :
gcloud container clusters update [CLUSTER_ID] \ --zone=[ZONE] \ --project=[PROJECT_ID] \ --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER
Format de la métrique
Toutes les métriques du plan de contrôle Kubernetes écrites dans Cloud Monitoring utilisent le type de ressource prometheus_target
. Chaque nom de métrique inclut un préfixe prometheus.googleapis.com/
et un suffixe indiquant le type de métrique PromQL, tel que /gauge
, /histogram
ou /counter
. En dehors de cela, chaque nom de métrique est identique au nom de métrique exposé par Kubernetes Open Source.
Tarifs
Les métriques du plan de contrôle GKE utilisent Google Cloud Managed Service pour Prometheus pour ingérer des métriques dans Cloud Monitoring. Les frais liés à Cloud Monitoring pour l'ingestion de métriques de plan de travail GKE sont basés sur le nombre d'échantillons ingérés. En savoir plus sur les tarifs de Cloud Monitoring.
Comprendre votre facture Monitoring
Pour identifier les métriques du plan de contrôle qui contiennent le plus grand nombre d'échantillons ingérés, utilisez la métrique monitoring.googleapis.com/collection/attribution/write_sample_count
:
Dans la console, sélectionnez Monitoring :
Dans le volet de navigation "Surveillance", cliquez sur Explorateur de métriques.
Dans le champ Métrique, sélectionnez
monitoring.googleapis.com/collection/attribution/write_sample_count
.Cliquez sur Ajouter un filtre.
Dans le champ Libellé, sélectionnez
attribution_dimension
.Dans le champ Comparaison, sélectionnez
= (equals)
.Dans le champ Valeur, saisissez
cluster
.Cliquez sur OK.
Vous pouvez aussi filtrer uniquement suivant certaines métriques. En particulier, étant donné que les noms des métriques du serveur d'API incluent tous l'élément "apiserver" et que les noms des métriques du programmeur incluent tous l'élément "scheduler", vous pouvez vous restreindre aux métriques contenant ces chaînes :
Cliquez sur Ajouter un filtre.
Dans le champ Libellé, sélectionnez
metric_type
.Dans le champ Comparaison, sélectionnez
=~ (equals regex)
.Dans le champ Valeur, saisissez
.*apiserver.*
ou.*scheduler.*
.Cliquez sur OK.
Vous pouvez également regrouper le nombre d'échantillons ingérés suivant la région ou le projet GKE :
Cliquez sur Grouper par.
Assurez-vous que metric_type est sélectionné.
Pour regrouper les données par région G K E, sélectionnez emplacement.
Pour regrouper les données par projet, sélectionnez project_id.
Cliquez sur OK.
Vous pouvez également regrouper le nombre d'échantillons ingérés suivant le nom du cluster GKE :
Cliquez sur Grouper par.
Pour regrouper les données par nom de cluster GKE, assurez-vous que les options attribution_dimension et attribution_id sont sélectionnées.
Cliquez sur OK.
Triez la liste des métriques par ordre décroissant en cliquant sur l'en-tête de colonne Valeur au-dessus de la liste des métriques.
Ces étapes montrent les métriques présentant le taux d'échantillons le plus élevé ingéré dans Cloud Monitoring. Étant donné que les métriques de plan de contrôle G K E sont facturées en fonction du nombre d'échantillons ingérés, prêtez une attention particulière aux métriques dont le taux d'ingestion d'échantillons est le plus élevé.
Exporter depuis Cloud Monitoring
Les métriques du plan de contrôle peuvent être exportées depuis Cloud Monitoring à l'aide de l'API Cloud Monitoring. Étant donné que toutes les métriques du plan de contrôle sont ingérées à l'aide de Managed Service pour Prometheus, les métriques du plan de contrôle peuvent être interrogées à l'aide de PromQL ou de requêtes utilisant MQL.
Quota
Les métriques du plan de contrôle consomment le quota "Time series ingestion requests per minute" (requêtes d'ingestion de séries temporelles par minute) de l'API Cloud Monitoring. Avant d'activer les métriques du plan de contrôle, il peut être judicieux de vérifier votre utilisation maximale récente de ce quota. Si vous avez plusieurs clusters dans le même projet ou que vous approchez déjà de la limite de ce quota, vous pouvez demander une augmentation de la limite de quota avant d'activer les métriques du plan de contrôle.
Interroger les métriques
Lorsque vous interrogez les métriques du plan de contrôle, le nom que vous utilisez varie selon que vous utilisez les fonctionnalités PromQL ou Cloud Monitoring telles que l'Explorateur de métriques, MQL ou les tableaux de bord. Les tableaux des sections Métriques du serveur d'API, Métriques du programmeur et Métriques du gestionnaire de contrôleurs ci-dessous présentent deux versions de chaque nom de métrique :
- Nom de la métrique PromQL: à l'aide de PromQL dans la page Service Prometheus géré de la console ou dans l'API Cloud Monitoring, utilisez le nom de la métrique PromQL.
- Nom de la métrique Cloud Monitoring : lorsque vous utilisez d'autres fonctionnalités de Monitoring, utilisez le nom de la métrique Cloud Monitoring répertorié dans les tableaux ci-dessous. Ce nom doit être précédé du préfixe
prometheus.googleapis.com/
, qui a été omis dans les entrées du tableau.
Métriques du serveur d'API
Lorsque les métriques du serveur d'API sont activées, toutes les métriques répertoriées dans le tableau ci-dessous sont exportées vers Cloud Monitoring dans le même projet que le cluster GKE.
Les noms des métriques Cloud Monitoring figurant dans ce tableau doivent être précédés du préfixe prometheus.googleapis.com/
. Ce préfixe a été omis dans les entrées du tableau.
Nom de la métrique PromQL Étape de lancement Nom de la métrique Cloud Monitoring |
|
---|---|
Genre, Type, Unité
Ressources surveillées Version de GKE requise |
Description Libellés |
apiserver_current_inflight_requests
Disponible pour tous les utilisateursapiserver_current_inflight_requests/gauge
|
|
Gauge , Double , 1
prometheus_target 1.23.6 et versions ultérieures |
Limite du nombre maximal de requêtes en cours actuellement utilisées pour ce serveur d'API par genre de requête au cours de la dernière seconde.request_kind
|
apiserver_request_duration_seconds
Disponible pour tous les utilisateursapiserver_request_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.23.6 et versions ultérieures |
Répartition de la latence des réponses en secondes pour chaque verbe, valeur de simulation, groupe, version, ressource, sous-ressource, champ d'application et composant.component
dry_run
group
resource
scope
subresource
verb
version
|
apiserver_request_total
Disponible pour tous les utilisateursapiserver_request_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.23.6 et versions ultérieures |
Compteur des requêtes au serveur d'API réparties pour chaque verbe, valeur de simulation, groupe, version, ressource, champ d'application, composant et code de réponse HTTP.code
component
dry_run
group
resource
scope
subresource
verb
version
|
apiserver_response_sizes
Disponible pour tous les utilisateursapiserver_response_sizes/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.23.6 et versions ultérieures |
Distribution de la taille de la réponse en octets pour chaque groupe, version, verbe, ressource, sous-ressource, champ d'application et composant.component
group
resource
scope
subresource
verb
version
|
apiserver_storage_objects
Disponible pour tous les utilisateursapiserver_storage_objects/gauge
|
|
Gauge , Double , 1
prometheus_target 1.23.6 et versions ultérieures |
Nombre d'objets stockés au moment de la dernière vérification, répartis par genre.resource
|
apiserver_admission_controller_admission_duration_seconds
Disponible pour tous les utilisateursapiserver_admission_controller_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.23.6 et versions ultérieures |
Histogramme de latence du contrôleur d'admission en secondes, identifié par son nom, et ventilé pour chaque opération, chaque ressource d'API et chaque type (valider ou accepter).name
operation
rejected
type
|
apiserver_admission_step_admission_duration_seconds
Disponible pour tous les utilisateursapiserver_admission_step_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.23.6 et versions ultérieures |
Histogramme de latence des sous-étapes d'admission en secondes, ventilé pour chaque opération, chaque ressource d'API et chaque type d'étape (validation ou admis).operation
rejected
type
|
apiserver_admission_webhook_admission_duration_seconds
Disponible pour tous les utilisateursapiserver_admission_webhook_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.23.6 et versions ultérieures |
Histogramme de latence du webhook d'admission en secondes, identifié par son nom, et ventilé pour chaque opération, chaque ressource d'API et chaque type (valider ou accepter).name
operation
rejected
type
|
Métriques du programmeur
Lorsque les métriques du programmeur sont activées, toutes les métriques répertoriées dans le tableau ci-dessous sont exportées vers Cloud Monitoring dans le même projet que le cluster GKE.
Les noms des métriques Cloud Monitoring figurant dans ce tableau doivent être précédés du préfixe prometheus.googleapis.com/
. Ce préfixe a été omis dans les entrées du tableau.
Nom de la métrique PromQL Étape de lancement Nom de la métrique Cloud Monitoring |
|
---|---|
Genre, Type, Unité
Ressources surveillées Version de GKE requise |
Description Libellés |
scheduler_pending_pods
Disponible pour tous les utilisateursscheduler_pending_pods/gauge
|
|
Gauge , Double , 1
prometheus_target 1.23.6 et versions ultérieures |
Nombre de pods en attente, par type de file d'attente. "active" représente le nombre de pods dans ActiveQ. "backoff" représente le nombre de pods dans backoffQ. "unschedulable" représente le nombre de pods dans unschedulablePods.queue
|
scheduler_preemption_attempts_total
Disponible pour tous les utilisateursscheduler_preemption_attempts_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.23.6 et versions ultérieures |
Nombre total de tentatives de préemption dans le cluster jusqu'à maintenant |
scheduler_preemption_victims
Disponible pour tous les utilisateursscheduler_preemption_victims/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.23.6 et versions ultérieures |
Nombre de cibles sélectionnées pour la préemption |
scheduler_scheduling_attempt_duration_seconds
Disponible pour tous les utilisateursscheduler_scheduling_attempt_duration_seconds/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.23.6 et versions ultérieures |
Latence de la tentative de planification en secondes (algorithme de planification + liaison)profile
result
|
scheduler_schedule_attempts_total
Disponible pour tous les utilisateursscheduler_schedule_attempts_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.23.6 et versions ultérieures |
Nombre de tentatives de planification de pods, en fonction du résultat. "unschedulable" signifie qu'un pod n'a pas pu être planifié, tandis que "error" traduit un problème interne au programmeur.profile
result
|
Métriques du gestionnaire de contrôleurs
Lorsque les métriques du gestionnaire de contrôleurs sont activées, toutes les métriques répertoriées dans le tableau ci-dessous sont exportées vers Cloud Monitoring dans le même projet que le cluster GKE.
Les noms des métriques Cloud Monitoring figurant dans ce tableau doivent être précédés du préfixe prometheus.googleapis.com/
. Ce préfixe a été omis dans les entrées du tableau.
Nom de la métrique PromQL Étape de lancement Nom de la métrique Cloud Monitoring |
|
---|---|
Genre, Type, Unité
Ressources surveillées Version de GKE requise |
Description Libellés |
node_collector_evictions_total
Disponible pour tous les utilisateursnode_collector_evictions_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.24 et versions ultérieures |
Nombre d'évictions de nœuds ayant eu lieu depuis le démarrage de l'instance actuelle de NodeController.zone
|
Métriques liées aux charges de travail
Si votre cluster G K E utilise des métriques de charge de travail, Migrez vers le service géré pour Prometheus avant de mettre à niveau votre cluster vers G K E 1.24, car la compatibilité des métriques de charge de travail est supprimée dans G K E 1.24.
G K E 1.20.8-gke.2100 ou version ultérieure et G K E versions antérieures à 1.24 offrent un pipeline de collecte de métriques entièrement géré pour scraper les métriques de style Prometheus exposées par n'importe quelle charge de travail G K E (par exemple, une tâche cron ou un déploiement pour une application) et envoyez ces métriques à Cloud Monitoring.
Toutes les métriques collectées par le pipeline de métriques liées aux charges de travail GKE sont ingérées dans Cloud Monitoring avec le préfixe workload.googleapis.com
.
Avantages des métriques liées aux charges de travail GKE :
- Configuration facile : une commande
kubectl
permettant de déployer une ressource personnalisée PodMonitor suffit pour commencer à collecter des métriques. Aucune installation manuelle d'un agent n'est nécessaire. - Haute configuration : ajustez les points de terminaison scrapés, la fréquence et d'autres paramètres.
- Entièrement géré : Google gère le pipeline afin que vous puissiez vous concentrer sur vos applications.
- Contrôle des coûts : gérez facilement les coûts Cloud Monitoring grâce au filtrage flexible des métriques.
- Standard ouvert : configurez les métriques liées aux charges de travail à l'aide de la ressource personnalisée PodMonitor, modélisée à partir de la ressource PodMonitor de l'opérateur Prometheus.
- Meilleurs tarifs : tarifs plus intuitifs, prévisibles et économiques.
- Compatibilité avec Autopilot : compatible avec les clusters GKE Standard et GKE Autopilot.
Exigences
Les métriques liées aux charges de travail GKE nécessitent la version 1.20.8-gke.2100 ou ultérieure du plan de contrôle GKE et ne sont pas compatibles avec les charges de travail GKE Windows.
Si vous activez le pipeline de métriques liées aux charges de travail, vous devez également activer la collecte des métriques définies par le système.
Étape 1 : Activez le pipeline de métriques liées aux charges de travail
Pour activer le pipeline de collecte de métriques de charge de travail dans un cluster GKE existant, procédez comme suit :
CONSOLE
Dans Google Cloud Console, accédez à la liste des clusters GKE :
Cliquez sur le nom de votre cluster.
Sur la ligne intitulée "Cloud Monitoring", cliquez sur l'icône Modifier.
Dans la boîte de dialogue "Modifier Cloud Monitoring" qui s'affiche, vérifiez que l'option Activer Cloud Monitoring est sélectionnée.
Dans le menu déroulant, sélectionnez Charges de travail.
Cliquez sur OK.
Cliquez sur Save Changes (Enregistrer les modifications).
GCLOUD
Ouvrez une fenêtre de terminal avec Google Cloud CLI installé. L'une des méthodes consiste à utiliser Cloud Shell.
-
Dans la console, activez Cloud Shell.
En bas de la fenêtre de la console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Exécutez cette commande :
gcloud beta container clusters update [CLUSTER_ID] \ --zone=[ZONE] \ --project=[PROJECT_ID] \ --monitoring=SYSTEM,WORKLOAD
Inclure la valeur
WORKLOAD
de l'option--monitoring
des commandesgcloud beta container clusters create
ougcloud beta container clusters update
active les pipelines de collecte de métriques de charge de travail.
L'activation du pipeline de collecte de métriques liées aux charges de travail a pour effet de déployer un agent de collecte de métriques sur chaque nœud capable de collecter des métriques d'application émises par les charges de travail Kubernetes.
Consultez la section Configurer Cloud Operations pour GKE pour obtenir plus d'informations sur l'intégration de Cloud Monitoring à GKE.
Étape 2 : Configurez les métriques à collecter
1. Créez une ressource personnalisée PodMonitor nommée 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. Initialisez les identifiants à l'aide de Google Cloud CLI afin de configurer kubectl
:
gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
3 Déployez la ressource personnalisée PodMonitor :
kubectl apply -f my-pod-monitor.yaml
Tarifs
Les frais liés à Cloud Monitoring pour l'ingestion de métriques de charge de travail G K E sont basés sur le nombre d'échantillons ingérés. En savoir plus sur les tarifs de Cloud Monitoring.
Gérer les coûts
Pour gérer les coûts, commencez par déterminer les métriques liées aux charges de travail les plus utiles pour vos besoins de surveillance. Le pipeline de métriques liées aux charges de travail GKE fournit des contrôles précis pour obtenir le bon compromis entre la capture de métriques détaillées et la réduction des coûts.
De nombreuses applications exposent une grande variété de métriques Prometheus. Par défaut, le pipeline de métriques liées aux charges de travail GKE scrape toutes les métriques de chaque pod sélectionné toutes les 60 secondes.
Vous pouvez utiliser les techniques suivantes pour réduire le coût des métriques :
Ajuster la fréquence de scraping : pour réduire le coût des métriques, nous vous recommandons de réduire la fréquence de scraping le cas échéant. Par exemple, il est possible qu'un KPI (indicateur clé de performance) pertinent pour l'entreprise change suffisamment lentement pour être scrapé toutes les 10 minutes. Dans PodMonitor, définissez la valeur
interval
pour contrôler la fréquence de scraping.Métriques de filtrage : identifiez les métriques non utilisées dans Cloud Monitoring, et utilisez
metricRelabelings
pour vous assurer que seules les métriques utiles pour les tableaux de bord, les alertes ou les SLO sont envoyées à Cloud Monitoring.
Voici un exemple concret de ressource personnalisée PodMonitor utilisant les deux techniques :
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
Pour identifier les métriques qui possèdent le plus grand nombre d'échantillons en cours d'ingestion, utilisez la métrique monitoring.googleapis.com/collection/attribution/write_sample_count
:
Dans la console, sélectionnez Monitoring :
Dans le volet de navigation "Surveillance", cliquez sur Explorateur de métriques.
Dans le champ Métrique, sélectionnez
monitoring.googleapis.com/collection/attribution/write_sample_count
.Vous pouvez éventuellement filtrer les métriques de charges de travail G K E uniquement :
Cliquez sur Ajouter un filtre.
Dans le champ Libellé, sélectionnez
metric_domain
.Dans le champ Valeur, saisissez
workload.googleapis.com
.Cliquez sur OK.
Vous pouvez également regrouper le nombre d'échantillons ingérés par l'espace de noms Kubernetes, la région G K E, le projet Google Cloud ou le type de ressource surveillée :
Cliquez sur Grouper par.
Pour regrouper les données par espace de noms Kubernetes, sélectionnez attribution_dimension et attribution_id.
Pour regrouper les données par région G K E, sélectionnez emplacement.
Pour regrouper les données par projet Cloud, sélectionnez resource_container.
Pour regrouper les données par type de ressource surveillée, sélectionnez resource_type.
Triez la liste des métriques par ordre décroissant en cliquant sur l'en-tête de colonne Valeur au-dessus de la liste des métriques.
Ces étapes montrent les métriques présentant le taux d'échantillons le plus élevé ingéré dans Cloud Monitoring. Étant donné que les métriques de charge de travail G K E sont facturées en fonction du nombre d'échantillons ingérés, prêtez une attention particulière aux métriques dont le taux d'échantillonnage est le plus élevé. Déterminez si vous pouvez réduire la fréquence de récupération de l'une de ces métriques ou si vous pouvez arrêter de les collecter.
Enfin, de nombreuses ressources sont disponibles pour comprendre le coût des métriques GKE ingérées dans Cloud Monitoring et pour optimiser ces coûts. Consultez le guide d'optimisation des coûts pour découvrir d'autres moyens de réduire les coûts liés à Cloud Monitoring.
Versions antérieures de GKE
Pour collecter des métriques d'application dans un cluster dont la version du plan de contrôle GKE est inférieure à 1.20.8-gke.2100, utilisez le side-car Stackdriver Prometheus.
Dépannage
Si les métriques ne sont pas disponibles comme prévu dans Cloud Monitoring, utilisez les procédures décrites dans les sections suivantes.
Résoudre les problèmes liés aux métriques système
Si les métriques système ne sont pas disponibles dans Cloud Monitoring comme prévu, voici quelques étapes à suivre pour résoudre le problème.
Vérifier que l'agent de métriques dispose de suffisamment de mémoire
Dans la plupart des cas, l'allocation de ressources par défaut à l'agent de métriques GKE est suffisante. Toutefois, si le DaemonSet plante de manière répétée, vous pouvez vérifier le motif de l'arrêt à l'aide des instructions suivantes :
Obtenez les noms des pods de l'agent de métriques GKE :
kubectl get pods -n kube-system -l component=gke-metrics-agent
Recherchez le pod ayant l'état
CrashLoopBackOff
.Le résultat ressemble à ce qui suit :
NAME READY STATUS RESTARTS AGE gke-metrics-agent-5857x 0/1 CrashLoopBackOff 6 12m
Décrivez le pod dont l'état est
CrashLoopBackOff
:kubectl describe pod POD_NAME -n kube-system
Remplacez
POD_NAME
par le nom du pod obtenu à l'étape précédente.Si le motif de l'arrêt du pod est
OOMKilled
, l'agent a besoin de mémoire supplémentaire.Le résultat ressemble à ce qui suit :
containerStatuses: ... lastState: terminated: ... exitCode: 1 finishedAt: "2021-11-22T23:36:32Z" reason: OOMKilled startedAt: "2021-11-22T23:35:54Z"
Ajoutez un libellé de nœud temporaire au nœud hébergeant l'agent de métriques défaillant. Ce libellé ne sera pas conservé après une mise à niveau.
kubectl label node/NODE_NAME \ ADDITIONAL_MEMORY_NODE_LABEL --overwrite
Remplacez
ADDITIONAL_MEMORY_NODE_LABEL
par l'un des éléments suivants :- Pour ajouter 10 Mo supplémentaires :
cloud.google.com/gke-metrics-agent-scaling-level=10
- Pour ajouter 20 Mo supplémentaires :
cloud.google.com/gke-metrics-agent-scaling-level=20
Remplacez
NODE_NAME
par le nom du nœud hébergeant l'agent de métriques concerné.Vous pouvez également créer un pool de nœuds avec un libellé de nœud persistant et utiliser des rejets de nœuds pour migrer vos charges de travail vers le nouveau pool de nœuds.
Pour créer un pool de nœuds avec un libellé persistant, exécutez la commande suivante :
gcloud container node-pools create NODEPOOL_NAME \ --cluster=CLUSTER_NAME \ --node-labels=ADDITIONAL_MEMORY_NODE_LABEL
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster existant.NODEPOOL_NAME
: nom du nouveau pool de nœuds.ADDITIONAL_MEMORY_NODE_LABEL
: l'un des libellés de nœud de mémoire supplémentaires indiqués à l'étape précédente, ajoutant 10 Mo ou 20 Mo de mémoire supplémentaire.
- Pour ajouter 10 Mo supplémentaires :
Résoudre les problèmes liés aux métriques de charge de travail
Si les métriques liées aux charges de travail ne sont pas disponibles dans Cloud Monitoring comme prévu, voici quelques étapes à suivre pour résoudre le problème.
Vérifiez que votre cluster remplit les conditions minimales requises
Assurez-vous que votre cluster GKE exécute le plan de contrôle version 1.20.8-gke.2100 ou ultérieure. Si ce n'est pas le cas, mettez à niveau le plan de contrôle de votre cluster.
Vérifiez que les métriques liées aux charges de travail sont activées
Assurez-vous que votre cluster GKE est configuré pour activer le pipeline de collecte de métriques liées aux charges de travail en procédant comme suit :
CONSOLE
Dans Google Cloud Console, accédez à la liste des clusters GKE :
Cliquez sur le nom de votre cluster.
Dans le panneau Informations détaillées de votre cluster, vérifiez que la charge de travail est incluse dans l'état de Cloud Monitoring. Si la charge de travail n'est pas affichée ici, activez les métriques de charge de travail.
GCLOUD
Ouvrez une fenêtre de terminal avec la CLI gcloud installée. L'une des méthodes consiste à utiliser Cloud Shell.
-
Dans la console, activez Cloud Shell.
En bas de la fenêtre de la console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Exécutez cette commande :
gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
Dans la sortie de cette commande, recherchez la ligne
monitoringConfig:
. Quelques lignes plus tard, vérifiez que la sectionenableComponents:
inclutWORKLOADS
. SiWORKLOADS
n'apparaît pas ici, activez les métriques de charge de travail.
Vérifiez que les métriques sont collectées à partir de votre application
Si vous ne parvenez pas à afficher les métriques de votre application dans Cloud Monitoring, les étapes ci-dessous peuvent vous aider à résoudre les problèmes. Ces étapes utilisent un exemple d'application à des fins de démonstration, mais vous pouvez appliquer les mêmes étapes ci-dessous pour résoudre les problèmes de n'importe quelle application.
Les premières étapes ci-dessous déploient un exemple d'application que vous pouvez utiliser à des fins de test. Les étapes restantes indiquent les étapes à suivre pour résoudre les problèmes d'affichage des métriques de cette application dans Cloud Monitoring.
Créez un fichier nommé
prometheus-example-app.yaml
contenant les éléments suivants :# 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"
Initialisez les identifiants à l'aide de Google Cloud CLI afin de configurer
kubectl
:gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
Créez l'espace de noms
gke-workload-metrics
:kubectl create ns gke-workload-metrics
Déployez l'exemple d'application :
kubectl apply -f prometheus-example-app.yaml
Vérifiez que l'exemple d'application est en cours d'exécution en exécutant la commande suivante :
kubectl get pod -n gke-workload-metrics -l app=prom-example
Le résultat devrait ressembler à ceci :
NAME READY STATUS RESTARTS AGE prom-example-775d8685f4-ljlkd 1/1 Running 0 25m
Vérifiez que votre application expose les métriques comme prévu.
À l'aide de l'un des pods renvoyés par la commande ci-dessus, vérifiez que le point de terminaison des métriques fonctionne correctement :
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 vous utilisez l'exemple d'application ci-dessus, vous devriez obtenir un résultat semblable à celui-ci :
# 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 ...
Créez un fichier nommé
my-pod-monitor.yaml
contenant les éléments suivants :# 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
Créez la ressource PodMonitor :
kubectl apply -f my-pod-monitor.yaml
Une fois que vous avez créé la ressource PodMonitor, le pipeline de métriques liées aux charges de travail GKE détecte les pods appropriés et commence à les scraper automatiquement. Le pipeline envoie les métriques collectées à Cloud Monitoring.
Vérifiez que le libellé et l'espace de noms sont correctement définis dans PodMonitor. Mettez à jour les valeurs de
NAMESPACE
etSELECTOR
ci-dessous afin de refléter lenamespace
et lesmatchLabels
dans votre ressource personnalisée PodMonitor. Exécutez ensuite cette commande :NAMESPACE=gke-workload-metrics SELECTOR=app=prom-example kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
Vous devez obtenir un résultat semblable à celui-ci :
NAME READY STATUS RESTARTS AGE prom-example-7cff4db5fc-wp8lw 1/1 Running 0 39m
Vérifiez que le PodMonitor est à l'état "Ready" (Prêt).
Exécutez la commande suivante pour renvoyer tous les PodMonitors que vous avez installés dans votre cluster :
kubectl get podmonitor.monitoring.gke.io --all-namespaces
Le résultat doit ressembler à ce qui suit :
NAMESPACE NAME AGE gke-workload-metrics example 2m36s
Identifiez le PodMonitor approprié à partir de l'ensemble renvoyé et exécutez cette commande (en remplaçant
example
dans la commande ci-dessous par le nom de votre PodMonitor) :kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
Examinez les résultats renvoyés par
kubectl describe
et vérifiez que la condition "Ready" est définie sur "True". Si elle est définie sur "False", recherchez les événements qui peuvent expliquer cela.Ensuite, vous allez vérifier que ces métriques sont bien reçues par Cloud Monitoring. Dans la section Cloud Monitoring de Google Cloud Console, accédez à l'Explorateur de métriques.
Dans le champ Métrique, saisissez
example_requests_total
.Dans le menu déroulant qui s'affiche, sélectionnez
workload.googleapis.com/example_requests_total
.Cette métrique
example_requests_total
est l'une des métriques Prometheus générées par l'exemple d'application.Si le menu déroulant n'apparaît pas ou si vous ne voyez pas
workload.googleapis.com/example_requests_total
dans le menu déroulant, patientez quelques minutes, puis réessayez.Toutes les métriques sont associées à la ressource Kubernetes Container (
k8s_container
) à partir de laquelle elles sont collectées. Vous pouvez sélectionnerk8s_container
dans le champ Type de ressource de l'Explorateur de métriques. Vous pouvez également grouper par libellé, commenamespace_name
oupod_name
.Cette métrique peut être utilisée n'importe où dans Cloud Monitoring ou interrogée via l'API Cloud Monitoring. Par exemple, pour ajouter ce graphique à un tableau de bord nouveau ou existant, cliquez sur le bouton Enregistrer le graphique dans l'angle supérieur droit et sélectionnez le tableau de bord souhaité dans une boîte de dialogue.
Recherchez les erreurs d'envoi à l'API Cloud Monitoring
Les métriques envoyées à Cloud Monitoring doivent respecter les limites de métriques personnalisées. Les erreurs sont consignées dans les journaux d'audit Cloud Monitoring.
À l'aide de l'Explorateur de journaux de Cloud Logging, recherchez les journaux avec ce filtre de journal (remplacez PROJECT_ID
par le nom de votre projet) :
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
Notez que cela permet d'afficher les erreurs de toutes les écritures dans Cloud Monitoring pour le projet, et pas seulement celles de votre cluster.
Vérifiez votre quota d'ingestion Cloud Monitoring
- Accédez à la page "Quotas de l'API Cloud Monitoring".
- Sélectionnez le projet approprié.
- Développez la section Requêtes d'ingestion de séries temporelles.
- Vérifiez que le nombre d'erreurs de dépassement de quota pour le nombre de requêtes d'ingestion de séries temporelles par minute est défini sur 0. (Si c'est le cas, le graphique "Nombre d'erreurs liées au dépassement de quota" indique "Aucune donnée disponible pour la période sélectionnée".)
- Si le pourcentage d'utilisation maximale dépasse 100 %, envisagez de sélectionner moins de pods, de sélectionner moins de métriques ou de demander une limite de quota plus élevée pour le quota
monitoring.googleapis.com/ingestion_requests
.
Vérifiez que le DaemonSet est déployé
Assurez-vous que le DaemonSet des métriques liées aux charges de travail est déployé dans votre cluster. Vous pouvez vérifier que cela fonctionne comme prévu en utilisant kubectl
:
Initialisez les identifiants à l'aide de Google Cloud CLI afin de configurer
kubectl
:gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
Vérifiez que le DaemonSet des métriques liées aux charges de travail est présent et opérationnel. Exécutez la commande suivante :
kubectl get ds -n kube-system workload-metrics
Si les composants ont bien été déployés, vous obtenez un résultat semblable au suivant :
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE AGE workload-metrics 3 3 3 3 3 2m
Le nombre d'instances dupliquées ci-dessus doit correspondre au nombre de nœuds GKE Linux dans votre cluster. Par exemple, un cluster comportant trois nœuds aura
DESIRED
= 3. Après quelques minutes, les nombres deREADY
et deAVAILABLE
doivent correspondre au nombre deDESIRED
. Sinon, il peut y avoir un problème avec le déploiement.
Autres métriques
Outre les métriques système et les métriques de plan de contrôle décrites dans ce document, les métriques Istio sont également disponibles pour les clusters G K E.