Condividi tramite

Metriche di Scrape Prometheus su larga scala in Monitoraggio di Azure

  • Articolo

Questo articolo fornisce indicazioni sulle prestazioni che possono essere previste quando le metriche di raccolta su larga scala per il servizio gestito di Monitoraggio di Azure per Prometheus.

CPU e memoria

L'utilizzo della CPU e della memoria è correlato al numero di byte di ogni campione e al numero di campioni eliminati. Questi benchmark si basano sulle destinazioni predefinite rasate, sul volume delle metriche personalizzate raschiate e sul numero di nodi, pod e contenitori. Questi numeri sono destinati a un riferimento poiché l'utilizzo può comunque variare in modo significativo a seconda del numero di serie temporali e byte per metrica.

Il limite massimo di volume per pod è attualmente di circa 3,5 milioni di campioni al minuto, a seconda del numero di byte per campione. Questa limitazione viene risolta quando il partizionamento viene aggiunto in futuro.

L'agente è costituito da una distribuzione con una replica e DaemonSet per le metriche di scraping. DaemonSet elimina qualsiasi destinazione a livello di nodo, ad esempio cAdvisor, kubelet e l'esportazione di nodi. È anche possibile configurarlo per eseguire lo scrape di tutte le destinazioni personalizzate a livello di nodo con configurazioni statiche. Il set di repliche elimina tutti gli altri elementi, ad esempio kube-state-metrics o processi di scrape personalizzati che usano l'individuazione dei servizi.

Confronto tra cluster di piccole e grandi dimensioni per la replica

Destinazioni di ritaglio Esempi inviati/minuti Numero di nodi Conteggio pod Prometheus-Collector utilizzo cpu (core) Prometheus-Collector utilizzo della memoria (byte)
destinazioni predefinite 11,344 3 40 12,9 mc 148 Mi
destinazioni predefinite 260,000 340 13000 1.10 c 1,70 GB
destinazioni predefinite
+ Destinazioni personalizzate		 3,56 milioni 340 13000 5.13 c 9,52 GB

Confronto tra cluster di piccole e grandi dimensioni per DaemonSet

Destinazioni di ritaglio Esempi inviati/ Totale minuto Esempi inviati/minuti/pod Numero di nodi Conteggio pod Prometheus-Collector totale utilizzo CPU (core) Prometheus-Collector totale utilizzo memoria (byte) Prometheus-Collector utilizzo CPU/Pod (core) Prometheus-Collector Utilizzo memoria/Pod (byte)
destinazioni predefinite 9,858 3,327 3 40 41,9 mc 581 Mi 14,7 mc 189 Mi
destinazioni predefinite 2,3 milioni 14.400 340 13000 805 mc 305,34 GB 2,36 mc 898 Mi

Per altre metriche personalizzate, il singolo pod si comporta come il pod di replica a seconda del volume delle metriche personalizzate.

Pianificare il pod di replica ama-metrics in un pool di nodi con più risorse

Un volume elevato di metriche per pod richiede un nodo sufficiente per gestire l'utilizzo della CPU e della memoria richiesto. Se il pod di replica ama-metrics non viene pianificato in un nodo o in un nodepool con risorse sufficienti, potrebbe mantenere OOMKilled e passare a CrashLoopBackoff. Per risolvere questo problema, se si dispone di un nodo o un nodepool nel cluster con risorse superiori (nel pool di nodi di sistema) e si vuole ottenere la replica pianificata in tale nodo, è possibile aggiungere l'etichetta azuremonitor/metrics.replica.preferred=true nel nodo e il pod di replica verrà pianificato in questo nodo. È anche possibile creare pool di sistema aggiuntivi, se necessario, con nodi più grandi e può aggiungere la stessa etichetta ai nodi o nodepool. È anche consigliabile aggiungere etichette a nodepool anziché nodi in modo che i nodi più recenti nello stesso pool possano essere usati anche per la pianificazione quando questa etichetta è applicabile a tutti i nodi nel pool.

kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"

Passaggi successivi