Résoudre des problèmes de collecte de métriques Prometheus dans Azure Monitor

Article
04/22/2024

Les étapes décrites dans cet article permettent de déterminer la raison pour laquelle les métriques Prometheus ne sont pas collectées comme prévu dans Azure Monitor.

Le pod réplica supprime les métriques de kube-state-metrics, les cibles de récupération personnalisées dans le configmap ama-metrics-prometheus-config et les cibles de récupération personnalisées définies dans les ressources personnalisées. Les pods DaemonSet scrapent les métriques des cibles suivantes sur leurs nœuds respectifs : kubelet, cAdvisor, node-exporter et scrapent des cibles personnalisées dans le ConfigMap ama-metrics-prometheus-config-node. Le pod, pour lequel vous souhaitez afficher les journaux et l’interface utilisateur Prometheus, dépend de votre cible de scraping.

Résoudre les problèmes à l’aide d’un script PowerShell

Si vous rencontrez une erreur alors que vous tentez d’activer la supervision pour votre cluster AKS, veuillez suivre les instructions mentionnées ici pour exécuter le script de résolution des problèmes. Ce script est conçu pour effectuer un diagnostic de base des problèmes de configuration sur votre cluster et vous pouvez consulter les fichiers générés lors de la création d’une demande de support pour une résolution plus rapide de votre cas de support.

Limitation des métriques

Dans le Portail Azure, accédez à votre espace de travail Azure Monitor. Dans le menu Metrics, vérifiez que les métriques Active Time Series % Utilization et Events Per Minute Ingested % Utilization sont inférieures à 100 %.

Si l’une d’elles dépasse 100 %, l’ingestion dans cet espace de travail est limitée. Dans le même espace de travail, accédez à New Support Request pour créer une demande d’augmentation des limites. Sélectionnez Service and subscription limits (quotas) comme type de problème et Managed Prometheus comme type de quota.

Lacunes intermittentes dans la collecte des données de métriques

Pendant les mises à jour des nœuds, vous pouvez voir un intervalle de 1 à 2 minutes dans les données de métriques collectées à partir de notre collecteur au niveau du cluster. Cet écart est dû au fait que le nœud sur lequel il s’exécute est mis à jour dans le cadre d’un processus de mise à jour normal. Cela affecte les cibles à l’échelle du cluster telles que kube-state-metrics et les cibles d’application personnalisées spécifiées. Elle se produit lorsque votre cluster est mis à jour manuellement ou via la mise à jour automatique. Ce comportement est attendu et se produit en raison de la mise à jour du nœud sur lequel il s’exécute. Aucune de nos règles d’alerte recommandées n’est affectée par ce comportement.

État du pod

Vérifier l’état du pod avec la commande suivante :

kubectl get pods -n kube-system | grep ama-metrics

Il devrait y avoir un pod réplica ama-metrics-xxxxxxxxxx-xxxxx, un pod ama-metrics-operator-targets-*, un pod ama-metrics-ksm-* et un pod ama-metrics-node-* pour chaque nœud sur le cluster.
L’état de chaque pod devrait être Running, et chaque pod devrait présenter un nombre de redémarrages égal au nombre de modifications configmap appliquées. Le pod ama-metrics-operator-targets-* peut avoir un redémarrage supplémentaire au début et cela est attendu :

Si l’état de chaque pod est Running mais qu’un ou plusieurs pods présentent des redémarrages, exécutez la commande suivante :

kubectl describe pod <ama-metrics pod name> -n kube-system

Cette commande affiche la raison des redémarrages. Des redémarrages de pods sont attendus si des modifications de configmap ont été apportées. Si la raison du redémarrage est OOMKilled, le pod ne peut pas suivre le volume de métriques. Consultez les recommandations d’échelle pour le volume de métriques.

Si les pods s’exécutent comme prévu, l’emplacement suivant à vérifier est les journaux du conteneur.

Journaux de conteneur

Affichez les journaux de conteneur avec la commande suivante :

kubectl logs <ama-metrics pod name> -n kube-system -c prometheus-collector

Au démarrage, toutes les erreurs initiales apparaissent en rouge, tandis que les avertissements apparaissent en jaune (l’affichage des journaux colorés nécessite au moins PowerShell version 7 ou une distribution Linux).

Vérifiez s’il existe un problème d’obtention du jeton d’authentification :
- Le message Aucune configuration présente pour la ressource AKS est journalisé toutes les 5 minutes.
- Le pod redémarre toutes les 15 minutes et chaque essai renvoie l’erreur : Aucune configuration n’est présente pour la ressource AKS.
  - Si c’est le cas, vérifiez que la règle et le point de terminaison de collecte de données ont bien été définis dans votre groupe de ressources.
  - Vérifiez également que l’espace de travail Azure Monitor existe.
  - Vérifiez l’absence de cluster AKS privé et assurez-vous que l’espace de travail n’est pas lié à une étendue de liaison privée Azure Monitor pour un autre service. Ce scénario n’est actuellement pas pris en charge.

Traitement de la configuration

Affichez les journaux de conteneur avec la commande suivante :

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c config-reader

Vérifiez l’absence d’erreur d’analyse de la configuration Prometheus, de fusion avec des cibles d’extraction par défaut activées et de la validation de la configuration complète.
Si vous avez inclus une configuration Prometheus personnalisée, vérifiez qu’elle est reconnue dans les journaux. Si ce n’est pas le cas :
- Dans l’espace de noms kube-system, vérifiez que le nom de votre ConfigMap est correct : ama-metrics-prometheus-config.
- Vérifiez que, dans le ConfigMap, votre configuration Prometheus se trouve dans une section appelée prometheus-config sous data, comme illustré ici :
```
kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config
  namespace: kube-system
data:
  prometheus-config: |-
    scrape_configs:
    - job_name: <your scrape job here>
```
Si vous avez créé des ressources personnalisées, vous devriez avoir rencontré des erreurs de validation lors de la création de moniteurs de pod/service. Si vous ne voyez toujours pas les métriques des cibles, assurez-vous que les journaux n’affichent aucune erreur.

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c targetallocator

Vérifiez l’absence d’erreur de MetricsExtension concernant l’authentification auprès de l’espace de travail Azure Monitor.
Vérifiez l’absence d’erreur du OpenTelemetry collector sur le scraping des cibles.

Exécutez la commande suivante :

kubectl logs <ama-metrics pod name> -n kube-system -c addon-token-adapter

Cette commande affiche une erreur en cas de problème d’authentification auprès de l’espace de travail Azure Monitor. L’exemple ci-dessous montre des journaux sans problèmes :

En l’absence d’erreur dans les journaux, l’interface Prometheus peut être utilisée pour le débogage afin de vérifier la configuration attendue et les cibles en cours d’extraction.

Interface Prometheus

Chaque pod ama-metrics-* dispose de l’interface utilisateur Prometheus en mode agent sur le port 9090. Les cibles de configuration personnalisée et de ressources personnalisées sont récupérées par le pod ama-metrics-* et les cibles de nœud par le pod ama-metrics-node-*. Effectuez un réacheminement de port vers le pod réplica ou l’un des pods daemonset pour vérifier la configuration, la détection de services et les points de terminaison cibles, comme décrit ici. Vous vous assurerez que les configurations personnalisées sont correctes, que les cibles prévues ont été détectées pour chaque travail et qu’il n’y a pas d’erreurs lors du scraping de cibles spécifiques.

Exécutez la commande kubectl port-forward <ama-metrics pod> -n kube-system 9090.

Ouvrez un navigateur à l’adresse 127.0.0.1:9090/config. Cette interface utilisateur a la configuration complète de scrape. Vérifiez que tous les travaux sont inclus dans la configuration.
Accédez à 127.0.0.1:9090/service-discovery pour afficher les cibles découvertes par l’objet découverte de service spécifié et ce que les relabel_configs ont filtré comme cibles. Par exemple, s’il manque les métriques d’un pod, vous pouvez voir si ce pod a été découvert et quel est son URI. Vous pouvez ensuite utiliser cet URI lors de l’examen des cibles pour voir s’il existe des erreurs d’extraction.
Accédez à 127.0.0.1:9090/targets pour voir tous les travaux, la dernière fois que le point de terminaison de ce travail a été extrait, et toutes les erreurs

Ressources personnalisées

Si vous avez inclus des ressources personnalisées, assurez-vous qu’elles apparaissent sous configuration, découverte de service et cibles.

Configuration

Découverte de service

Targets

S’il n’y a aucun problème et que les cibles prévues sont en cours d’extraction, vous pouvez afficher les métriques exactes en cours d’extraction en activant le mode débogage.

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.

Le module complémentaire des métriques peut être configuré pour s’exécuter en mode débogage en modifiant le paramètre configmap enabled sous debug-mode en true, en suivant les instructions fournies ici.

Quand il est activé, toutes les métriques Prometheus scrapées sont hébergées sur le port 9091. Exécutez la commande suivante :

kubectl port-forward <ama-metrics pod name> -n kube-system 9091

Accédez à 127.0.0.1:9091/metrics dans un navigateur pour voir si les métriques ont été extraites par le collecteur OpenTelemetry. Vous pouvez accéder à cette interface utilisateur pour chaque pod ama-metrics-*. S’il n’y a pas de métriques, il se peut qu’il y ait un problème avec les longueurs de nom de métrique ou d’étiquette, ou le nombre d’étiquettes. Assurez-vous également que le quota d’ingestion pour les métriques Prometheus n’est pas dépassé, comme expliqué dans cet article.

Noms de métrique, noms d’étiquette et valeurs d’étiquette

L’extraction basée sur un agent présente actuellement les limitations répertoriées dans le tableau suivant :

Propriété	Limite
Longueur du nom d’étiquette	Inférieure ou égale à 511 caractères. Lorsque cette limite est dépassée pour une série chronologique dans un travail, tout le travail de scraping échoue, et les métriques sont supprimées de ce travail avant l’ingestion. Vous pouvez voir up=0 pour ce travail, et l’Ux cible indique la raison pour up=0.
Longueur de la valeur d’étiquette	Inférieure ou égale à 1023 caractères. Lorsque cette limite est dépassée pour une série chronologique d’un travail, l’ensemble du scraping échoue, et les métriques sont supprimées de ce travail avant l’ingestion. Vous pouvez voir up=0 pour ce travail, et l’Ux cible indique la raison pour up=0.
Nombre d’étiquettes par série chronologique	Inférieur ou égal à 63. Lorsque cette limite est dépassée pour une série chronologique dans un travail, tout le travail de scraping échoue, et les métriques sont supprimées de ce travail avant l’ingestion. Vous pouvez voir up=0 pour ce travail, et l’Ux cible indique la raison pour up=0.
Longueur du nom de la mesure	Inférieure ou égale à 511 caractères. Lorsque cette limite est dépassée pour une série chronologique dans un travail, seule la série en question est supprimée. MetricextensionConsoleDebugLog permet de tracer la métrique supprimée.
Noms d’étiquettes avec une casse différente	Dans une même métrique, si deux étiquettes ont une casse différente, alors elles sont considérées comme doublons et sont supprimées lors de l’ingestion. Par exemple, la série chronologique `my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1}` est supprimée en raison de doublons, car `ExampleLabel` et `examplelabel` sont considérés comme un même nom d’étiquette.

Vérifiez le quota d’ingestion sur l’espace de travail Azure Monitor

En cas d’omission de métriques, vous pouvez d’abord vérifier si les limites d’ingestion de votre espace de travail Azure Monitor sont dépassées. Dans le Portail Azure, vous pouvez consulter en temps réel les données d’utilisation de n’importe quel espace de travail Azure Monitor. En temps réel, vous pouvez afficher les métriques d’utilisation dans le menu Metrics de l’espace de travail Azure Monitor. Chaque espace de travail Azure Monitor dispose, par défaut, des métriques d’utilisation suivantes.

Séries chronologiques actives : le nombre de séries chronologiques uniques récemment ingérées dans l’espace de travail au cours des 12 dernières heures
Limite des séries chronologiques actives : nombre maximal de séries chronologiques uniques qui peuvent être ingérées de manière active dans l’espace de travail
Pourcentage d’utilisation des séries chronologiques actives : pourcentage de séries chronologiques actives actuellement utilisées
Événements ingérés par minute : nombre d’événements (échantillons) reçus par minute récemment
Limite d’événements ingérés par minute : nombre maximal d’événements par minute qui peuvent être ingérés avant d’atteindre la limite
Pourcentage d’utilisation des événements ingérés par minute : taux d’ingestion des métriques utilisé dans la limite actuelle

Consultez les quotas et limites du service pour connaître les quotas par défaut et les augmentations possibles en fonction de votre utilisation. Vous pouvez demander une augmentation du quota pour les espaces de travail Azure Monitor à partir du menu Support Request de l’espace de travail Azure Monitor. Dans la demande de support, veillez à inclure l’ID, l’ID interne et la localisation/la région de l’espace de travail Azure Monitor que vous trouverez dans le menu « Propriétés » de l’espace de travail Azure Monitor dans le Portail Azure.

Étapes suivantes

Vérifiez les considérations relatives à la collecte des métriques à grande échelle.