Supprimer les métriques Prometheus à grande échelle dans Azure Monitor
Cet article fournit des conseils sur les performances qui peuvent être attendues lors de la collecte des métriques à grande échelle pour le service managé Azure Monitor pour Prometheus.
Processeur et mémoire
L’utilisation du processeur et de la mémoire est mise en corrélation avec le nombre d’octets de chaque échantillon et avec le nombre d’échantillons scrapés. Ces points de référence sont basés sur les cibles scrapées par défaut, le volume de métriques personnalisées scrapées et le nombre de nœuds, de pods et de conteneurs. Ces nombres doivent servir de référence, car l’utilisation peut toujours varier considérablement en fonction du nombre de séries chronologiques et d’octets par métrique.
La limite de volume supérieure par pod est actuellement d’environ 3 à 3,5 millions d’échantillons par minute, selon le nombre d’octets par échantillon. Cette limitation sera traitée lorsque le partitionnement sera ajouté à l’avenir.
L’agent se compose d’un déploiement avec un réplica et d’un DaemonSet pour le scraping des métriques. Le DaemonSet scrape toutes les cibles au niveau du nœud telles que cAdvisor, kubelet et l’exportateur de nœuds. Vous pouvez également le configurer pour supprimer toutes les cibles personnalisées au niveau du nœud avec des configurations statiques. Le jeu de réplicas scrape tout le reste, comme les métriques kube-state-metrics ou les travaux de scraping personnalisés qui utilisent la découverte de service.
Comparaison entre des petits et des grands clusters pour des réplicas
| Cibles de scraping | Échantillons envoyés / minute | Nombre de nœuds | Nombre de pods | Utilisation du processeur Prometheus-Collector (cœurs) | Utilisation de la mémoire Prometheus-Collector (octets) |
|---|---|---|---|---|---|
| Cibles par défaut | 11 344 | 3 | 40 | 12,9 mc | 148 Mi |
| Cibles par défaut | 260 000 | 340 | 13 000 | 1.10 c | 1,70 Go |
| Cibles par défaut + Cibles personnalisées |
3,56 millions | 340 | 13 000 | 5.13 c | 9,52 Go |
Comparaison entre des petits et des grands clusters pour des DaemonSets
| Cibles de scraping | Total d’échantillons envoyés / minute | Échantillons envoyés / minute / pod | Nombre de nœuds | Nombre de pods | Utilisation totale du processeur Prometheus-Collector (cœurs) | Utilisation totale de la mémoire Prometheus-Collector (octets) | Utilisation du processeur Prometheus-Collector / pod (cœurs) | Utilisation de la mémoire Prometheus-Collector / pod (octets) |
|---|---|---|---|---|---|---|---|---|
| Cibles par défaut | 9 858 | 3 327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 Mi |
| Cibles par défaut | 2,3 millions | 14 400 | 340 | 13 000 | 805 mc | 305,34 Go | 2,36 mc | 898 Mi |
Pour obtenir plus de métriques personnalisées, le pod unique se comporte comme le pod du réplica en fonction du volume de métriques personnalisées.
Planifier un pod de réplica ama-metrics sur un pool de nœuds avec plus de ressources
Un grand volume de métriques par pod a besoin d’un nœud avec des ressources en processeur et en mémoire suffisantes. Si le pod de réplica ama-metrics n’est pas planifié sur un nœud ou un pool de nœuds avec suffisamment de ressources, il peut être OOMKilled et passer en mode CrashLoopBackoff. Pour résoudre ce problème, vous pouvez ajouter l’étiquette azuremonitor/metrics.replica.preferred=true à un nœud ou à un pool de nœuds sur votre cluster avec des ressources plus élevées (dans le pool de nœuds système). Cela permet de garantir que le pod de réplica est planifié sur ce nœud. Vous pouvez également créer des pools système supplémentaires avec des nœuds plus grands et ajouter la même étiquette. Il est préférable d’étiqueter des pools de nœuds plutôt que des nœuds individuels afin que les nouveaux nœuds du pool puissent également être utilisés pour la planification.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"