Scorporare le metriche di Prometheus su larga scala in Monitoraggio di Azure
Questo articolo fornisce indicazioni sulle prestazioni che possono essere previste per 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 scorporati. Questi benchmark sono basati sulle destinazioni predefinite scorporate, sul volume delle metriche personalizzate scorporate e sul numero di nodi, pod e contenitori. Questi numeri sono indicativi 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-3,5 milioni di campioni al minuto, a seconda del numero di byte per campione. Questa limitazione viene risolta quando il partizionamento orizzontale viene aggiunto successivamente.
L'agente è costituito da una distribuzione con una replica e DaemonSet per le metriche di scorporo. DaemonSet scorpora tutte le destinazioni a livello di nodo, ad esempio cAdvisor, kubelet e l’utilità di esportazione dei nodi. È possibile configurarlo anche per scorporare tutte le destinazioni personalizzate a livello di nodo con configurazioni statiche. Il set di repliche elimina tutto il resto, 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
| Obiettivi di scorporo | Campioni inviati al minuto | Numero di nodi | Numero di pod | Utilizzo CPU Prometheus-Collector (core) | Utilizzo memoria Prometheus-Collector (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
| Obiettivi di scorporo | Campioni totali inviati al minuto | Campioni inviati al minuto per pod | Numero di nodi | Numero di pod | Utilizzo totale CPU Prometheus-Collector (core) | Utilizzo totale memoria Prometheus-Collector (byte) | Utilizzo CPU prometheus-Collector/Pod (core) | Utilizzo memoria Prometheus-Collector/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 altre risorse
Un volume elevato di metriche per ogni pod richiede un nodo con cpu e memoria sufficienti. Se il pod di replica ama-metrics non è pianificato in un nodo o in un pool di nodi con risorse sufficienti, potrebbe ottenere OOMKilled e passare a CrashLoopBackoff. Per risolvere questo problema, è possibile aggiungere l'etichetta azuremonitor/metrics.replica.preferred=true a un nodo o a un pool di nodi nel cluster con risorse più elevate (nel pool di nodi di sistema). In questo modo il pod di replica viene pianificato in tale nodo. È anche possibile creare pool di sistema aggiuntivi con nodi più grandi e aggiungere la stessa etichetta. È preferibile etichettare i pool di nodi anziché i singoli nodi in modo che i nuovi nodi nel pool possano essere usati anche per la pianificazione.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"