Personnaliser le scraping des métriques Prometheus dans le service managé pour Prometheus d’Azure Monitor
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-system
l'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.
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 nomskube-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
- alias de cluster (pour modifier la valeur de l’étiquette
ama-metrics-prometheus-config
Ce 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 nomskube-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éesama-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 nomskube-system
de votre clusterama-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 nomskube-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"
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/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.
- Configuration à l’aide de CRD pour la configuration d’extraction personnalisée
- Fichier config pour la configuration d’extraction personnalisée
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: '.+'
Authentification de base
- Configurations d’extraction à l’aide de fichier config
- Capturer des configurations avec CRD(moniteur de pod/service)
Si vous utilisez le paramètre basic_auth
dans votre configuration Prometheus, veuillez suivre les étapes -
- 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 quelle chaîne, 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>
Le secret ama-metrics-mtls-secret est monté sur les conteneurs ama-metrics dans le chemin - /etc/prometheus/certs/ et est mis à la disposition du processus qui capture les métriques Prometheus. La clé( ex - password1) dans l’exemple ci-dessus sera le nom de fichier, la valeur est décodée en base64 et ajoutée au contenu du fichier dans le conteneur, et le scraper Prometheus utilise le contenu de ce fichier pour obtenir la valeur utilisée comme mot de passe pour récupérer le point de terminaison.
- Dans le configmap pour la configuration de scrape personnalisée, utilisez le paramètre suivant. 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 à un fichier qui contient le mot de passe.
basic_auth:
username: <username string>
password_file: /etc/prometheus/certs/password1
En fournissant le chemin d’accès au password_file ci-dessus, le scraper Prometheus utilise le contenu du fichier nommé password1 dans le chemin /etc/prometheus/certs comme valeur de mot de passe pour la récupération basée sur l’authentification de base.
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 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.
Procédez comme suit.
Créez un secret dans l'espace de noms du système Kube 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 à ceux spécifiés dans la section des données. Les valeurs secrètes doivent être encodées en base64 avant d’être placées dans la section des données, comme ci-dessous.
Vous trouverez ci-dessous un exemple de création de secret avec YAML.
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 conteneurs ama-metrics dans le chemin - /etc/prometheus/certs/ et est mis à la disposition du processus qui capture les métriques Prometheus. La clé( ex - certfile) dans l’exemple ci-dessus sera le nom de fichier, la valeur est décodée en base64 et ajoutée au contenu du fichier dans le conteneur, et le scraper Prometheus utilise le contenu de ce fichier pour obtenir la valeur utilisée comme mot de passe pour récupérer le point de terminaison.
Vous trouverez ci-dessous les détails sur la façon de fournir les paramètres de configuration TLS via un ConfigMap ou CRD.
- Capturer des configurations à l’aide du fichier de configuration
- Capturer des configurations avec CRD(moniteur de pod/service)
- Pour fournir le paramètre de configuration TLS dans un configmap, suivez l’exemple ci-dessous.
tls_config:
ca_file: /etc/prometheus/certs/<certfile> # since it is self-signed
cert_file: /etc/prometheus/certs/<certfile>
key_file: /etc/prometheus/certs/<keyfile>
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 tous les fichiers(clés) dans la section des données avec leurs valeurs codées en base 64 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. 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.
Assurez-vous 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éé, 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....
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