La dernière version d'ARMS Prometheus est Helm v1.1.17, qui correspond à l'agent v4.0.0. Cette version intègre plusieurs améliorations visant à renforcer la stabilité de la collecte, corriger des bugs connus et optimiser la consommation de ressources.
Si votre cluster exécute un agent ARMS Prometheus de la série v3.x.x, nous vous recommandons vivement de le mettre à niveau vers la dernière version. Les versions plus anciennes peuvent contenir des composants non optimisés et présenter un risque de déconnexion des données.
Nouveautés de la version v4.0.0
|
Type de modification |
Description |
|
Nouveau |
Ajout d'une tâche de collecte pour les événements du cluster afin de prendre en charge le tableau de bord Kubernetes Deployment. |
|
Nouveau |
Ajout de métriques d'auto-surveillance basées sur les accords de niveau de service (SLA) pour alimenter le tableau de bord de stabilité des SLA. |
|
Nouveau |
Prise en charge de l'authentification BasicAuth dans ServiceMonitor. Le Secret doit se trouver dans le même namespace que le ServiceMonitor. |
|
Nouveau |
Ajout d'une fonctionnalité de métadonnées de métriques pour afficher la signification de métriques spécifiques. |
|
Nouveau |
L'agent peut désormais transmettre sa version de chart au serveur, qui utilise ce numéro de version pour initialiser ou mettre à niveau les tableaux de bord. |
|
Nouveau |
Ajout de métriques d'auto-surveillance RemoteWrite pour suivre la durée d'envoi de chaque lot de données. |
|
Nouveau |
Ajout de métriques d'auto-surveillance pour les erreurs et la latence de la collecte de métriques de base. |
|
Nouveau |
Ajout de métriques d'auto-surveillance pour les erreurs et la latence de la collecte de métriques métier. |
|
Amélioration |
Amélioration de la configuration par défaut |
|
Amélioration |
Amélioration de la méthode de découverte de services pour les tâches de collecte CSI, principalement pour la collecte PersistentVolume (PV). |
|
Amélioration |
Optimisation de la fréquence de |
|
Amélioration |
Simplification de certaines entrées de journal et enrichissement d'autres pour fournir des informations de temporisation plus détaillées pour le pipeline de scraping. |
|
Amélioration |
Amélioration des tâches de collecte de métriques de base pour utiliser un intervalle de scraping et un délai d'expiration fixes, les découplant ainsi de la configuration globale pour réduire les interférences. |
|
Amélioration |
Optimisation de la logique d'interaction en mode multi-réplicas maître-esclave. Les réplicas maître et worker n'interfèrent plus les uns avec les autres, ce qui renforce la stabilité globale. |
|
Amélioration |
Amélioration de la stratégie de distribution des cibles depuis le réplica maître, réduisant la consommation CPU d'environ 30 % et la consommation mémoire de 40 % pour améliorer les performances de collecte. |
|
Amélioration |
Optimisation du traitement |
|
Amélioration |
Optimisation de la logique de l'écouteur Informer pour les scénarios multi-locataires, réduisant la consommation CPU d'environ 20 %. |
|
Amélioration |
Amélioration de la gestion des échecs intermittents de résolution CoreDNS. L'agent utilise désormais une adresse IP mise en cache, réduisant la dépendance à la résolution DNS en temps réel et augmentant la stabilité de la transmission des données. |
|
Amélioration |
Optimisation de la logique de distribution des configurations de scraping via |
|
Amélioration |
Optimisation de la stratégie de pré-scraping sur le réplica maître pour réduire la consommation de ressources et améliorer ses capacités de découverte de services et de planification des cibles. |
|
Amélioration |
Ajout d'une gestion adaptative pour les lots de données uniques dépassant 1 Mo afin de réduire la perte de données causée par les limitations du backend. |
|
Correction |
Correction d'un problème dans |
|
Correction |
Correction d'un problème dans les scénarios multi-locataires où des mises à jour retardées du cache des libellés Pod provoquaient la division d'une seule série temporelle en deux. |
|
Correction |
Correction d'un problème où le réplica maître échouait parfois à distribuer les cibles à un réplica ayant redémarré ou rencontré une erreur Out-Of-Memory (OOM), entraînant l'omission de cibles de scraping. |
|
Correction |
Correction de problèmes liés à l'analyse du type Secret et à la transmission des en-têtes dans RemoteWrite. |
|
Correction |
Correction d'un problème où l'action de désactivation |
|
Correction |
Correction d'un problème où les paramètres par défaut globaux et |
Risques liés à la mise à niveau
Risque de mise à niveau : cette mise à niveau vers Helm v1.1.17/agent v4.0.0 est disruptive. Selon la charge de collecte de métriques de votre cluster (nombre de cibles et de séries temporelles), vous pouvez rencontrer une brève interruption des données. La perturbation devrait durer entre 0 et 5 minutes, mais cela peut varier selon les clusters.
Avant la mise à niveau : effectuez les vérifications préalables décrites dans Étape 1 : Vérifications préalables à la mise à niveau (obligatoire) afin de minimiser l'impact sur les données de surveillance de votre cluster.
Après la mise à niveau : si vous constatez des problèmes de données, suivez les étapes indiquées dans Étape 3 : Vérifications post-mise à niveau (facultatif). Si un problème persiste, consultez la section FAQ post-mise à niveau. Pour toute assistance supplémentaire, contactez nos experts techniques sur DingTalk (ID : aliprometheus).
Procédure de mise à niveau
Étape 1 : Vérifications préalables à la mise à niveau (obligatoire)
Lorsque vous mettez à niveau depuis une version Helm antérieure à la 1.1.16 vers la version 1.1.17, la mise à niveau ne conserve pas vos paramètres personnalisés. Vous devez vérifier l'existence de paramètres personnalisés avant la mise à niveau. Si vous souhaitez conserver ces paramètres, vous devez les réappliquer manuellement une fois la mise à niveau terminée.
Les mises à niveau depuis la version Helm 1.1.16 ou ultérieure héritent automatiquement des paramètres personnalisés, il n'est donc pas nécessaire de les réappliquer lors des mises à niveau suivantes. Suivez ces étapes pour vérifier vos paramètres avant la mise à niveau :
Connectez-vous à la console Container Service for Kubernetes (ACK).
Cliquez sur le nom de votre cluster cible. Dans le volet de navigation de gauche, choisissez Workload > Stateless. Sélectionnez le namespace
arms-prom. Recherchez la charge de travailarms-prometheus-ack-arms-prometheuset, dans la colonne Operation, choisissez More > View YAML pour afficher la configuration YAML complète.-
Vérifiez les paramètres suivants et notez toutes les valeurs personnalisées que vous souhaitez conserver :
spec.replicas: la valeur par défaut après la mise à niveau est 1. Si votre valeur actuelle est différente, notez-la.-
spec.containers.args: il s'agit des paramètres de démarrage de l'agent pour le mode multi-locataire. Si le mode multi-locataire n'est pas activé, ce champ peut être absent. Si vous avez personnalisé ces paramètres, notez leurs valeurs :tenant_useridtenant_clusteridtenant_token
-
spec.containers.resources: les limites par défaut sont de 3 cœurs et 4 Go de mémoire. Les requêtes par défaut sont de 1 cœur et 1 Go de mémoire.Si vos paramètres diffèrent, notez les valeurs afin de pouvoir les réappliquer après la mise à niveau.
Après la mise à niveau, utilisez la même méthode pour afficher la configuration YAML, modifiez le fichier pour réappliquer vos valeurs personnalisées, puis cliquez sur Update pour enregistrer les modifications.
Étape 2 : Procédure de mise à niveau
Nous vous recommandons de mettre à niveau la version Helm du composant ARMS Prometheus via la console ACK. Suivez ces étapes :
Connectez-vous à la console Container Service for Kubernetes (ACK).
Cliquez sur le nom de votre cluster cible. Dans le volet de navigation de gauche, choisissez Operations > Component Management. Cliquez sur l'onglet Logs and Monitoring, recherchez la carte ack-arms-prometheus et cliquez sur Upgrade.
-
Une fois la mise à niveau terminée, choisissez Operations > Managed Service for Prometheus dans le volet de navigation de gauche. Dans le coin supérieur droit, cliquez sur Go to ARMS Prometheus. Vous êtes redirigé vers la page de liste des instances Prometheus dans la console Managed Service for Prometheus, où vous pouvez consulter l'état de l'agent et les détails de la collecte de métriques.
Pour vérifier la mise à niveau, vous pouvez également cliquer sur Settings dans le volet de navigation de gauche et vérifier la version du composant dans l'onglet Settings.
Étape 3 : Vérifications post-mise à niveau (facultatif)
Connectez-vous à la console ARMS.
Dans le volet de navigation de gauche, choisissez .
Connectez-vous à la console Cloud Monitor.
Dans le volet de navigation de gauche, choisissez pour ouvrir la liste des instances pour Managed Service for Prometheus.
Cliquez sur le nom de votre instance Prometheus cible. Dans le volet de navigation de gauche, cliquez sur Service Discovery. Cliquez sur l'onglet Targets pour examiner l'état de vos tâches de collecte.
Dans le volet de navigation de gauche, cliquez sur Settings. Dans l'onglet Self-Monitoring, cliquez sur View Grafana Dashboard dans le coin supérieur droit. Après la mise à niveau, surveillez l'état de fonctionnement de l'agent. Assurez-vous que le nombre de réplicas est correct et qu'il n'y a aucune anomalie concernant les taux d'envoi de données, la consommation de ressources ou le nombre d'erreurs.
-
Sur la page Self-Monitoring, cliquez sur l'onglet Agent Self-monitoring pour afficher le tableau de bord d'auto-surveillance de l'agent Prometheus.
Après la mise à niveau, vérifiez les quatre tâches de collecte de métriques de base :
_arms/kubelet/cadvisor,_arms/kubelet/metric,_kube-state-metricsetnode-exporter. Utilisez le sélecteur de plage de temps dans le coin supérieur droit pour comparer les données d'avant et après la mise à niveau afin de détecter d'éventuels problèmes de collecte.
FAQ post-mise à niveau
Incohérence du nombre de réplicas après la mise à niveau
Vérifiez si des réplicas d'agent sont dans l'état Pending. L'agent ARMS Prometheus nécessite que tous les réplicas soient dans l'état Running pour fonctionner correctement. Vous pouvez afficher l'état de tous les réplicas sur la page Workload > Stateless de votre cluster cible dans la console ACK, sous le namespace arms-prom.
Consommation élevée de ressources après la mise à niveau
Vérifiez la présence d'erreurs de transmission de données. De telles erreurs peuvent provoquer une accumulation de données dans la mémoire de l'agent, entraînant une augmentation de la consommation de ressources. Vous pouvez afficher l'utilisation de la mémoire et du CPU de l'agent Prometheus dans la console ACK. Accédez à la page Operations > Managed Service for Prometheus de votre cluster cible, cliquez sur l'onglet Others et recherchez la section Prometheus Agent pour afficher l'utilisation des ressources.
Métriques de base manquantes ou discontinues
Si vous constatez des problèmes avec des métriques de base telles que node_*** (icône ①), container_*** (icône ②), kubelet_*** (icône ③) ou kube_*** (icône ④), vérifiez si les tâches de collecte correspondantes signalent des erreurs. Vous pouvez vérifier l'état de ces tâches dans l'onglet Service Discovery > Targets de la console Managed Service for Prometheus. Si vous trouvez des erreurs, contactez nos experts techniques sur DingTalk (ID : aliprometheus) pour obtenir de l'aide.
Baisse du trafic RemoteWrite ou perte de données
Si vous n'avez pas configuré RemoteWrite, vous pouvez ignorer ce problème.
Si vous avez configuré RemoteWrite, sachez que dans l'agent v4.0.0, le paramètre
write_relabel_configsest désormais activé par défaut, contrairement aux versions précédentes. Si votre configuration inclut des actions telles quedropoukeep, vous pouvez observer une baisse du trafic. Vous pouvez ajuster ce paramètre selon vos besoins. Pour ce faire, accédez à la page Settings dans la console Managed Service for Prometheus. Dans l'onglet Settings, cliquez sur Edit Prometheus.yaml et modifiez la configuration.