Premiers pas avec la collecte gérée

Ce document explique comment configurer Google Cloud Managed Service pour Prometheus avec la collecte gérée. La configuration est un exemple minimal d'ingestion fonctionnelle utilisant un déploiement Prometheus qui surveille un exemple d'application et stocke les métriques collectées dans Monarch.

Ce document vous explique comment :

  • Configurer votre environnement et vos outils de ligne de commande
  • Configurer la collecte gérée pour votre cluster.
  • Configurer une ressource pour le scraping et l'ingestion de métriques cibles.
  • Migrer les ressources personnalisées prometheus-operator existantes.

Nous vous recommandons d'utiliser la collecte gérée qui réduit la complexité du déploiement, du scaling, de la segmentation, de la configuration et de la maintenance des collecteurs. La collecte gérée est compatible avec GKE et tous les autres environnements Kubernetes.

La collection gérée exécute les collecteurs basés sur Prometheus en tant que Daemonset et assure l'évolutivité en ne scrapant que les cibles sur des nœuds colocalisés. Vous configurez les collecteurs avec des ressources personnalisées légères afin de scraper les exportateurs à l'aide de la collection pull, puis les collecteurs transfèrent les données ainsi récupérées vers le datastore central Monarch. Google Cloud n'accède jamais directement à votre cluster pour extraire ou récupérer des données de métriques. vos collecteurs envoient des données à Google Cloud. Pour en savoir plus sur la collecte de données gérée et auto-déployée, consultez les pages Collecte des données avec le service géré pour Prometheus et Ingestion et interrogation avec une collection gérée et auto-déployée.

Avant de commencer

Cette section décrit la configuration nécessaire pour les tâches décrites dans ce document.

Configurer des projets et des outils

Pour utiliser Google Cloud Managed Service pour Prometheus, vous avez besoin des ressources suivantes :

  • Un projet Google Cloud avec l'API Cloud Monitoring activée.

    • Si vous n'avez pas de projet Google Cloud, procédez comme suit :

      1. Dans la console Google Cloud, accédez à Nouveau projet :

        Créer un projet

      2. Dans le champ Nom du projet, saisissez un nom pour votre projet, puis cliquez sur Créer.

      3. Accéder à la page Facturation :

        Accéder à Facturation

      4. Sélectionnez le projet que vous venez de créer s'il n'est pas déjà sélectionné en haut de la page.

      5. Vous êtes invité à choisir un profil de paiement existant ou à en créer un.

      L'API Monitoring est activée par défaut pour les nouveaux projets.

    • Si vous disposez déjà d'un projet Google Cloud, assurez-vous que l'API Monitoring est activée :

      1. Accédez à la page API et services :

        Accéder à API et services

      2. Sélectionnez votre projet.

      3. Cliquez sur Enable APIs and Services (Activer les API et les services).

      4. Recherchez "Monitoring".

      5. Dans les résultats de recherche, cliquez sur "API Cloud Monitoring".

      6. Si l'option "API activée" ne s'affiche pas, cliquez sur le bouton Activer.

  • Un cluster Kubernetes. Si vous ne disposez pas de cluster Kubernetes, suivez les instructions du guide de démarrage rapide pour GKE.

Vous avez également besoin des outils de ligne de commande suivants :

  • gcloud
  • kubectl

Les outils gcloud et kubectl font partie de Google Cloud CLI. Pour en savoir plus sur leur installation, consultez la page Gérer les composants de Google Cloud CLI. Pour afficher les composants de la CLI gcloud que vous avez installés, exécutez la commande suivante :

gcloud components list

Configurer votre environnement

Pour éviter de saisir à plusieurs reprises l'ID de votre projet ou le nom de votre cluster, effectuez la configuration suivante :

  • Configurez les outils de ligne de commande comme suit :

    • Configurez limited-feature mode pour faire référence à l'ID de votre projet Google Cloud :

      gcloud config set project PROJECT_ID

    • Configurez la CLI kubectl pour utiliser votre cluster :

      kubectl config set-cluster CLUSTER_NAME

    Pour en savoir plus sur ces outils, consultez les articles suivants :

Configurer un espace de noms

Créez l'espace de noms Kubernetes NAMESPACE_NAME pour les ressources que vous créez dans le cadre de l'exemple d'application :

kubectl create ns NAMESPACE_NAME

Configurer la collecte gérée

Vous pouvez utiliser la collecte gérée sur les clusters Kubernetes GKE et non-GKE.

Une fois la collecte gérée activée, les composants intégrés au cluster s'exécutent, mais aucune métrique n'est encore générée. Les ressources PodMonitoring ou ClusterPodMonitoring sont nécessaires à ces composants afin de scraper correctement les points de terminaison des métriques. Vous devez déployer ces ressources avec des points de terminaison de métriques valides, ou activer l'un des packages de métriques gérés intégrés à GKE, comme par exemple Kube State Metrics. Pour en savoir plus, consultez la section Problèmes côté ingestion.

L'activation de la collecte gérée installe les composants suivants dans votre cluster :

Pour obtenir une documentation de référence sur l'opérateur du service géré pour Prometheus, consultez la page des fichiers manifestes.

Activer la collecte gérée : GKE

La collecte gérée est activée par défaut pour les éléments suivants :

Si vous exécutez dans un environnement GKE qui n'active pas la collecte gérée par défaut, vous pouvez activer la collecte gérée manuellement.

La collecte gérée sur GKE est automatiquement mise à niveau lorsque de nouvelles versions des composants au sein du cluster sont disponibles.

La collecte gérée sur GKE utilise des autorisations accordées au compte de service Compute Engine par défaut. Si vous disposez d'une règle qui modifie les autorisations standards sur le compte de service de nœud par défaut, vous devrez peut-être ajouter le rôle Monitoring Metric Writer pour continuer.

Activer manuellement la collecte gérée

Si vous exécutez dans un environnement GKE qui n'active pas la collecte gérée par défaut, vous pouvez activer la collecte gérée en procédant comme suit :

  • Le tableau de bord des clusters GKE dans Cloud Monitoring.
  • La page Kubernetes Engine dans la console Google Cloud.
  • Google Cloud CLI. Pour utiliser gcloud CLI, vous devez exécuter GKE version 1.21.4-gke.300 ou ultérieure.

  • Terraform pour Google Kubernetes Engine Pour utiliser Terraform afin d'activer le service géré pour Prometheus, vous devez exécuter GKE version 1.21.4-gke.300 ou ultérieure.

Tableau de bord des clusters GKE

Vous pouvez effectuer les opérations suivantes à l'aide du tableau de bord GKE Clusters (clusters GKE) dans Cloud Monitoring.

  • Déterminez si Managed Service for Prometheus est activé sur vos clusters et si vous utilisez une collection gérée ou auto-déployée.
  • Activez la collecte gérée sur les clusters dans votre projet.
  • Affichez d'autres informations sur vos clusters.

Pour afficher le tableau de bord GKE Clusters (clusters GKE), procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Tableaux de bord .

    Accéder à la page Tableaux de bord

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Sélectionnez la catégorie de tableau de bord GCP, puis GKE Clusters (clusters GKE).

Le tableau de bord des clusters GKE dans Cloud Monitoring.

Pour activer la collecte gérée sur un ou plusieurs clusters GKE à l'aide du tableau de bord des clusters GKE, procédez comme suit :

  1. Cochez la case associée à chaque cluster GKE sur lequel vous souhaitez activer la collecte gérée.

  2. Sélectionnez Activer la sélection.

Interface utilisateur de Kubernetes Engine

Vous pouvez effectuer les opérations suivantes à l'aide de la console Google Cloud :

  • Activer la collecte gérée sur un cluster GKE existant
  • Créer un cluster GKE avec la collecte gérée activée

Pour mettre à jour un cluster existant, procédez comme suit :

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page Clusters Kubernetes

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

  2. Cliquez sur le nom du cluster.

  3. Dans la liste Fonctionnalités, recherchez l'option Service géré pour Prometheus. Si elle est désactivée, cliquez sur Modifier, puis sélectionnez Activer le service géré pour Prometheus.

  4. Cliquez sur Enregistrer les modifications.

Pour créer un cluster avec la collecte gérée activée, procédez comme suit :

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page Clusters Kubernetes

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

  2. Cliquez sur Créer.

  3. Cliquez sur Configurer pour l'option Standard.

  4. Dans le panneau de navigation, cliquez sur Fonctionnalités.

  5. Dans la section Opérations, sélectionnez Activer le service géré pour Prometheus.

  6. Cliquez sur Enregistrer.

CLI gcloud

Vous pouvez effectuer les opérations suivantes en utilisant la CLI gcloud :

  • Activer la collecte gérée sur un cluster GKE existant
  • Créer un cluster GKE avec la collecte gérée activée

L'exécution de ces commandes peut prendre jusqu'à cinq minutes.

Tout d'abord, définissez votre projet :

gcloud config set project PROJECT_ID

Pour mettre à jour un cluster existant, exécutez l'une des commandes update suivantes, selon que votre cluster est zonal ou régional :

  • gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --zone ZONE

  • gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --region REGION

Pour créer un cluster avec la collecte gérée activée, exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus

GKE Autopilot

La collecte gérée est activée par défaut dans les clusters GKE Autopilot exécutant GKE version 1.25 ou ultérieure. Vous ne pouvez pas désactiver la collecte gérée.

Si votre cluster ne parvient pas à activer automatiquement la collecte gérée lors de la mise à niveau vers la version 1.25, vous pouvez l'activer manuellement en exécutant la commande "update" dans la section de la gcloud CLI.

Terraform

Pour obtenir des instructions sur la configuration de la collecte gérée à l'aide de Terraform, consultez le registre Terraform pour google_container_cluster.

Pour obtenir des informations générales sur l'utilisation de Google Cloud avec Terraform, consultez la page Terraform avec Google Cloud.

Désactiver la collecte gérée

Si vous souhaitez désactiver la collecte gérée sur vos clusters, vous pouvez utiliser l'une des méthodes suivantes :

Interface utilisateur de Kubernetes Engine

Vous pouvez effectuer les opérations suivantes à l'aide de la console Google Cloud :

  • Désactiver la collecte gérée sur un cluster GKE existant
  • Ignorer l'activation automatique de la collecte gérée lors de la création d'un cluster GKE Standard exécutant GKE version 1.27 ou ultérieure.

Pour mettre à jour un cluster existant, procédez comme suit :

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page Clusters Kubernetes

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

  2. Cliquez sur le nom du cluster.

  3. Dans la section Fonctionnalités, recherchez l'option Service géré pour Prometheus. Cliquez sur  Modifier et décochez Activer Managed Service pour Prometheus.

  4. Cliquez sur Enregistrer les modifications.

Pour ignorer l'activation automatique de la collecte gérée lors de la création d'un cluster GKE Standard (version 1.27 ou ultérieure), procédez comme suit :

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page Clusters Kubernetes

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

  2. Cliquez sur Créer.

  3. Cliquez sur Configurer pour l'option Standard.

  4. Dans le panneau de navigation, cliquez sur Fonctionnalités.

  5. Dans la section Opérations, effacez Activer le service géré pour Prometheus.

  6. Cliquez sur Enregistrer.

CLI gcloud

Vous pouvez effectuer les opérations suivantes en utilisant la CLI gcloud :

  • Désactiver la collecte gérée sur un cluster GKE existant
  • Ignorer l'activation automatique de la collecte gérée lors de la création d'un cluster GKE Standard exécutant GKE version 1.27 ou ultérieure.

L'exécution de ces commandes peut prendre jusqu'à cinq minutes.

Tout d'abord, définissez votre projet :

gcloud config set project PROJECT_ID

Pour désactiver la collecte gérée sur un cluster existant, exécutez l'une des commandes update suivantes, selon que votre cluster est zonal ou régional :

  • gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --zone ZONE

  • gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --region REGION

Pour ignorer l'activation automatique de la collecte gérée lors de la création d'un cluster GKE Standard (version 1.27 ou ultérieure), exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus

GKE Autopilot

Vous ne pouvez pas désactiver la collecte gérée dans les clusters GKE Autopilot exécutant GKE version 1.25 ou ultérieure.

Terraform

Pour désactiver la collecte gérée, définissez l'attribut enabled dans le bloc de configuration managed_prometheus sur false. Pour en savoir plus sur ce bloc de configuration, consultez le registre Terraform pour google_container_cluster.

Pour obtenir des informations générales sur l'utilisation de Google Cloud avec Terraform, consultez la page Terraform avec Google Cloud.

Activer la collecte gérée : Kubernetes hors GKE

Si vous exécutez dans un environnement autre que GKE, vous pouvez activer la collecte gérée à l'aide des éléments suivants :

  • La CLI kubectl.

  • La solution groupée incluse dans les déploiements GKE Enterprise exécutant la version 1.12 ou ultérieure.

CLI kubectl

Pour installer des collecteurs gérés lorsque vous utilisez un cluster Kubernetes hors GKE, exécutez les commandes suivantes pour installer les fichiers manifestes d'installation et d'opérateur :

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/setup.yaml

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

GKE Enterprise

Pour en savoir plus sur la configuration de la collecte gérée pour les clusters GKE Enterprise, consultez la documentation concernant votre distribution :

Déployer l'exemple d'application

L'exemple d'application émet la métrique de compteur example_requests_total et la métrique d'histogramme example_random_numbers (entre autres) sur son port metrics. Le fichier manifeste de l'application définit trois instances répliquées.

Pour déployer l'exemple d'application, exécutez la commande suivante :

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/example-app.yaml

Configurer une ressource PodMonitoring

Pour ingérer les données de métriques émises par l'exemple d'application, Managed Service pour Prometheus utilise le scraping cible. Le scraping et l'ingestion des métriques cibles sont configurées à l'aide des ressources personnalisées Kubernetes. Le service géré utilise des ressources personnalisées PodMonitoring.

Une RS PodMonitoring ne scrape les cibles que dans l'espace de noms dans lequel la RS est déployée. Pour scraper des cibles dans plusieurs espaces de noms, déployez la même RS PodMonitoring dans chaque espace de noms. Vous pouvez vérifier que la ressource PodMonitoring est installée dans l'espace de noms prévu en exécutant la commande kubectl get podmonitoring -A.

Pour obtenir une documentation de référence sur toutes les ressources personnalisées Managed Service pour Prometheus, consultez la documentation prometheus-engine/doc/api reference.

Le fichier manifeste suivant définit une ressource PodMonitoring, prom-example, dans l'espace de noms NAMESPACE_NAME. La ressource utilise un sélecteur de libellés Kubernetes pour rechercher tous les pods de l'espace de noms portant le libellé app.kubernetes.io/name avec la valeur prom-example. Les pods correspondants sont récupérés sur un port nommé metrics, toutes les 30 secondes, sur le chemin HTTP /metrics.

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s

Pour appliquer cette ressource, exécutez la commande suivante :

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/pod-monitoring.yaml

Votre collecteur géré scrape désormais les pods correspondants. Vous pouvez afficher l'état de votre cible de scraping en activant la fonctionnalité d'état cible.

Pour configurer la collecte horizontale qui s'applique à une plage de pods sur tous les espaces de noms, utilisez la ressource ClusterPodMonitoring. La ressource ClusterPodMonitoring fournit la même interface que la ressource PodMonitoring, mais ne limite pas les pods détectés à un espace de noms donné.

Si vous utilisez GKE, vous pouvez procéder comme suit :

Si vous procédez à l'exécution en dehors de GKE, vous devez créer un compte de service et l'autoriser à écrire vos données de métrique, comme décrit dans la section suivante.

Fournir des identifiants de manière explicite

Lors de l'exécution sur GKE, le serveur Prometheus de collecte récupère automatiquement les identifiants de l'environnement en fonction du compte de service du nœud. Dans les clusters Kubernetes non GKE, les identifiants doivent être explicitement fournis via la ressource OperatorConfig dans l'espace de noms gmp-public.

  1. Définissez le contexte de votre projet cible :

    gcloud config set project PROJECT_ID

  2. Créez un compte de service :

    gcloud iam service-accounts create gmp-test-sa

  3. Accordez les autorisations requises au compte de service :

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. Créez et téléchargez une clé pour le compte de service :

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. Ajoutez le fichier de clé en tant que secret à votre cluster non-GKE :

    kubectl -n gmp-public create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Ouvrez la ressource OperatorConfig pour la modifier :

    kubectl -n gmp-public edit operatorconfig config

    1. Ajoutez le texte affiché en gras à la ressource :

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
collection:
  credentials:
    name: gmp-test-sa
    key: key.json
      Veillez également à ajouter ces identifiants à la section rules pour que l'évaluation des règles gérées fonctionne.

    2. Enregistrez le fichier et fermez l'éditeur. Une fois la modification appliquée, les pods sont recréés et commencent à s'authentifier auprès du backend de métrique avec le compte de service donné.

    Autres sujets sur la collecte gérée

    Cette page explique comment effectuer les opérations suivantes :

    • Activer la fonctionnalité d'état cible pour faciliter le débogage.
    • Configurer le scraping cible à l'aide de Terraform.
    • Filtrer les données que vous exportez vers le service géré.
    • Récupérer les métriques Kubelet et cAdvisor.
    • Convertir vos ressources prom-operator existantes pour les utiliser avec le service géré.
    • Exécuter une collecte gérée en dehors de GKE.

    Activer la fonctionnalité d'état cible

    Vous pouvez vérifier l'état de vos cibles dans vos ressources PodMonitoring ou ClusterPodMonitoring en définissant la valeur features.targetStatus.enabled dans la ressource OperatorConfig sur true, comme indiqué ci-dessous :

        apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    features:
      targetStatus:
        enabled: true

    Après quelques secondes, le champ Status.Endpoint Statuses s'affiche sur chaque ressource PodMonitoring ou ClusterPodMonitoring valide, lorsqu'il est configuré.

    Si vous disposez d'une ressource PodMonitoring nommée prom-example dans l'espace de noms NAMESPACE_NAME, vous pouvez vérifier l'état en exécutant la commande suivante :

    kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example

    La sortie ressemble à ceci :

    API Version:  monitoring.googleapis.com/v1
Kind:         PodMonitoring
...
Status:
  Conditions:
    ...
    Status:                True
    Type:                  ConfigurationCreateSuccess
  Endpoint Statuses:
    Active Targets:       3
    Collectors Fraction:  1
    Last Update Time:     2023-08-02T12:24:26Z
    Name:                 PodMonitoring/custom/prom-example/metrics
    Sample Groups:
      Count:  3
      Sample Targets:
        Health:  up
        Labels:
          Cluster:                     CLUSTER_NAME
          Container:                   prom-example
          Instance:                    prom-example-589ddf7f7f-hcnpt:metrics
          Job:                         prom-example
          Location:                    REGION
          Namespace:                   NAMESPACE_NAME
          Pod:                         prom-example-589ddf7f7f-hcnpt
          project_id:                  PROJECT_ID
        Last Scrape Duration Seconds:  0.020206416
        Health:                        up
        Labels:
          ...
        Last Scrape Duration Seconds:  0.054189485
        Health:                        up
        Labels:
          ...
        Last Scrape Duration Seconds:  0.006224887

    Le résultat inclut les champs d'état suivants :

    • Status.Conditions.Status est défini lorsque Managed Service pour Prometheus accuse réception et traite PodPodMonitoring.
    • Status.Endpoint Statuses.Active Targets indique le nombre de cibles de scrape que Managed Service pour Prometheus compte sur tous les collecteurs de cette ressource PodMonitoring. Dans l'exemple d'application, le déploiement prom-example possède trois instances répliquées avec une seule cible de métrique. La valeur est donc 3. En cas de cibles non opérationnelles, le champ Status.Endpoint Statuses.Unhealthy Targets s'affiche.
    • Status.Endpoint Statuses.Collectors Fraction affiche la valeur 1 (100%) si tous les collecteurs gérés sont accessibles à Managed Service pour Prometheus.
    • Status.Endpoint Statuses.Last Update Time indique la date et l'heure de la dernière mise à jour. Lorsque l'heure de la dernière mise à jour est beaucoup plus longue que l'intervalle de scraping souhaité, la différence peut indiquer des problèmes liés à votre cible ou à votre cluster.
    • Le champ Status.Endpoint Statuses.Sample Groups présente des exemples de cibles regroupées par étiquettes cibles courantes injectées par le collecteur. Cette valeur est utile pour déboguer les situations dans lesquelles vos cibles ne sont pas découvertes. Si toutes les cibles sont opérationnelles et collectées, la valeur attendue du champ Health est up et la valeur du champ Last Scrape Duration Seconds est la durée habituelle d'une cible type.

    Pour en savoir plus sur ces champs, consultez le document de l'API Managed Service pour Prometheus.

    L'un des éléments suivants peut indiquer un problème avec votre configuration :

    • Le champ Status.Endpoint Statuses est absent de votre ressource PodMonitoring.
    • La valeur du champ Last Scrape Duration Seconds est trop ancienne.
    • Trop peu de cibles sont visibles.
    • La valeur du champ Health indique que la cible est down.

    Pour en savoir plus sur le débogage des problèmes de découverte des cibles, consultez la section Problèmes côté ingestion dans la documentation de dépannage.

    Configurer un point de terminaison de scraping autorisé

    Si votre cible de scraping nécessite une autorisation, vous pouvez configurer le collecteur pour qu'il utilise le type d'autorisation approprié et fournisse les secrets pertinents.

    Google Cloud Managed Service pour Prometheus est compatible avec les types d'autorisations suivants :

    mTLS

    mTLS est couramment configuré dans les environnements zéro confiance, tels que le maillage de services Istio ou Cloud Service Mesh.

    Pour activer le scraping des points de terminaison sécurisés à l'aide de mTLS, définissez le champ Spec.Endpoints[].Scheme de votre ressource PodMonitoring sur https. Bien que cette option ne soit pas recommandée, vous pouvez définir le champ Spec.Endpoints[].insecureSkipVerify de votre ressource PodMonitoring sur true pour ignorer la validation de l'autorité de certification. Vous pouvez également configurer Managed Service pour Prometheus afin de charger des certificats et des clés à partir de ressources de secret.

    Par exemple, la ressource Secret suivante contient des clés pour les certificats client (cert), de clé privée (key) et d'autorité de certification (ca) :

    kind: Secret
metadata:
  name: secret-example
stringData:
  cert: ********
  key: ********
  ca: ********

    Accordez au collecteur Managed Service pour Prometheus l'autorisation d'accéder à cette ressource Secret :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Sur les clusters GKE Autopilot, cela se présente comme suit :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Pour configurer une ressource PodMonitoring utilisant la ressource Secret précédente, modifiez-la pour ajouter une section scheme et tls :

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    scheme: https
    tls:
      ca:
        secret:
          name: secret-example
          key: ca
      cert:
        secret:
          name: secret-example
          key: cert
      key:
        secret:
          name: secret-example
          key: key

    Pour obtenir une documentation de référence sur toutes les options mTLS de Managed Service pour Prometheus, consultez la documentation de référence de l'API.

    BasicAuth

    Pour activer le scraping des points de terminaison sécurisés à l'aide de BasicAuth, définissez le champ Spec.Endpoints[].BasicAuth de votre ressource PodMonitoring avec votre nom d'utilisateur et votre mot de passe. Pour les autres types d'en-têtes d'autorisation HTTP, consultez la section En-tête d'autorisation HTTP.

    Par exemple, la ressource Secret suivante contient une clé permettant de stocker le mot de passe :

    kind: Secret
metadata:
  name: secret-example
stringData:
  password: ********

    Accordez au collecteur Managed Service pour Prometheus l'autorisation d'accéder à cette ressource Secret :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Sur les clusters GKE Autopilot, cela se présente comme suit :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Pour configurer une ressource PodMonitoring qui utilise la ressource Secret précédente et le nom d'utilisateur foo, modifiez votre ressource pour ajouter une section basicAuth :

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    basicAuth:
      username: foo
      password:
        secret:
          name: secret-example
          key: password

    Pour obtenir une documentation de référence sur toutes les options BasicAuth de Managed Service pour Prometheus, consultez la documentation de référence de l'API.

    En-tête de l'autorisation HTTP

    Pour activer le scraping des points de terminaison sécurisés à l'aide des en-têtes d'autorisation HTTP, définissez le champ Spec.Endpoints[].Authorization de votre ressource PodMonitoring avec le type et les identifiants. Pour les points de terminaison BasicAuth, utilisez plutôt la configuration BasicAuth.

    Par exemple, la ressource Secret suivante contient une clé permettant de stocker les identifiants :

    kind: Secret
metadata:
  name: secret-example
stringData:
  credentials: ********

    Accordez au collecteur Managed Service pour Prometheus l'autorisation d'accéder à cette ressource Secret :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Sur les clusters GKE Autopilot, cela se présente comme suit :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Pour configurer une ressource PodMonitoring qui utilise la ressource Secret précédente et un type de Bearer, modifiez votre ressource pour ajouter une section authorization :

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    authorization:
      type: Bearer
      credentials:
        secret:
          name: secret-example
          key: credentials

    Pour obtenir une documentation de référence sur toutes les options d'en-tête d'autorisation HTTP de Managed Service pour Prometheus, consultez la documentation de référence de l'API.

    OAuth 2

    Pour activer le scraping des points de terminaison sécurisés à l'aide d'OAuth 2, vous devez définir le champ Spec.Endpoints[].OAuth2 dans votre ressource PodMonitoring.

    Par exemple, la ressource Secret suivante contient une clé permettant de stocker le code secret du client :

    kind: Secret
metadata:
  name: secret-example
stringData:
  clientSecret: ********

    Accordez au collecteur Managed Service pour Prometheus l'autorisation d'accéder à cette ressource Secret :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Sur les clusters GKE Autopilot, cela se présente comme suit :

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Pour configurer une ressource PodMonitoring qui utilise la ressource Secret précédente avec un ID client de foo et une URL de jeton de example.com/token, modifiez votre ressource pour ajouter une section oauth2 :

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    oauth2:
      clientID: foo
      clientSecret:
        secret:
          name: secret-example
          key: password
      tokenURL: example.com/token

    Pour obtenir une documentation de référence sur toutes les options OAuth 2 de Managed Service pour Prometheus, consultez la documentation de référence de l'API.

    Configurer le scraping cible à l'aide de Terraform

    Vous pouvez automatiser la création et la gestion de ressources PodMonitoring et ClusterPodMonitoring à l'aide du type de ressource Terraform kubernetes_manifest ou du type de ressource Terraform kubectl_manifest, qui vous permettent de spécifier des ressources personnalisées arbitraires.

    Pour obtenir des informations générales sur l'utilisation de Google Cloud avec Terraform, consultez la page Terraform avec Google Cloud.

    Filtrer les métriques exportées

    Si vous collectez une grande quantité de données, vous pouvez empêcher l'envoi de certaines séries temporelles au service géré pour Prometheus afin de limiter les coûts. Vous pouvez pour cela utiliser les règles de réécriture de libellés Prometheus avec une action keep pour une liste d'autorisation ou une action drop pour une liste de blocage. Pour la collecte gérée, cette règle se trouve dans la section metricRelabeling de votre ressource PodMonitoring ou ClusterPodMonitoring.

    Par exemple, la règle de réécriture de libellés de métrique suivante filtre toutes les métriques commençant par foo_bar_, foo_baz_ ou foo_qux_ :

      metricRelabeling:
  - action: drop
    regex: foo_(bar|baz|qux)_.+
    sourceLabels: [__name__]

    La page Gestion des métriques de Cloud Monitoring fournit des informations qui peuvent vous aider à contrôler les sommes que vous consacrez aux métriques facturables, sans affecter l'observabilité. La page Gestion des métriques fournit les informations suivantes :

    • Les volumes d'ingestion pour la facturation à base d'octets et celle à base d'exemples, englobant les différents domaines de métriques et des métriques individuelles
    • Les données sur les libellés et la cardinalité des métriques
    • Nombre de lectures pour chaque métrique.
    • L'utilisation de métriques dans les règles d'alerte et les tableaux de bord personnalisés
    • Les taux d'erreurs d'écriture de métriques

    Vous pouvez également utiliser la gestion des métriques pour exclure les métriques inutiles, ce qui élimine le coût de leur ingestion. Pour en savoir plus sur la Gestion des métriques, consultez la section Afficher et gérer l'utilisation des métriques.

    Pour découvrir d'autres suggestions permettant de réduire vos coûts, consultez la section Contrôle et attribution des coûts.

    Récupérer les métriques Kubelet et cAdvisor

    Le Kubelet expose des métriques sur lui-même ainsi que des métriques cAdvisor sur les conteneurs s'exécutant sur son nœud. Vous pouvez configurer la collecte gérée pour récupérer les métriques Kubelet et cAdvisor en modifiant la ressource OperatorConfig. Pour obtenir des instructions, consultez la documentation de l'exportateur pour Kubelet et cAdvisor.

    Convertir les ressources prometheus-operator existantes

    Vous pouvez généralement convertir vos ressources d'opérateur Prometheus en ressources PodMonitoring et ClusterPodMonitoring de la collection gérée des services gérés pour Prometheus.

    Par exemple, la ressource ServiceMonitor définit la surveillance d'un ensemble de services. La ressource PodMonitoring diffuse un sous-ensemble des champs diffusés par la ressource ServiceMonitor. Vous pouvez convertir une ressource personnalisée ServiceMonitor en ressource personnalisée PodMonitoring en mappant les champs comme décrit dans le tableau suivant :

    monitoring.coreos.com/v1
    ServiceMonitor     		Compatibilité
         		 monitoring.googleapis.com/v1
    PodMonitoring
    .ServiceMonitorSpec.Selector Identiques .PodMonitoringSpec.Selector
    .ServiceMonitorSpec.Endpoints[] .TargetPort correspond à .Port
    .Path: compatible
    .Interval: compatible
    .Timeout: compatible     		.PodMonitoringSpec.Endpoints[]
    .ServiceMonitorSpec.TargetLabels PodMonitor doit spécifier :
    .FromPod[].From libellé du pod
    .FromPod[].To libellé cible     		.PodMonitoringSpec.TargetLabels

    Voici un exemple de ressource personnalisée ServiceMonitor ; le contenu en gras est remplacé dans la conversion, et le contenu en italique est mappé directement :

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - targetPort: web
    path: /stats
    interval: 30s
  targetLabels:
  - foo

    Voici la ressource personnalisée PodMonitoring analogue, en supposant que votre service et ses pods possèdent le libellé app=example-app. Si cette hypothèse ne s'applique pas, vous devez utiliser les sélecteurs de libellés de la ressource de service sous-jacente.

    Le contenu en gras a été remplacé dans la conversion :

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web
    path: /stats
    interval: 30s
  targetLabels:
    fromPod:
    - from: foo # pod label from example-app Service pods.
      to: foo

    Vous pouvez toujours utiliser vos ressources d'opérateur et configurations de déploiement Prometheus existantes à l'aide de collecteurs auto-déployés plutôt que de collecteurs gérés. Vous pouvez interroger les métriques envoyées par les deux types de collecteurs. Il est donc préférable d'utiliser des collecteurs auto-déployés pour vos déploiements Prometheus existants tout en utilisant des collecteurs gérés pour les nouveaux déploiements Prometheus.

    Libellés réservés

    Managed Service pour Prometheus ajoute automatiquement les libellés suivants à toutes les métriques collectées. Ces libellés permettent d'identifier de manière unique une ressource dans Monarch :

    • project_id : identifiant du projet Google Cloud associé à votre métrique.
    • location : emplacement physique (région Google Cloud) dans lequel les données sont stockées. Cette valeur correspond généralement à la région de votre cluster GKE. Si les données sont collectées à partir d'un déploiement AWS ou sur site, la valeur peut être la région Google Cloud la plus proche.
    • cluster : nom du cluster Kubernetes associé à la métrique.
    • namespace : nom de l'espace de noms Kubernetes associé à la métrique.
    • job : libellé de la tâche de la cible Prometheus, si elle est connue. Il peut être vide pour les résultats d'évaluation de règles.
    • instance : libellé d'instance de la cible Prometheus, si elle est connue. Il peut être vide pour les résultats d'évaluation de règles.

    Bien que cela ne soit pas recommandé lors de l'exécution sur Google Kubernetes Engine, vous pouvez ignorer les libellés project_id, location et cluster en les ajoutant en tant qu'args à la ressource de déploiement dans operator.yaml. Si vous utilisez des libellés réservés en tant que libellés de métriques, Managed Service pour Prometheus les réécrit automatiquement en ajoutant le préfixe exported_. Ce comportement correspond à la manière dont Prometheus gère en amont les conflits avec les libellés réservés.

    Configurations de compression

    Si vous disposez de nombreuses ressources PodMonitoring, vous risquez de manquer d'espace ConfigMap. Pour résoudre ce problème, activez la compression gzip dans votre ressource OperatorConfig :

      apiVersion: monitoring.googleapis.com/v1
  kind: OperatorConfig
  metadata:
    namespace: gmp-public
    name: config
  features:
    config:
      compression: gzip

    Activer l'autoscaling vertical des pods (VPA) pour la collection gérée

    Si vous rencontrez des erreurs de mémoire insuffisante (OOM) pour les pods de collecteur de votre cluster ou si les demandes et les limites de ressources par défaut des collecteurs ne répondent pas à vos besoins, vous pouvez utiliser l'autoscaling vertical des pods pour allouer des ressources de manière dynamique.

    Lorsque vous définissez le champ scaling.vpa.enabled: true sur la ressource OperatorConfig, l'opérateur déploie un fichier manifeste VerticalPodAutoscaling dans le cluster qui permet de définir automatiquement les requêtes et les limites de ressources des pods de collecte en fonction de l'utilisation.

    Pour activer le VPA pour les pods de collecteur dans Managed Service pour Prometheus, exécutez la commande suivante :

    kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge

    Si la commande aboutit, l'opérateur configure l'auto-scaling vertical des pods de collecteur. Les erreurs de mémoire insuffisante entraînent une augmentation immédiate des limites de ressources. S'il n'y a pas d'erreurs OOM, le premier ajustement des demandes de ressources et des limites des pods de collecteurs a généralement lieu sous 24 heures.

    Vous pouvez recevoir ce message d'erreur lorsque vous essayez d'activer le VPA :

    vertical pod autoscaling is not available - install vpa support and restart the operator

    Pour résoudre cette erreur, vous devez d'abord activer l'autoscaling vertical des pods au niveau du cluster :

    1. Accédez à la page des Kubernetes Engine : clusters dans la console Google Cloud.

      Dans la console Cloud Console, accédez à la page des clusters Kubernetes.

      Accéder à la page Clusters Kubernetes

      Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

    2. Sélectionnez le cluster que vous souhaitez modifier.

    3. Dans la section Automatisation, modifiez la valeur de l'option Autoscaling vertical des pods.

    4. Cochez la case Activer l'autoscaling vertical des pods, puis cliquez sur Enregistrer les modifications. Cette modification redémarre votre cluster. L'opérateur redémarre dans le cadre de ce processus.

    5. Réessayez la commande suivante : kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge pour activer le VPA pour Managed Service pour Prometheus.

    Pour vérifier que la ressource OperatorConfig a bien été modifiée, ouvrez-la à l'aide de la commande kubectl -n gmp-public edit operatorconfig config. Si l'opération aboutit, votre OperatorConfig inclut la section suivante en gras :

    apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
scaling:
  vpa:
    enabled: true

    L'autoscaling vertical des pods fonctionne mieux lorsque vous ingérez un nombre constant d'échantillons, répartis de manière égale sur les nœuds. Si la charge des métriques est irrégulière ou présente des pics, ou si la charge des métriques varie considérablement entre les nœuds, le VPA peut ne pas être une solution efficace.

    Pour en savoir plus, consultez la section Autoscaling vertical des pods dans GKE.

    Suppression

    Pour désactiver la collecte gérée déployée à l'aide de gcloud ou de l'interface utilisateur de GKE, vous pouvez effectuer l'une des opérations suivantes :

    • Exécutez la commande suivante :

      gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus

    • Utilisez l'interface utilisateur GKE :

      1. Dans la console Google Cloud, sélectionnez Kubernetes Engine, puis Clusters.

      2. Recherchez le cluster pour lequel vous souhaitez désactiver la collecte gérée et cliquez sur son nom.

      3. Dans l'onglet Détails, faites défiler la page jusqu'à Fonctionnalités, puis définissez l'état sur Désactivé à l'aide du bouton de modification.

    Pour désactiver la collecte gérée déployée à l'aide de Terraform, spécifiez enabled = false dans la section managed_prometheus de la ressource google_container_cluster.

    Pour désactiver la collecte gérée déployée à l'aide de kubectl, exécutez la commande suivante :

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

    La désactivation de la collecte gérée empêche votre cluster d'envoyer de nouvelles données à Managed Service pour Prometheus. Cette action ne supprime pas les données de métriques existantes déjà stockées dans le système.

    La désactivation de la collecte gérée supprime également l'espace de noms gmp-public et toutes les ressources qu'il contient, y compris les exportateurs installés dans cet espace de noms.

    Exécuter une collecte gérée en dehors de GKE

    Dans les environnements GKE, vous pouvez exécuter la collecte gérée sans configuration supplémentaire. Dans d'autres environnements Kubernetes, vous devez fournir explicitement les identifiants, une valeur project-id pour contenir vos métriques, une valeur location (région Google Cloud) où vos métriques seront stockées et une valeur cluster pour enregistrer le nom du cluster dans lequel le collecteur s'exécute.

    Comme gcloud ne fonctionne pas en dehors des environnements Google Cloud, vous devez déployer à l'aide de kubectl. Contrairement à gcloud, le déploiement d'une collecte gérée à l'aide de kubectl ne met pas automatiquement à niveau votre cluster lorsqu'une nouvelle version est disponible. N'oubliez pas de consulter la page des versions pour connaître les nouvelles versions, et effectuez une mise à niveau manuelle en exécutant à nouveau les commandes kubectl avec la nouvelle version.

    Vous pouvez fournir une clé de compte de service en modifiant la ressource OperatorConfig dans operator.yaml, comme décrit dans la section Fournir des identifiants explicitement. Vous pouvez fournir les valeurs project-id, location et cluster en les ajoutant en tant que args à la ressource Deployment dans operator.yaml.

    Nous vous recommandons de choisir project-id en fonction de votre modèle de location planifié pour les lectures. Choisissez un projet dans lequel stocker les métriques en fonction de la manière dont vous envisagez d'organiser les lectures par la suite via des champs d'application de métriques. Si cela n'a aucune importance pour vous, vous pouvez tout regrouper dans un même projet.

    Pour location, nous vous recommandons de choisir la région Google Cloud la plus proche de votre déploiement. Plus la région Google Cloud choisie est éloignée de votre déploiement, plus la latence d'écriture sera importante, et plus vous risquez d'être affecté par d'éventuels problèmes de réseau. Vous pouvez consulter cette liste des régions couvrant plusieurs clouds. Si cela n'a pas d'importance à vos yeux, vous pouvez tout déployer dans une seule région Google Cloud. Vous ne pouvez pas utiliser global comme emplacement.

    Pour cluster, nous vous recommandons de choisir le nom du cluster dans lequel l'opérateur est déployé.

    Lorsqu'elle est correctement configurée, votre ressource OperatorConfig doit ressembler à ceci :

        apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    collection:
      credentials:
        name: gmp-test-sa
        key: key.json
    rules:
      credentials:
        name: gmp-test-sa
        key: key.json

    Votre ressource Deployment doit ressembler à ceci :

    apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: operator
        ...
        args:
        - ...
        - "--project-id=PROJECT_ID"
        - "--cluster=CLUSTER_NAME"
        - "--location=REGION"

    Cet exemple suppose que vous avez défini la variable REGION sur une valeur telle que us-central1.

    L'exécution de Managed Service pour Prometheus en dehors de Google Cloud entraîne des frais de transfert de données. Le transfert de données vers Google Cloud est payant, et des frais peuvent vous être facturés depuis un autre cloud. Vous pouvez réduire ces coûts en activant la compression gzip sur le réseau via la ressource OperatorConfig. Ajoutez le texte affiché en gras à la ressource :

        apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    collection:
      compression: gzip
      ...

    Documentation complémentaire sur les ressources personnalisées des collections gérées

    Pour obtenir une documentation de référence sur toutes les ressources personnalisées Managed Service pour Prometheus, consultez la documentation prometheus-engine/doc/api reference.

    Étapes suivantes