Gérer les métriques GKE

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.

G​K​E 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 G​K​E (telle qu'une tâche cron ou un déploiement pour une application).

Métriques système

Lorsqu'un cluster est créé, G​K​E 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 G​K​E à Cloud Monitoring. Si vous choisissez d'envoyer des métriques à Cloud Monitoring, vous devez envoyer des métriques système.

Toutes les métriques G​K​E 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 G​K​E de Google Cloud Console. De plus, le tableau de bord G​K​E 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 à G​K​E.

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

  1. Dans Google Cloud Console, accédez à la liste des clusters G​K​E :

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom de votre cluster.

  3. Sur la ligne intitulée Cloud Monitoring, cliquez sur l'icône Modifier.

  4. Dans la boîte de dialogue Modifier Cloud Monitoring qui s'affiche, vérifiez que l'option Activer Cloud Monitoring est sélectionnée.

  5. 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.

  6. Cliquez sur OK.

  7. Cliquez sur Save Changes (Enregistrer les modifications).

GCLOUD

  1. 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 :

  2. Dans la console, activez Cloud Shell.

    Activer 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.

  3. Transmettez une ou plusieurs des valeurs API_SERVER, SCHEDULER ou CONTROLLER_MANAGER à l'option --monitoring des commandes gcloud container clusters create ou gcloud 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 :

  1. Dans la console, sélectionnez Monitoring :

    Accéder à Monitoring

  2. Dans le volet de navigation "Surveillance", cliquez sur Explorateur de métriques.

  3. Dans le champ Métrique, sélectionnez monitoring.googleapis.com/collection/attribution/write_sample_count.

  4. Cliquez sur Ajouter un filtre.

  5. Dans le champ Libellé, sélectionnez attribution_dimension.

  6. Dans le champ Comparaison, sélectionnez = (equals).

  7. Dans le champ Valeur, saisissez cluster.

  8. Cliquez sur OK.

  9. 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.

  10. 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.

  11. 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.

  12. 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 utilisateurs
apiserver_current_inflight_requests/gauge
GaugeDouble1
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 utilisateurs
apiserver_request_duration_seconds/histogram
CumulativeDistributions
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 utilisateurs
apiserver_request_total/counter
CumulativeDouble1
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 utilisateurs
apiserver_response_sizes/histogram
CumulativeDistribution1
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 utilisateurs
apiserver_storage_objects/gauge
GaugeDouble1
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 utilisateurs
apiserver_admission_controller_admission_duration_seconds/histogram
CumulativeDistributions
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 utilisateurs
apiserver_admission_step_admission_duration_seconds/histogram
CumulativeDistributions
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 utilisateurs
apiserver_admission_webhook_admission_duration_seconds/histogram
CumulativeDistributions
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 utilisateurs
scheduler_pending_pods/gauge
GaugeDouble1
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 utilisateurs
scheduler_preemption_attempts_total/counter
CumulativeDouble1
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 utilisateurs
scheduler_preemption_victims/histogram
CumulativeDistribution1
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 utilisateurs
scheduler_scheduling_attempt_duration_seconds/histogram
CumulativeDistribution1
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 utilisateurs
scheduler_schedule_attempts_total/counter
CumulativeDouble1
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 utilisateurs
node_collector_evictions_total/counter
CumulativeDouble1
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 G​K​E sont ingérées dans Cloud Monitoring avec le préfixe workload.googleapis.com.

Avantages des métriques liées aux charges de travail G​K​E :

  • 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 G​K​E Standard et G​K​E Autopilot.

Exigences

Les métriques liées aux charges de travail G​K​E nécessitent la version 1.20.8-gke.2100 ou ultérieure du plan de contrôle G​K​E et ne sont pas compatibles avec les charges de travail G​K​E 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 G​K​E existant, procédez comme suit :

CONSOLE

  1. Dans Google Cloud Console, accédez à la liste des clusters G​K​E :

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom de votre cluster.

  3. Sur la ligne intitulée "Cloud Monitoring", cliquez sur l'icône Modifier.

  4. Dans la boîte de dialogue "Modifier Cloud Monitoring" qui s'affiche, vérifiez que l'option Activer Cloud Monitoring est sélectionnée.

  5. Dans le menu déroulant, sélectionnez Charges de travail.

  6. Cliquez sur OK.

  7. Cliquez sur Save Changes (Enregistrer les modifications).

GCLOUD

  1. Ouvrez une fenêtre de terminal avec Google Cloud CLI installé. L'une des méthodes consiste à utiliser Cloud Shell.

  2. Dans la console, activez Cloud Shell.

    Activer 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.

  3. 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 commandes gcloud beta container clusters create ou gcloud 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 à G​K​E.

É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 G​K​E 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 G​K​E 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 :

  1. 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.

  2. 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 :

  1. Dans la console, sélectionnez Monitoring :

    Accéder à Monitoring

  2. Dans le volet de navigation "Surveillance", cliquez sur Explorateur de métriques.

  3. Dans le champ Métrique, sélectionnez monitoring.googleapis.com/collection/attribution/write_sample_count.

  4. 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.

  5. 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.

  6. 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 G​K​E 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 G​K​E

Pour collecter des métriques d'application dans un cluster dont la version du plan de contrôle G​K​E 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 :

  1. 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
    
  2. 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"
    
  3. 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.

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 G​K​E est configuré pour activer le pipeline de collecte de métriques liées aux charges de travail en procédant comme suit :

CONSOLE

  1. Dans Google Cloud Console, accédez à la liste des clusters G​K​E :

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom de votre cluster.

  3. 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

  1. Ouvrez une fenêtre de terminal avec la CLI gcloud installée. L'une des méthodes consiste à utiliser Cloud Shell.

  2. Dans la console, activez Cloud Shell.

    Activer 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.

  3. 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 section enableComponents: inclut WORKLOADS. Si WORKLOADS 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.

  1. 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"
    
  2. Initialisez les identifiants à l'aide de Google Cloud CLI afin de configurer kubectl :

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  3. Créez l'espace de noms gke-workload-metrics :

    kubectl create ns gke-workload-metrics
    
  4. Déployez l'exemple d'application :

    kubectl apply -f prometheus-example-app.yaml
    
  5. 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
    
  6. 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
    ...
    
  7. 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
    
  8. 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 G​K​E détecte les pods appropriés et commence à les scraper automatiquement. Le pipeline envoie les métriques collectées à Cloud Monitoring.

  9. Vérifiez que le libellé et l'espace de noms sont correctement définis dans PodMonitor. Mettez à jour les valeurs de NAMESPACE et SELECTOR ci-dessous afin de refléter le namespace et les matchLabels 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
    
  10. 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.

  11. 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.

  12. Dans le champ Métrique, saisissez example_requests_total.

  13. 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électionner k8s_container dans le champ Type de ressource de l'Explorateur de métriques. Vous pouvez également grouper par libellé, comme namespace_name ou pod_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

  1. Accédez à la page "Quotas de l'API Cloud Monitoring".
  2. Sélectionnez le projet approprié.
  3. Développez la section Requêtes d'ingestion de séries temporelles.
  4. 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".)
  5. 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 :

  1. Initialisez les identifiants à l'aide de Google Cloud CLI afin de configurer kubectl :

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  2. 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 de READY et de AVAILABLE doivent correspondre au nombre de DESIRED. 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.