Premiers pas avec la collecte auto-déployée

Ce document explique comment configurer Google Cloud Managed Service pour Prometheus avec la collecte auto-déployée. Un exemple d'application est déployé sur un cluster Kubernetes et surveillé par un serveur Prometheus qui stocke les métriques collectées dans Monarch.

Sur cette page, vous allez :

  • Configurer votre environnement et vos outils de ligne de commande
  • Configurer un compte de service pour les clusters compatibles avec Workload Identity
  • Exécuter le binaire Prometheus prêt à l'emploi sur Kubernetes
  • Contrôler les métriques qui sont ingérées dans Managed Service pour Prometheus
  • Intégrer Managed Service pour Prometheus dans les configurations de prometheus-operator
  • Compiler et exécuter manuellement le binaire Prometheus

La collecte de données autodéployée vous permet de gérer votre installation Prometheus comme vous l'avez toujours fait. La seule différence est que vous exécutez le binaire de remplacement de Managed Service pour Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.43.1-gmp.0-gke.0, au lieu du binaire Prometheus en amont.

Le binaire à insérer offre des options de configuration supplémentaires avec les options --export.*. Pour en savoir plus, consultez la sortie de l'option --help. Ce document souligne les options les plus importantes.

Managed Service pour Prometheus ne prend pas en charge l'exportation de métriques à partir d'un serveur de fédération ou d'un serveur utilisé comme récepteur d'écritures distantes. Vous pouvez répliquer toutes les fonctionnalités du serveur de fédération, y compris la réduction du volume d'ingestion par agrégation des données avant leur envoi à Monarch, à l'aide de filtres et d'agrégations locales.

La diffusion de données vers Managed Service pour Prometheus consomme des ressources supplémentaires. Si vous déployez vous-même les collecteurs, nous vous recommandons d'augmenter les limites de processeur et de mémoire d'un facteur cinq et de les ajuster en fonction de l'utilisation réelle.

Pour en savoir plus sur la collecte des données gérée et auto-déployée, consultez la page Collecte des données avec Managed Service pour Prometheus.

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 la CLI gcloud 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

Vérifier les identifiants du compte de service

Vous pouvez ignorer cette section si Workload Identity est activé pour votre cluster Kubernetes.

Lors de l'exécution sur GKE, Managed Service pour Prometheus récupère automatiquement les identifiants de l'environnement en fonction du compte de service Compute Engine par défaut. Le compte de service par défaut dispose des autorisations nécessaires, monitoring.metricWriter et monitoring.viewer, par défaut. Si vous n'utilisez pas Workload Identity et que vous avez précédemment supprimé l'un de ces rôles du compte de service de nœud par défaut, vous devrez rajouter ces autorisations manquantes avant de continuer.

Si vous n'exécutez pas sur GKE, consultez la section Fournir les identifiants explicitement.

Configurer un compte de service pour Workload Identity

Vous pouvez ignorer cette section si Workload Identity n'est pas activé pour votre cluster Kubernetes.

Managed Service pour Prometheus capture les données de métriques à l'aide de l'API Cloud Monitoring. Si votre cluster utilise Workload Identity, vous devez autoriser votre compte de service Kubernetes à accéder à l'API Monitoring. Cette section décrit les opérations suivantes :

Créer et associer le compte de service

Cette étape apparaît à plusieurs endroits de la documentation de Managed Service pour Prometheus. Si vous avez déjà effectué cette étape dans le cadre d'une tâche précédente, vous n'avez pas besoin de la répéter. Passez directement à la section Autoriser le compte de service.

La séquence de commandes suivante crée le compte de service gmp-test-sa et l'associe au compte de service Kubernetes par défaut dans l'espace de noms NAMESPACE_NAME :

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Si vous utilisez un autre espace de noms ou compte de service GKE, ajustez les commandes en conséquence.

Autoriser le compte de service

Les groupes d'autorisations associées sont collectés dans des rôles que vous attribuez à un compte principal, dans cet exemple, le compte de service Google Cloud. Pour en savoir plus sur ces rôles, consultez la page Contrôle des accès.

La commande suivante accorde au compte de service Google Cloud gmp-test-sa les rôles de l'API Monitoring dont il a besoin pour écrire les données de métriques.

Si vous avez déjà attribué un rôle spécifique au compte de service Google Cloud dans le cadre de la tâche précédente, vous n'avez pas besoin de le faire à nouveau.

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

Déboguer votre configuration Workload Identity

Si vous rencontrez des difficultés pour utiliser Workload Identity, consultez la documentation sur la vérification de la configuration de Workload Identity et le guide de dépannage de Workload Identity.

Les fautes de frappe et les copier-coller partiels sont les sources d'erreurs les plus courantes lors de la configuration de Workload Identity. Nous vous recommandons vivement d'utiliser les variables modifiables et les icônes de copier-coller cliquables intégrées dans les exemples de code figurant dans ces instructions.

Workload Identity dans les environnements de production

L'exemple décrit dans ce document associe le compte de service Google Cloud au compte de service Kubernetes par défaut et accorde au compte de service Google Cloud toutes les autorisations nécessaires pour utiliser l'API Monitoring.

Dans un environnement de production, vous pouvez utiliser une approche plus précise, avec un compte de service pour chaque composant, chacun disposant d'autorisations minimales. Pour en savoir plus sur la configuration des comptes de service pour la gestion des identités de charge de travail, consultez la page Utiliser Workload Identity.

Configurer une collecte auto-déployée

Cette section explique comment configurer et exécuter un exemple d'application qui utilise une collecte auto-déployée.

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.10.0/examples/example-app.yaml

Exécuter le binaire Prometheus de remplacement

Pour ingérer les données de métrique émises par l'exemple d'application, vous devez déployer la version dupliquée du serveur Prometheus, qui est configuré pour scraper les métriques de la charge de travail ainsi que son propre point de terminaison de métriques.

  1. Pour déployer le serveur dupliqué, exécutez la commande suivante :

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

    Le serveur Prometheus déployé est une copie légère du binaire Prometheus en amont. Il se comporte comme un serveur Prometheus standard, mais il ingère également les données dans Managed Service pour Prometheus.

    Le fichier manifeste ci-dessus fournit un exemple fonctionnel de base qui envoie des données au data store global, Monarch. Il ne stocke pas de copie locale des données de manière permanente. Pour en savoir plus sur le fonctionnement de cette configuration prédéfinie et sur son extension, consultez la documentation de configuration Prometheus Open Source.

    L'image prédéfinie ne fonctionne que sur les nœuds Linux. Pour scraper des cibles exécutées sur des nœuds Windows, déployez le serveur sur un nœud Linux et configurez-le pour scraper des points de terminaison sur les nœuds Windows ou créez le binaire pour Windows vous-même.

  2. Vérifiez que les pods du serveur Prometheus et de l'exemple d'application ont bien été déployés :

    kubectl -n NAMESPACE_NAME get pod

    Si le déploiement aboutit, un résultat semblable au suivant s'affiche :

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

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 ou de la configuration de Workload Identity. Dans les clusters Kubernetes non GKE, les identifiants doivent être explicitement fournis au serveur Prometheus de collecte à l'aide d'options ou de la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS.

  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

    Cette étape crée le compte de service que vous avez peut-être déjà créé dans les instructions de Workload Identity.

  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 NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Ouvrez la ressource StatefulSet de Prometheus pour la modifier :

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

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

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

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

    Plutôt que d'utiliser les options définies dans cet exemple, vous pouvez définir le chemin d'accès du fichier de clé à l'aide de la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS.

    Autres sujets sur la collecte auto-déployée

    Cette page explique comment effectuer les opérations suivantes :

    • Filtrez les données que vous exportez vers le service géré.
    • Convertissez vos configurations de déploiement existantes.
    • Exécutez le binaire Prometheus en mode haute disponibilité.
    • Créez et exécutez le binaire Prometheus de remplacement.
    • Exécutez le service géré pour Prometheus en dehors de 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 à Managed Service pour Prometheus afin de limiter les coûts.

    Vous pouvez utiliser des configurations de libellés de métriques standards dans votre configuration de scraping Prometheus. Avec les configurations de libellés, vous pouvez supprimer des métriques basées sur les correspondances de libellés au moment de l'ingestion.

    Il se peut que vous souhaitiez ingérer des données en local, mais ne pas les exporter vers Managed Service pour Prometheus. Pour filtrer les métriques exportées, vous pouvez utiliser l'option --export.match.

    L'option spécifie un ou plusieurs sélecteurs de séries PromQL, et elle peut être utilisée plusieurs fois. Une série temporelle est exportée vers le service géré pour Prometheus si elle satisfait tous les sélecteurs d'au moins une option. En d'autres termes, lors de la détermination de l'éligibilité, les conditions d'une même option sont combinées à l'opérateur AND, tandis que les conditions d'options distinctes sont combinées à l'opérateur OR. L'exemple suivant utilise deux instances de l'option :

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    Cette modification entraîne uniquement l'exportation des métriques de la tâche "prometheus", ainsi que les métriques générées par les règles d'enregistrement agrégées au niveau de la tâche à exporter (en suivant les bonnes pratiques de dénomination). Les échantillons de toutes les autres séries sont filtrés. Par défaut, aucun sélecteur n'est spécifié et toutes les séries temporelles sont exportées.

    L'option --export.match possède la même sémantique que le paramètre match[] pour la fédération Prometheus. Vous pouvez donc migrer les configurations de fédération vers Managed Service pour Prometheus en utilisant les sélecteurs de votre serveur de fédération directement, sous forme d'options sur les serveurs Prometheus scrapés par votre serveur Prometheus de fédération. Il n'est pas possible d'exporter des métriques d'un serveur de fédération vers le service géré.

    Pour inclure des métriques de type histogramme (histogram) dans un filtre, vous devez spécifier les métriques _count, _sum et _bucket. Vous pouvez également utiliser un outil de mise en correspondance de caractères génériques, par exemple le sélecteur {__name__=~"histogram_metric_.+"}.

    Si vous utilisez la bibliothèque prometheus-operator, définissez les options --export.match à l'aide de la variable d'environnement EXTRA_ARGS du conteneur. Pour en savoir plus, consultez la section Utilisation avec prometheus-operator.

    Vous pouvez combiner des options de filtre avec des règles d'enregistrement exécutées localement pour effectuer un "déploiement" des données avant de les envoyer à Monarch, ce qui permet de réduire votre cardinalité et les coûts. Pour en savoir plus, consultez la page Contrôle et attribution des coûts.

    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
    • 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
    Pour en savoir plus sur la page Gestion des métriques, consultez la section Afficher et gérer l'utilisation des métriques.

    Utilisation avec prometheus-operator

    Le binaire Managed Service pour Prometheus peut également être utilisé avec un déploiement GKE Prometheus existant géré par prometheus-operator.

    Pour utiliser le binaire du service géré, remplacez la spécification d'image dans la ressource Prometheus :

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.43.1-gmp.0-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Si vous êtes dans un cluster Workload Identity et que l'espace de noms ou le compte de service de votre ressource diffère, répétez les instructions de Workload Identity pour la paire d'espaces de noms et de comptes Kubernetes supplémentaire.

    Lorsque vous utilisez un cluster Kubernetes non GKE, vous devez fournir les identifiants manuellement. Pour fournir les identifiants, procédez comme suit :

    1. Ajoutez un fichier de clé de compte de service approprié en tant que secret, comme décrit dans la section Fournir des identifiants de manière explicite.

    2. Modifiez la ressource Prometheus pour ajouter le texte en gras :

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: gmp-test
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    Vous pouvez définir la variable d'environnement EXTRA_ARGS du conteneur pour ajouter des options supplémentaires, telles que les options de filtrage de métriques. Cela s'effectue via une variable d'environnement, car la section args de la spécification de conteneur est gérée par l'opérateur Prometheus.

    Utilisation avec kube-prometheus

    Vous pouvez configurer des déploiements créés à l'aide de la bibliothèque populaire kube-prometheus afin d'utiliser Managed Service pour Prometheus.

    Kube-prometheus a des dépendances internes strictes dans ses espaces de noms et comptes de service par défaut. Nous vous recommandons donc de ne modifier que le nombre minimal de champs nécessaires pour envoyer des données à Managed Service pour Prometheus.

    Dans manifests/prometheus-prometheus.yaml, remplacez la spécification d'image et désactivez la collecte haute disponibilité en réduisant replicas à 1 :

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.43.1-gmp.0-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...

    Si vous procédez à l'exécution sur GKE et que vous n'avez pas modifié le compte de service par défaut sur le nœud, l'application des fichiers manifestes modifiés doit immédiatement lancer l'envoi des données à Managed Service pour Prometheus. Sinon, vous devrez peut-être configurer et appliquer un compte de service. Si vous procédez à l'exécution sur GKE et que vous utilisez Workload Identity, vous devrez peut-être créer et autoriser le compte de service prometheus-k8s dans l'espace de noms monitoring. Lorsque vous utilisez un cluster Kubernetes non GKE, suivez les instructions de la section Utilisation avec prometheus-operator.

    Notez que kube-prometheus collecte par défaut de nombreuses métriques, qui, pour la plupart, sont rarement nécessaires dans un environnement Kubernetes géré comme GKE. Pour réduire les coûts d'ingestion, vous pouvez personnaliser kube-prometheus afin qu'il n'extrait que les métriques qui vous intéressent et filtrer les métriques exportées de manière agressive.

    Pour obtenir plus de suggestions, consultez la page Contrôle et attribution des coûts.

    Déploiement haute disponibilité

    Le binaire Prometheus de remplacement est compatible avec la collecte à haute disponibilité lorsque l'élection du responsable est utilisée. Les serveurs Prometheus répliqués en mode haute disponibilité collectent les métriques et évaluent les règles comme d'habitude, mais un seul d'entre eux envoie des données au service géré Google Cloud pour Prometheus.

    Les instances dupliquées du même serveur Prometheus doivent toujours avoir des configurations identiques, y compris les mêmes external_labels. Cette exigence diffère des autres systèmes qui reposent sur un libellé externe spécial (__replica__, par exemple) pour rendre les instances dupliquées explicitement différentes.

    Le serveur d'API Kubernetes est un backend d'élection du responsable compatible et peut être activé en définissant les options suivantes :

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    Les valeurs LEASE_NAMESPACE et LEASE_NAME identifient la ressource de bail utilisée pour mettre en œuvre l'élection du responsable. Tous les serveurs Prometheus pointant vers la même ressource appartiennent au même ensemble d'instances dupliquées. Le compte de service Kubernetes du déploiement Prometheus doit être autorisé à lire et à écrire la ressource de bail correspondante. Lorsque vous exécutez le serveur Prometheus en dehors d'un cluster Kubernetes, vous pouvez fournir une configuration explicite en utilisant l'option --export.ha.kube.config.

    Une fois cette opération effectuée, vous pouvez augmenter la valeur replicas à 2 ou plus.

    Libellés réservés

    Managed Service pour Prometheus utilise six libellés réservés pour identifier de manière unique une ressource dans Monarch :

    • project_id : identifiant du projet Google Cloud associé à votre métrique. Obligatoire.
    • 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. Obligatoire.
    • cluster : nom du cluster Kubernetes associé à la métrique. Si l'application n'est pas exécutée sur Kubernetes, elle peut être utilisée comme niveau de hiérarchie arbitraire, tel qu'un groupe d'instances. Facultatif, mais vivement recommandé.
    • namespace : nom de l'espace de noms Kubernetes associé à la métrique. S'il n'est pas exécuté sur Kubernetes, cela peut être utilisé comme niveau de hiérarchie arbitraire, par exemple un sous-groupe d'instances. Facultatif, mais fortement recommandé.
    • 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. Obligatoire et généralement ajouté automatiquement par Prometheus.
    • 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. Obligatoire et généralement ajouté automatiquement par Prometheus. Si vous définissez ou modifiez manuellement le libellé, n'utilisez pas de valeurs codées en dur telles que localhost, car cela entraîne des collisions de séries temporelles.

    Lorsqu'ils sont exécutés sur Google Cloud, les libellés project_id, location et cluster sont automatiquement ajoutés à chaque métrique.

    Bien que cela ne soit pas recommandé lorsque vous exécutez Prometheus sur Google Cloud, vous pouvez ignorer les libellés project_id, location, cluster et namespace à l'aide de la section global.external_labels de votre configuration Prometheus. Pour en savoir plus, consultez la section Exécuter une collection autodéployée en dehors de Google Cloud.

    Si vous utilisez des libellés réservés en tant que libellés de métriques, la collecte autodéployée utilise le libellé de métrique comme valeur pour le libellé réservé. Cela peut offrir une certaine flexibilité, mais peut également entraîner des erreurs si, par exemple, vous utilisez le libellé location pour faire référence à autre chose qu'une région Google Cloud.

    Déploiements binaires

    Si vous souhaitez procéder à l'exécution dans un environnement non conteneurisé, vous pouvez compiler directement le binaire Prometheus de remplacement.

    Créer la source

    Si vous disposez d'un processus existant pour compiler Prometheus vous-même, vous pouvez remplacer de manière transparente notre dépôt GitHub dans votre processus. Managed Service pour Prometheus possède sa propre extension de tag de version afin de distinguer ses versions des versions en amont.

    Pour créer le binaire brut, la chaîne d'outils Go et les versions récentes de NPM/Yarn doivent être installées sur la machine. Pour en savoir plus, consultez les instructions de création en amont.

    1. Clonez le dépôt :

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. Vérifiez le tag de version souhaité :

      git checkout v2.43.1-gmp.0

    3. Pour créer un tarball pour Managed Service pour Prometheus, exécutez les commandes suivantes :

      make build && make tarball

    Le package tarball et les binaires obtenus sont entièrement compatibles avec leurs variantes en amont en termes de structure de répertoire et de fonctionnalités.

    Limites relatives à la création et à la mise à jour des métriques et des étiquettes

    Managed Service pour Prometheus applique une limite de débit par minute pour la création de métriques et l'ajout de nouveaux libellés aux métriques existantes. Cette limite de débit n'est généralement atteinte que lors de la première intégration à Managed Service pour Prometheus, par exemple lorsque vous migrez un déploiement Prometheus existant qui a fait ses preuves pour utiliser une collection auto-déployée. Il ne s'agit pas d'une limite de débit pour l'ingestion de points de données. Cette limite de débit s'applique uniquement à la création de métriques qui n'existaient pas auparavant ou à l'ajout de nouveaux libellés aux métriques existantes.

    Ce quota est fixe, mais les problèmes éventuels doivent être automatiquement résolus à mesure que de nouvelles métriques et de nouveaux libellés de métriques sont créés dans la limite définie par minute.

    Pour en savoir plus, consultez la section Dépannage.

    Exécuter une collection autodéployée en dehors de Google Cloud

    Dans les environnements Compute Engine, GKE ou sur une machine sur laquelle vous avez exécuté gcloud login avec un compte disposant d'autorisations suffisantes, vous pouvez exécuter une collecte autodéployée sans configuration supplémentaire. En dehors de Google Cloud, vous devez fournir explicitement des identifiants, un project_id pour contenir vos métriques et une location (région Google Cloud) dans laquelle stocker vos métriques. Vous devez également définir les étiquettes cluster et namespace, même si vous utilisez un environnement autre que Kubernetes.

    Vous pouvez fournir une clé de compte de service à l'aide de l'option --export.credentials-file ou de la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS, comme décrit dans la section Fournir des identifiants de manière explicite.

    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.

    Si vous utilisez un environnement Kubernetes, définissez les valeurs cluster et namespace sur le cluster et l'espace de noms locaux. En cas d'exécution en dehors de Kubernetes, définissez-les sur des valeurs hiérarchiques. Par exemple, dans un environnement basé sur des VM s'exécutant sur AWS, définissez la valeur cluster sur __aws__ et la valeur namespace sur l'ID d'instance. Vous pouvez renseigner l'ID d'instance de manière dynamique à l'aide d'une règle de réécriture d'étiquettes qui appelle le serveur de métadonnées local.

    À titre d'exemple fonctionnel minimal, vous pouvez exécuter un binaire Prometheus local à autosurveillance à l'aide de la commande suivante :

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

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

    Toutefois, nous vous recommandons de définir les libellés cibles export pour le service géré dans la section global.external_labels de votre configuration Prometheus. Par exemple, dans les environnements Kubernetes, vous pouvez utiliser la configuration suivante :

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    L'exécution du service géré 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 ce coût en activant la compression avec l'option --export.compression=gzip.

    Étapes suivantes