Créer et valider un fichier de configuration personnalisé pour les métriques Prometheus dans Azure Monitor
Outre les cibles d’extraction par défaut que l’agent Prometheus Azure Monitor extrait par défaut, procédez comme suit pour fournir une configuration d’extraction supplémentaire à l’agent à l’aide d’un configmap. L’agent Prometheus Azure Monitor ne comprend pas ou ne traite pas les CRD d’opérateur pour la configuration d’extraction, mais utilise la configuration Prometheus native telle que définie dans Configuration Prometheus.
Les 2 configmaps qui peuvent être utilisés pour le scraping de cible personnalisé sont :
- ama-metrics-prometheus-config (Recommandé) : lorsqu’un configmap portant ce nom est créé, les travaux de scraping définis dans celui-ci sont exécutés à partir du pod réplica de métriques Azure Monitor en cours d’exécution dans le cluster.
- ama-metrics-prometheus-config-node (Avancé) : lorsqu’un configmap portant ce nom est créé, les travaux de scraping définis dans celui-ci sont exécutés à partir de chaque pod Linux DaemonSet en cours d’exécution dans le cluster. Pour plus d’informations, consultez la Configuration avancée.
- ama-metrics-prometheus-config-node-windows (Avancé) : lorsqu’un configmap portant ce nom est créé, les travaux de scraping définis dans celui-ci sont exécutés à partir de chaque DaemonSet Windows. Pour plus d’informations, consultez la Configuration avancée.
Créer un fichier de configuration Prometheus
Un moyen plus simple de créer des travaux de configuration d’extraction (scrape) Prometheus :
- Étape 1 : Utilisez un fichier de configuration (yaml) pour créer/définir des travaux d’extraction.
- Étape 2 : Validez le fichier de configuration d’extraction à l’aide d’un outil personnalisé (comme spécifié dans cet article), puis convertir ce fichier de configuration en configmap.
- Étape 3 : Déployez le fichier de configuration scrape en tant que configmap sur vos clusters.
De cette façon, il est plus facile de créer une configuration yaml (qui est extrêmement sensible aux espaces) et de ne pas ajouter d’espaces involontaires en créant directement la configuration scrape à l’intérieur du ConfigMap.
Créez un fichier de configuration d’extraction Prometheus nommé prometheus-config. Pour plus d’informations sur la création d’une configuration d’extraction (scrape) pour Prometheus, consultez les conseils et exemples de configuration. Vous pouvez également consulter la référence de configuration d’extraction Prometheus.ior. Votre liste de fichiers de configuration répertoriera les configurations d’extraction sous la section scrape_configs, et pourra éventuellement utiliser la section globale pour définir les paramètres scrape_interval, scrape_timeout et external_labels globaux.
Conseil
Les modifications apportées à la section globale auront un impact sur les configurations par défaut et la configuration personnalisée.
Voici un exemple de fichier de configuration d’extraction Prometheus :
global:
scrape_interval: 30s
scrape_configs:
- job_name: my_static_config
scrape_interval: 60s
static_configs:
- targets: ['my-static-service.svc.cluster.local:1234']
- job_name: prometheus_example_app
scheme: http
kubernetes_sd_configs:
- role: service
relabel_configs:
- source_labels: [__meta_kubernetes_service_name]
action: keep
regex: "prometheus-example-service"
Valider le fichier de configuration d’extraction
L’agent utilise l’outil promconfigvalidator pour valider la configuration Prometheus qui lui est donnée via le configmap. Si la configuration n’est pas valide, l’agent complémentaire n’utilisera pas la configuration personnalisée donnée. Une fois que vous avez votre fichier de configuration Prometheus, vous pouvez éventuellement utiliser l’outil promconfigvalidator pour valider votre configuration avant de créer un configmap que l’agent consomme.
L’outil promconfigvalidator se trouve dans le module complémentaire de métriques Azure Monitor. Vous pouvez utiliser l’un des pods ama-metrics-node-* dans l’espace de noms kube-system de votre cluster pour télécharger l’outil de validation. Utilisez kubectl cp de télécharger l’outil et sa configuration :
for podname in $(kubectl get pods -l rsName=ama-metrics -n=kube-system -o json | jq -r '.items[].metadata.name'); do kubectl cp -n=kube-system "${podname}":/opt/promconfigvalidator ./promconfigvalidator; kubectl cp -n=kube-system "${podname}":/opt/microsoft/otelcollector/collector-config-template.yml ./collector-config-template.yml; chmod 500 promconfigvalidator; done
Après avoir copié le fichier exécutable et yaml, recherchez le chemin d’accès de votre fichier de configuration Prometheus. Remplacez ensuite <config path> et exécutez le validateur avec la commande :
./promconfigvalidator/promconfigvalidator --config "<config path>" --otelTemplate "./promconfigvalidator/collector-config-template.yml"
L’exécution du validateur génère le fichier de configuration fusionné merged-otel-config.yaml si aucun chemin d’accès n’est fourni avec le paramètre facultatif output. N’utilisez pas ce fichier fusionné comme configuration pour l’agent collecteur de métriques, car il est utilisé uniquement à des fins de validation et de débogage d’outil.
Déployer le fichier de configuration en tant que configmap
Votre fichier de configuration Prometheus personnalisé est consommé en tant que champ nommé prometheus-config dans un ou plusieurs configmap(s) complémentaires ama-metrics-prometheus-config (ou) ama-metrics-prometheus-config-node (ou) ama-metrics-prometheus-config-node-windows de métriques dans l’espace de noms kube-system. Vous pouvez créer un configmap à partir du fichier de configuration d’extraction que vous avez créé ci-dessus, en renommant votre fichier de configuration Prometheus en prometheus-config (sans extension de fichier) et en exécutant une ou plusieurs des commandes suivantes, selon le configmap que vous souhaitez créer pour votre configuration de travail d’extraction personnalisée.
Ex : pour créer un configmap pour replicaset
kubectl create configmap ama-metrics-prometheus-config --from-file=prometheus-config -n kube-system
Cela aura pour effet de créer un configmap nommé ama-metrics-prometheus-config dans l’espace de noms kube-system. Le pod réplica des métriques Azure Monitor redémarre ensuite en 30 à 60 secondes pour appliquer la nouvelle configuration. Pour voir s’il y a des problèmes avec la validation, le traitement ou la fusion de la configuration, vous pouvez examiner les pods du réplica ama-metrics.
Ex : pour créer un configmap pour DaemonSet Linux
kubectl create configmap ama-metrics-prometheus-config-node --from-file=prometheus-config -n kube-system
Cela aura pour effet de créer un configmap nommé ama-metrics-prometheus-config-node dans l’espace de noms kube-system. Le pod réplica des métriques Azure Monitor redémarre ensuite en 30 à 60 secondes pour appliquer la nouvelle configuration. Pour voir s’il y a des problèmes avec la validation, le traitement ou la fusion de la configuration, vous pouvez examiner les pods du DaemonSet Linux ama-metrics-node.
Ex : pour créer un configmap pour DaemonSet Windows
kubectl create configmap ama-metrics-prometheus-config-node-windows --from-file=prometheus-config -n kube-system
Cela aura pour effet de créer un configmap nommé ama-metrics-prometheus-config-node-windows dans l’espace de noms kube-system. Tous les pods DaemonSet Windows des métriques Azure Monitor redémarrent ensuite en 30 à 60 secondes pour appliquer la nouvelle configuration. Pour voir s’il y a des problèmes avec la validation, le traitement ou la fusion de la configuration, vous pouvez examiner les pods du DaemonSet Windows ama-metrics-win-node.
Vérifiez que le fichier de configuration Prometheus est nommé prometheus-config avant d’exécuter la commande suivante, car le nom de fichier est utilisé comme nom de paramètre configmap.
Cela aura pour effet de créer un configmap nommé ama-metrics-prometheus-config dans l’espace de noms kube-system. Le pod de métriques Azure Monitor redémarre ensuite pour appliquer la nouvelle configuration. Pour voir s’il y a des problèmes avec la validation, le traitement ou la fusion de la configuration, vous pouvez examiner les pods ama-metrics.
Vous trouverez un exemple de configmap ama-metrics-prometheus-configici.
Dépannage
Si vous avez correctement créé le configmap (ama-metrics-prometheus-config ou ama-metrics-prometheus-config-node) dans l’espace de noms kube-system et que vous ne voyez toujours pas les cibles personnalisées scrapées, vérifiez les erreurs dans les journaux de pod replica pour le configmap ama-metrics-prometheus-config ou des journaux daemonset pod pour le configmap ama-metrics-prometheus-config-node) à l’aide des journaux kubectl et assurez-vous qu’il n’y a aucune erreur dans la section Commencer à fusionner les configurations Prometheus par défaut et personnalisées avec le préfixe prometheus-config-merger
Remarque
Configuration avancée : configurer des travaux de scraping Prometheus personnalisés pour le DaemonSet
Le pod de réplica ama-metrics consomme la configuration Prometheus personnalisée et scrape les cibles spécifiées. Pour un cluster avec un grand nombre de nœuds et de pods et un grand volume de métriques à scraper, certaines cibles de scraping personnalisées applicables peuvent être déchargées du pod de réplica ama-metrics unique vers le pod DaemonSet ama-metrics.
Le ConfigMap ama-metrics-prometheus-config-node, similaire au ConfigMap de replicat-set, peut être créé pour avoir des configurations de scraping statiques sur chaque nœud. La configuration scraping ne doit cibler qu’un seul nœud et ne doit pas utiliser d’annotations de découverte de service/pod. Sinon, chaque nœud tente de scraper toutes les cibles et effectue de nombreux appels au serveur API de Kubernetes.
Les cibles de scraping personnalisées peuvent suivre le même format à l’aide de static_configs avec des cibles utilisant la variable d'environnement $NODE_IP et en spécifiant le port à scraper. Chaque pod de daemonset prend la configuration, scrape les métriques et les envoie pour ce nœud.
Exemple : la configuration node-exporter ci-dessous est l’une des cibles par défaut des pods DaemonSet. Il utilise la variable d’environnement $NODE_IP, qui est déjà définie pour chaque conteneur de module complémentaire ama-metrics afin de cibler un port spécifique sur le nœud.
- job_name: nodesample
scrape_interval: 30s
scheme: http
metrics_path: /metrics
relabel_configs:
- source_labels: [__metrics_path__]
regex: (.*)
target_label: metrics_path
- source_labels: [__address__]
replacement: '$NODE_NAME'
target_label: instance
static_configs:
- targets: ['$NODE_IP:9100']