Personnaliser le scraping des métriques Prometheus dans le service managé pour Prometheus d’Azure Monitor

  • Article

Cet article fournit des instructions sur la personnalisation du scraping de métriques pour un cluster Kubernetes avec le module complémentaire de métriques dans Azure Monitor.

ConfigMaps

Quatre ConfigMaps différents peuvent être configurés pour fournir une configuration de scraping et d’autres paramètres pour le module complémentaire de métriques. Tous les mappages de configuration doivent être appliqués à l’espace de noms kube-system pour n’importe quel cluster.

Notes

Aucune des quatre cartes de configuration n’existe par défaut dans le cluster lorsque Managed Prometheus est activé. En fonction de ce qui doit être personnalisé, vous devez déployer l'une ou l'autre de ces quatre cartes de configuration en utilisant le même nom dans kube-systeml'espace de noms. Les modules AMA-Metrics récupèrent ces cartes de configuration après leur déploiement dans l’kube-system espace de noms et redémarrent au bout de 2 à 3 minutes pour appliquer les paramètres de configuration spécifiés dans la ou les cartes de configuration.

  1. ama-metrics-settings-configmap Ce mappage de configuration contient des paramètres simples ci-dessous qui peuvent être configurés. Vous pouvez prendre le ConfigMap à partir du référentiel GitHub ci-dessus, modifier les paramètres requis et appliquer/déployer le ConfigMap dans l’espace de noms kube-system de votre cluster
    • alias de cluster (pour modifier la valeur de l’étiquette cluster dans chaque série chronologique/métrique ingérée à partir d’un cluster)
    • activer/désactiver les cibles de scraping par défaut : ACTIVER/DÉSACTIVER le scraping par défaut en fonction des cibles. La configuration de scraping pour ces cibles par défaut est déjà prédéfinie/intégrée
    • activer le scraping en fonction de l’annotation de pod par espace de noms
    • listes de conservation de métriques : ce paramètre est utilisé pour contrôler des métriques répertoriées pour être autorisées à partir de chaque cible par défaut et pour modifier le comportement par défaut
    • intervalles de scraping pour des cibles prédéfinies/par défaut. 30 secs est la fréquence de scraping par défaut et elle peut être modifiée par cible par défaut à l’aide de ce ConfigMap
    • mode débogage : ACTIVER cette option permet de déboguer des problèmes de métrique/ingestion manquants. En savoir plus sur la résolution des problèmes
  2. ama-metrics-prometheus-configCe mappage de configuration peut être utilisé pour fournir une configuration de scraping Prometheus pour des réplica de module complémentaire. Le module complémentaire exécute une réplica singleton, et tous les services au niveau du cluster peuvent être détectés et extraits en fournissant des travaux de scraping dans ce ConfigMap. Vous pouvez prendre l’exemple de ConfigMap à partir du référentiel GitHub ci-dessus, ajouter des travaux scraping dont vous avez besoin et appliquer/déployer le mappage de configuration à l’espace de noms kube-system de votre cluster. Malgré sa prise en charge, notez que la méthode recommandée de récupération de cibles personnalisées utilise des ressources personnalisées
  3. ama-metrics-prometheus-config-node (Avancé) Ce ConfigMap peut être utilisé pour fournir une configuration de scraping Prometheus au DaemonSet du module complémentaire qui s’exécute sur chaque nœud Linux du cluster, et toutes les cibles de niveau nœud de chaque nœud peuvent être scrapées en fournissant des travaux de scraping dans ce ConfigMap. Lorsque vous utilisez ce ConfigMap, vous pouvez utiliser la variable $NODE_IP dans votre configuration de scraping, qui est remplacée par l’adresse IP du nœud correspondant dans le pod DaemonSet en cours d’exécution sur chaque nœud. De cette façon, vous disposez d’un accès pour scraper tout ce qui s’exécute sur ce nœud à partir du module complémentaire de métriques DaemonSet. Soyez prudent lorsque vous utilisez des découvertes dans la configuration de scraping dans ce mappage de configuration au niveau du nœud, car chaque nœud du cluster va configurer la détection et de la ou des cibles et collecter des métriques redondantes. Vous pouvez prendre l’exemple de ConfigMap à partir du référentiel GitHub ci-dessus, ajouter des travaux scraping dont vous avez besoin et appliquer/déployer le mappage de configuration à l’espace de noms kube-system de votre cluster
  4. ama-metrics-prometheus-config-node-windows (Avancé) Ce ConfigMap peut être utilisé pour fournir une configuration de scraping Prometheus au DaemonSet du module complémentaire qui s’exécute sur chaque nœud Windows du cluster, et les cibles de niveau nœud de chaque nœud peuvent être scrapées en fournissant des travaux de scraping dans ce ConfigMap. Lorsque vous utilisez ce ConfigMap, vous pouvez utiliser la variable $NODE_IP dans votre configuration de scraping, qui est remplacée par l’adresse IP du nœud correspondant dans le pod DaemonSet en cours d’exécution sur chaque nœud. De cette façon, vous disposez d’un accès pour scraper tout ce qui s’exécute sur ce nœud à partir du module complémentaire de métriques DaemonSet. Soyez prudent lorsque vous utilisez des découvertes dans la configuration de scraping dans ce mappage de configuration au niveau du nœud, car chaque nœud du cluster va configurer la détection et de la ou des cibles et collecter des métriques redondantes. Vous pouvez prendre l’exemple de ConfigMap à partir du référentiel GitHub ci-dessus, ajouter des travaux scraping dont vous avez besoin et appliquer/déployer le mappage de configuration à l’espace de noms kube-system de votre cluster

Définitions de ressources personnalisées

Le module complémentaire de métriques Azure Monitor prend en charge la récupération des métriques Prometheus à l’aide de Prometheus : Moniteurs de pods et Moniteurs de services, comme l’opérateur OSS Prometheus. L’activation du module complémentaire déploie les définitions de ressources personnalisées de moniteur de pod et de service pour vous permettre de créer vos propres ressources personnalisées. Suivez les instructions pour créer et appliquer des ressources personnalisées sur votre cluster.

Configmap des paramètres du module complémentaire des métriques

ama-metrics-settings-configmap peut être téléchargé, modifié et appliqué au cluster pour personnaliser les fonctionnalités prêtes à l’emploi du module complémentaire de métriques.

Activer et désactiver les cibles par défaut

Le tableau suivant contient la liste de toutes les cibles par défaut que le module complémentaire de métriques Azure Monitor peut scraper par défaut et s’il est initialement activé ou non. Les cibles par défaut sont scrapées toutes les 30 secondes. Un réplica est déployé pour scraper des cibles à l’échelle du cluster, telles que kube-state-metrics. Un contrôleur DaemonSet est également déployé pour scraper des cibles à l’échelle du nœud, telles que le composant kubelet.

Clé Type activé Pod Description
kubelet bool true DaemonSet Linux Scrapez un kubelet dans chaque nœud du cluster K8s sans aucune configuration de scrape supplémentaire.
cadvisor bool true DaemonSet Linux Scrapez cadvisor dans chaque nœud du cluster K8s sans aucune configuration de scrape supplémentaire.
Linux uniquement.
kubestate bool true Réplica Linux Scrapez kube-state-metrics dans le cluster K8s (installé dans le cadre du module complémentaire) sans aucune configuration de scrape supplémentaire.
nodeexporter bool true DaemonSet Linux Scrapez les métriques de nœud sans configuration de scraping supplémentaire.
Linux uniquement.
CoreDNS bool false Réplica Linux Scrapez le service coredns dans le cluster K8s sans aucune configuration de scrape supplémentaire.
kubeproxy bool false DaemonSet Linux Scrapez kube-proxy dans chaque nœud Linux découvert dans le cluster K8s sans aucune configuration de scrape supplémentaire.
Linux uniquement.
apiserver bool false Réplica Linux Scrapez le serveur d’API Kubernetes dans le cluster K8s sans aucune configuration de scrape supplémentaire.
windowsexporter bool false DaemonSet Windows Scrapez le programme d’exportation de Windows dans chaque nœud du cluster K8s sans aucune configuration de scrape supplémentaire.
Windows uniquement.
windowskubeproxy bool false DaemonSet Windows Scrapez le kubeproxy Windows dans chaque nœud du cluster K8s sans aucune configuration de scrape supplémentaire.
Windows uniquement.
prometheuscollectorhealth bool false Réplica Linux Scrapez des informations sur le conteneur prometheus-collector, telles que la quantité et la taille de séries chronologiques scrapées.

Si vous souhaitez activer le scraping des cibles par défaut qui ne sont pas activées par défaut, modifiez le configmapama-metrics-settings-configmap pour faire passer les cibles répertoriées sous default-scrape-settings-enabled à true. Appliquez le configmap à votre cluster.

Activer le scraping basé sur l’annotation de pod

Pour scraper des pods d’application sans avoir à créer une configuration Prometheus personnalisée, il est possible d’y ajouter des annotations. L’annotation prometheus.io/scrape: "true" est requise pour que le pod soit scrapé. Les annotations prometheus.io/path et prometheus.io/port indiquent le chemin d’accès et le port hébergés par les métriques sur le pod. Les annotations d’un pod qui héberge des métriques au niveau de <pod IP>:8080/metrics sont les suivantes :

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

Le scraping de ces pods avec des annotations spécifiques est désactivé par défaut. Pour l’activer, dans ama-metrics-settings-configmap, ajoutez l’expression régulière pour le ou les espaces de noms des pods avec des annotations que vous souhaitez scraper comme valeur du champ podannotationnamespaceregex.

Par exemple, le paramètre suivant scrape les pods avec des annotations uniquement dans les espaces de noms kube-system et my-namespace :

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

Pour activer le scraping pour les pods avec des annotations dans tous les espaces de noms, utilisez :

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

Avertissement

Le scraping des annotations de pod dans de nombreux espaces de noms peut générer un très grand volume de métriques en fonction du nombre de pods qui ont des annotations.

Personnalisation des métriques collectées par les cibles par défaut

Par défaut, pour toutes les cibles par défaut, seules les métriques minimales utilisées dans les règles d’enregistrement par défaut, les alertes et les tableaux de bord Grafana sont ingérées comme décrit dans minimal-ingestion-profile. Pour collecter toutes les métriques à partir des cibles par défaut, mettez à jour les keep-lists dans le ConfigMap des paramètres sous default-targets-metrics-keep-list, puis définissez minimalingestionprofile sur false.

Pour établir une liste d’autorisation d’autres métriques en plus des métriques par défaut répertoriées pour être autorisées, pour toutes les cibles par défaut, modifiez les paramètres sous default-targets-metrics-keep-list pour le travail correspondant que vous souhaitez modifier.

Par exemple, kubelet est le paramètre de filtrage des métriques pour le kubelet cible par défaut. Utilisez le script suivant pour filtrer les métriques collectées pour les cibles par défaut à l'aide d'un filtrage basé sur des expressions rationnelles.

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

Notes

Si vous utilisez des guillemets ou des barres obliques inverses dans le regex, vous devez les placer dans un échappement à l’aide d’une barre oblique inverse comme les exemples "test\'smetric\"s\"" et testbackslash\\*.

Pour personnaliser davantage les travaux par défaut afin de modifier les propriétés telles que la fréquence de collecte ou les étiquettes, désactivez la cible par défaut correspondante en définissant la valeur de configmap pour la cible sur false. Ensuite, appliquez le travail à l’aide d’un configmap personnalisé. Pour plus d’informations sur la configuration personnalisée, consultez Personnaliser le scraping des métriques Prometheus dans Azure Monitor.

Alias de cluster

L’étiquette de cluster ajoutée à chaque série chronologique scrapée utilise la dernière partie de l’ID de ressource Azure Resource Manager du cluster AKS complet. Par exemple, si l’ID de ressource est /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername, l’étiquette du cluster est myclustername.

Pour remplacer l’étiquette du cluster dans la série chronologique scrapée, mettez à jour le paramètre cluster_alias sur n’importe quelle chaîne sous prometheus-collector-settings dans le configmapama-metrics-settings-configmap. Si ce configmap n’existe pas dans le cluster, vous pouvez le créer ou, s’il existe déjà dans votre cluster, vous pouvez le modifier.

La nouvelle étiquette s’affiche également dans la liste déroulante des paramètres de cluster dans les tableaux de bord Grafana au lieu de celle par défaut.

Notes

Seuls les caractères alphanumériques sont autorisés. Tous les autres caractères sont remplacés par _. Cette modification vise à garantir que les différents composants qui utilisent cette étiquette respectent la convention alphanumérique de base.

Mode débogage

Avertissement

Ce mode peut affecter les performances et ne doit être activé que pendant une courte période à des fins de débogage.

Pour afficher chaque métrique scrapée aux fins de débogage, l’agent du module complémentaire de métriques peut être configuré pour s’exécuter en mode débogage en mettant à jour le paramètre enabled sur true sous le paramètres debug-mode dans le configmapama-metrics-settings-configmap. Vous pouvez créer ce configmap ou en modifier un existant. Pour plus d’informations, consultez la section Mode débogage dans la collection Dépannage des métriques Prometheus.

Paramètres d’intervalle de récupération

Pour mettre à jour les paramètres d’intervalle de récupération pour n’importe quelle cible, vous pouvez mettre à jour la durée dans le paramètre default-targets-scrape-interval-settings pour cette cible dans le configmapama-metrics-settings-configmap. Vous devez définir les intervalles de récupération dans le format correct spécifié dans ce site web. Sinon, la valeur par défaut de 30 secondes est appliquée aux cibles correspondantes. Par exemple : si vous souhaitez mettre à jour l’intervalle de scraping pour le travail kubelet sur 60s, vous pouvez mettre à jour la section suivante dans YAML :

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

et appliquez YAML en utilisant la commande suivante : kubectl apply -f .\ama-metrics-settings-configmap.yaml

Configurer des travaux de scraping Prometheus personnalisées

Vous pouvez extraire des métriques Prometheus à l’aide de Prometheus : Moniteurs de pods et Moniteurs de services (Recommandé), de la même manière qu’avec l’opérateur OSS Prometheus. Suivez les instructions pour créer et appliquer des ressources personnalisées sur votre cluster.

De plus, vous pouvez suivre les instructions pour créer, valider et appliquer le ConfigMap pour votre cluster. Le format de configuration est similaire au fichier de configuration Prometheus.

Conseils et exemples de configuration Prometheus

Découvrez quelques conseils à partir d’exemples dans cette section.

Utilisez les modèles de moniteur de pod et de service et suivez la spécification de l’API pour créer vos ressources personnalisées (Moniteur de pod et Moniteur de service). Notez que la seule modification requise pour les ressources personnalisées OSS existantes pour qu’elles soient récupérées par le Prometheus géré est le groupe d’API azmonitoring.coreos.com/v1. Pour en savoir plus, consultez cet article

Notes

Lorsque la configuration de scraping personnalisée échoue à s’appliquer en raison d’erreurs de validation, la configuration de scraping par défaut continue d’être utilisée.

Si vous souhaitez que des paramètres globaux s’appliquent à tous les travaux d’extraction, et si vous n’avez que des ressources personnalisées, vous devrez toujours créer un ConfigMap avec uniquement les paramètres globaux (les paramètres de chacun de ces travaux dans les ressources personnalisées remplaceront ceux de la section globale)

Scraper des configurations

Pour le moment, les méthodes de découverte cible prises en charge pour les ressources personnalisées sont les moniteurs de pods et de services

Moniteurs de pods et de services

Les cibles découvertes à l’aide de pods et de moniteurs de service ont des étiquettes __meta_* différentes en fonction de l’utilisation du moniteur. Les étiquettes peuvent être utilisées dans la section relabelings pour filtrer des cibles ou remplacer des étiquettes pour les cibles.

Consultez les exemples Moniteur de pod et Moniteur de service de moniteurs de pod et de service.

Étiquetages

La section relabelings est appliquée au moment de la détection de la cible et s’applique à chaque cible pour le travail. Les exemples suivants montrent comment utiliser relabelings.

Ajouter une étiquette

Ajoutez une nouvelle étiquette appelée example_label avec la valeur example_value à chaque métrique du travail. Utilisez __address__ comme étiquette source uniquement, car cette étiquette existe toujours et ajoute l’étiquette pour chaque cible du travail.

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

Utiliser des étiquettes de moniteur de pod ou de service

Les cibles découvertes à l’aide de pods et de moniteurs de service ont des étiquettes __meta_* différentes en fonction de l’utilisation du moniteur. Les étiquettes __* sont supprimées après la détection des cibles. Pour les filtrer au niveau des métriques, conservez-les d’abord en utilisant relabelings en affectant un nom d’étiquette. Ensuite, utilisez metricRelabelings pour filtrer.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metricRelabelings:
- sourceLabels: [kubernetes_namespace]
  action: keep
  regex: 'default'

Réétiquetage des travaux et des instances

Les valeurs d’étiquette job et instance peuvent être modifiées en fonction de l’étiquette source, comme n’importe quelle autre étiquette.

# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: job

# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

Ré-étiquetage des métriques

Les ré-étiquetages des métriques sont appliqués après l’extraction et avant l’ingestion. Utilisez la section metricRelabelings pour filtrer les métriques après le scraping. Les exemples suivants illustrent son fonctionnement.

Annuler les métriques par nom

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

Conserver uniquement certaines métriques par nom

# Keep only the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: '(example_.*)'

Renommer des métriques

Le renommage des métriques n’est pas pris en charge.

Filtrer les métriques par étiquettes

# Keep metrics only where example_label = 'example'
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metricRelabelings:
- sourceLabels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metricRelabelings:
- sourceLabels: [example_label_1]
  action: keep
  regex: '.+'

Scraping basé sur TLS

Si vous avez une instance Prometheus servie avec TLS et que vous souhaitez en extraire des métriques, vous devez définir le schéma sur https et définir les paramètres TLS dans votre ConfigMap ou CRD respectif. Vous pouvez utiliser la propriété de configuration tls_config à l’intérieur d’une tâche de scraping personnalisée pour configurer les paramètres TLS à l’aide d’un CRD ou d’un ConfigMap. Vous devez fournir un certificat d’autorité de certification avec lequel valider le certificat du serveur d’API. Le certificat d’autorité de certification est utilisé pour vérifier l’authenticité du certificat du serveur lorsque Prometheus se connecte à la cible via TLS. Il permet de s’assurer que le certificat du serveur est signé par une autorité approuvée.

Le secret doit être créé dans l’espace de noms kube-system, puis le ConfigMap/CRD doit être créé dans l’espace de noms kube-system. L’ordre de création des secrets a une importance. S’il n’y a pas de secret mais qu’il y a un CRD/ConfigMap valide, vous trouverez des erreurs dans le journal du collecteur, >no file found for cert....

Vous trouverez ci-dessous les détails sur la façon de fournir les paramètres de configuration TLS via un ConfigMap ou CRD.

  • Pour fournir le paramètre de configuration TLS dans un ConfigMap, créez le certificat auto-signé et la clé à l’intérieur du répertoire /etc/prometheus/certs au sein de votre application mtls. Voici à quoi doit ressembler un exemple de tlsConfig à l’intérieur du ConfigMap :
tls_config:
    ca_file: /etc/prometheus/certs/client-cert.pem
    cert_file: /etc/prometheus/certs/client-cert.pem
    key_file: /etc/prometheus/certs/client-key.pem
    insecure_skip_verify: false
  • Pour fournir le paramètre de configuration TLS dans un CRD, créez le certificat auto-signé et la clé à l’intérieur du répertoire /etc/prometheus/certs au sein de votre application mtls. Voici à quoi doit ressembler un exemple de tlsConfig à l’intérieur d’un Podmonitor :
tlsConfig:
    ca:
        secret:
        key: "client-cert.pem" # since it is self-signed
        name: "ama-metrics-mtls-secret"
    cert:
        secret:
        key: "client-cert.pem"
        name: "ama-metrics-mtls-secret"
    keySecret:
        key: "client-key.pem"
        name: "ama-metrics-mtls-secret"
    insecureSkipVerify: false

Remarque

Vérifiez que le nom du fichier de certificat et le nom de la clé à l’intérieur de l’application mtls sont au format suivant en cas de scraping basé sur CRD. Par exemple : secret_kube-system_ama-metrics-mtls-secret_cert-name.pem et secret_kube-system_ama-metrics-mtls-secret_key-name.pem. Le CRD doit être créé dans l’espace de noms kube-system. Le nom du secret doit être exactement ama-metrics-mtls-secret dans l’espace de noms kube-system. Voici un exemple de commande pour créer un secret : kubectl create secret generic ama-metrics-mtls-secret --from-file=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem --from-file=secret_kube-system_ama-metrics-mtls-secret_client-key.pem=secret_kube-system_ama-metrics-mtls-secret_client-key.pem -n kube-system

Pour en savoir plus sur l’authentification TLS, les documents suivants peuvent être utiles.

Authentification de base

Si vous utilisez le paramètre basic_auth dans votre configuration Prometheus, veuillez suivre les étapes -

  1. Créez un secret dans l'espace de noms du système Kube nommé ama-metrics-mtls-secret

La valeur de password1 est base64encoded. La clé password1 peut être n'importe quoi, mais doit simplement correspondre à votre chemin de fichier scrapeconfig password_file.

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>
  1. Dans la carte de configuration pour la configuration de scrape personnalisée, utilisez le paramètre suivant :
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

Remarque

Assurez-vous que le nom est ama-metrics-mtls-secret et qu'il se trouve dans l'espace de noms kube-system.

Le chemin /etc/prometheus/certs/ est obligatoire, mais password1 peut être n'importe quelle chaîne et doit correspondre à la clé des données dans le secret créé ci-dessus. En effet, le secret ama-metrics-mtls-secret est monté dans le chemin /etc/prometheus/certs/ au sein du conteneur.

La valeur codée en base64 est automatiquement décodée par les pods d'agent lorsque le secret est monté en tant que fichier.

Tout autre paramètre de configuration pour l'autorisation qui est considéré comme un secret dans la configuration de prometheus doit plutôt utiliser l'alternative de paramètre de fichier, comme décrit ci-dessus.

Étapes suivantes

Configurer des alertes sur les métriques Prometheus
Interroger des métriques Prometheus
En savoir plus sur la collecte de métriques Prometheus