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 replicaset scrape tout le reste, comme les métriques kube-state-metrics ou les travaux de scraping personnalisés qui utilisent la détection 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 nécessite un nœud suffisamment volumineux pour pouvoir gérer l’utilisation du processeur et de la mémoire requise. Si le pod du réplica ama-metrics n’est pas planifié sur un nœud ou un pool de nœuds disposant des ressources suffisantes, il peut continuer à obtenir des erreurs OOMKilled et accédez à CrashLoopBackoff. Pour résoudre ce problème, si vous avez un nœud ou pool de nœuds sur votre cluster disposant de ressources plus élevées (dans le pool de nœuds système) et que vous souhaitez obtenir la planification du réplica sur ce nœud, vous pouvez ajouter l’étiquette azuremonitor/metrics.replica.preferred=true sur le nœud, et le pod du réplica sera planifié sur ce nœud. Si nécessaire, vous pouvez également créer un ou plusieurs pools système supplémentaires avec des nœuds plus grands et ajouter la même étiquette à leur ou leurs nœuds ou à leur pool de nœuds. Il est également préférable d’ajouter des étiquettes au pool de nœuds plutôt qu’à des nœuds, afin que les nœuds plus récents du même pool puissent également être utilisés pour la planification lorsque cette étiquette s’applique à tous les nœuds du pool.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"