Partager via

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 configmap ama-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"

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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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 configmap ama-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. Si vous activez les règles d’enregistrement et d’alerte, veillez à utiliser le nom d’alias de cluster dans le paramètre du nom du cluster du modèle d’intégration de règle pour que les règles fonctionnent.

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 configmap ama-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 configmap ama-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

Remarque

Si vous avez des configurations de ré-étiquetage, assurez-vous que l’étiquetage ne filtre pas les cibles et que les étiquettes configurées correspondent bien aux cibles.

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: '.+'

Jetons d’authentification de base et de porteur

Pour utiliser les paramètres basic_auth ou bearer_token dans votre configuration Prometheus, procédez de la manière suivante :

  1. Créez un secret dans l’espace de noms kube-system nommé ama-metrics-mtls-secret.

    Le nom de la clé password1 peut être n’importe quoi tant qu’il correspond au nom de fichier dans le chemin d’accès au fichier password_file dans la configuration d’extraction Prometheus à l’étape suivante. La valeur de la clé doit être encodée en base64.

    apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>

    Le secret ama-metrics-mtls-secret est monté sur les pods ama-metrics du chemin d’accès /etc/prometheus/certs/ et est mis à la disposition de l’extracteur Prometheus. La clé (password1 dans l’exemple ci-dessus) est le nom du fichier. La valeur est décodée en base64 et ajoutée en tant que contenu du fichier dans le conteneur.

  2. Ensuite, dans la configuration d’extraction personnalisée dans le configmap, fournissez le chemin d’accès au fichier :

    Authentification de base

    Le champ username doit contenir la chaîne de nom d’utilisateur réelle. Le champ password_file doit contenir le chemin d’accès au fichier qui contient le mot de passe.

    # Sets the `Authorization` header on every scrape request with the
# configured username and password.
basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

    Jeton du porteur

    Le champ bearer_token_file doit contenir le chemin d’accès au fichier qui contient le jeton.

    # Sets the `Authorization` header on every scrape request with the bearer token
# read from the configured file. It is mutually exclusive with `bearer_token`.
bearer_token_file: /etc/prometheus/certs/password1

Vous trouverez plus d’informations sur ces paramètres dans la documentation Prometheus scrape_config.

Si vous utilisez l’authentification de base et l’authentification TLS, reportez-vous à la section ci-dessous. Pour plus d’informations, reportez-vous à la section note ci-dessous.

Scraping basé sur TLS

Si vous souhaitez extraire des métriques Prometheus à partir d’un point de terminaison https, la configuration Prometheus, PodMonitor ou ServiceMonitor doit disposer de scheme défini sur https et de paramètres TLS supplémentaires.

  1. Créez un secret dans l’espace de noms kube-system nommé ama-metrics-mtls-secret. Chaque paire clé-valeur spécifiée dans la section de données de l’objet secret est montée en tant que fichier distinct dans cet emplacement /etc/prometheus/certs avec des noms de fichiers identiques aux clés spécifiées dans la section des données. Les valeurs secrètes doivent être encodées en base64.

    Voici l’exemple YAML d’un secret :

    apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  <certfile>: base64_cert_content    
  <keyfile>: base64_key_content

    Le secret ama-metrics-mtls-secret est monté sur les pods ama-metrics du chemin d’accès /etc/prometheus/certs/ et est mis à la disposition de l’extracteur Prometheus. La clé (password1 dans l’exemple ci-dessus) est le nom du fichier. La valeur est décodée en base64 et ajoutée en tant que contenu du fichier dans le conteneur.

  2. Ensuite, dans la configuration Prometheus, PodMonitor ou ServiceMonitor, fournissez le chemin d’accès au fichier :

  • Pour fournir le paramètre de configuration TLS dans un configmap, suivez l’exemple ci-dessous :
tls_config:
   # CA certificate to validate API server certificate with.
   ca_file: /etc/prometheus/certs/<certfile>

   # Certificate and key files for client cert authentication to the server.
   cert_file: /etc/prometheus/certs/<certfile>
   key_file: /etc/prometheus/certs/<keyfile>

   # Disable validation of the server certificate.
   insecure_skip_verify: false

Authentification de base et TLS

Si vous souhaitez utiliser les paramètres d’authentification de base et TLS dans votre configmap/CRD, assurez-vous que le secret ama-metrics-mtls-secret inclut toutes les clés dans la section des données avec leurs valeurs codées en base64 correspondantes, comme indiqué ci-dessous :

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  certfile: base64_cert_content    # used for TLS
  keyfile: base64_key_content      # used for TLS
  password1: base64-encoded-string # used for basic auth
  password2: base64-encoded-string # used for basic auth

Remarque

Remarque

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. Cela est dû au fait que le secret ama-metrics-mtls-secret est monté dans le chemin d’accès /etc/prometheus/certs/ dans le conteneur.

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

Vérifiez que le nom du secret est ama-metrics-mtls-secret et qu’il se trouve dans l’espace de noms kube-system.

Le secret doit être créé en premier, puis le configmap, PodMonitor ou ServiceMonitor doit être créé dans l’espace de noms kube-system. L’ordre de création des secrets a une importance. Lorsqu’il n’existe pas de secret mais qu’un configmap, PodMonitor ou ServiceMonitor pointe vers le secret, l’erreur suivante s’affiche dans les journaux de conteneur ama-metrics prometheus-collector : no file found for cert....

Pour en savoir plus sur les paramètres de configuration TLS, suivez les indications de la section Configurations.

É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