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.

Sur cette page, vous allez :

• 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 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 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 la CLI gcloud pour faire référence à l'ID de votre projet 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 :

  • Présentation de la CLI gcloud
  • Commandes kubectl

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. Vous devez déployer une ressource PodMonitoring qui extrait un point de terminaison de métriques valide pour afficher toutes les données dans l'interface utilisateur des requêtes. Pour en savoir plus, consultez la section Problèmes côté ingestion.

Activer la collecte gérée : GKE

Si vous exécutez dans un environnement GKE, 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.

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.

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 de votre projet.
• Affichez d'autres informations sur les clusters.

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

1. Dans la console Google Cloud, sélectionnez Monitoring ou utilisez le bouton suivant :

   Accéder à Monitoring

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

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.

Remarque : Ce tableau de bord n'affiche que les clusters GKE du projet en cours, même si le champ d'application de la métrique contient plusieurs projets. Pour en savoir plus, consultez la page Présentation de l'affichage des métriques de plusieurs projets.

UI 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 la console Google Cloud, sélectionnez Kubernetes Engine ou utilisez le bouton suivant :

   Accéder à Kubernetes Engine

2. Sélectionnez Clusters.

3. Cliquez sur le nom du cluster.

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

5. Cliquez sur Enregistrer les modifications.

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

1. Dans la console Google Cloud, sélectionnez Kubernetes Engine ou utilisez le bouton suivant :

   Accéder à Kubernetes Engine

2. Sélectionnez Clusters.

3. Cliquez sur Créer.

4. Cliquez sur Configurer pour l'option Standard.

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

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

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

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 Anthos 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.5.0/manifests/setup.yaml

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

Anthos

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

• Cluster Anthos sur VMware (v1.12 et versions ultérieures)
• Clusters Anthos sur bare metal (v1.12 et versions ultérieures)

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

Déployer l'exemple d'application

Le service géré fournit un fichier manifeste pour un exemple d'application qui émet des métriques Prometheus sur le port metrics. L'application utilise trois instances dupliqué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.5.0/examples/example-app.yaml

Configurer une ressource PodMonitoring

Pour ingérer les données de métriques émises par l'exemple d'application, vous utilisez le scraping de données cibles. 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 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: 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.5.0/examples/pod-monitoring.yaml

Votre collecteur géré scrape désormais les pods correspondants.

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

Remarque : Le champ targetLabels fournit une configuration de libellé simplifiée de type Prometheus. Vous pouvez utiliser le libellé pour ajouter des libellés de pods en tant que libellés sur la série temporelle ingérée. Vous ne pouvez pas écraser les libellés cibles obligatoires. Pour obtenir la liste de ces libellés, consultez la ressource prometheus_target.

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

• Pour interroger les métriques ingérées par l'exemple d'application, consultez la section Interroger les données du service Prometheus.
• Pour en savoir plus sur le filtrage des métriques exportées et l'adaptation de vos ressources prom-operator, consultez la section Autres sujets sur la collecte gérée.

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 Compute Engine par défaut ou de la configuration de Workload Identity.

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
   

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

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

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

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__]

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

Remarque : Vous pouvez convertir une ressource personnalisée PodMonitor prometheus-operator vers la ressource personnalisée PodMonitoring du service géré de la même manière. Les sélecteurs de libellés peuvent toujours être copiés.

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 :

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

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.5.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 du service géré pour Prometheus en dehors de Google Cloud entraîne des frais d'entrée de données et peut entraîner des frais de sortie de données s'il est exécuté sur un autre cloud. Dans les versions 0.5.0 et ultérieures, vous pouvez réduire ces coûts en activant la compression gzip via 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.

Étape suivante

• Interrogez les métriques Prometheus collectées à l'aide du service.
• Configurez l'évaluation des règles gérées.
• Configurez des exportateurs couramment utilisés.