Scrape Prometheus-mått i stor skala i Azure Monitor
Den här artikeln innehåller vägledning om prestanda som kan förväntas när samlingsmått i hög skala för Azure Monitor-hanterad tjänst för Prometheus.
CPU och minne
Cpu- och minnesanvändningen korreleras med antalet byte för varje exempel och antalet prover som skrapats. Dessa riktmärken baseras på de standardmål som skrapats, mängden anpassade mått som skrapats och antalet noder, poddar och containrar. Dessa tal är avsedda som referens eftersom användningen fortfarande kan variera avsevärt beroende på antalet tidsserier och byte per mått.
Den övre volymgränsen per podd är för närvarande cirka 3–3,5 miljoner prover per minut, beroende på antalet byte per prov. Den här begränsningen åtgärdas när horisontell partitionering läggs till i framtiden.
Agenten består av en distribution med en replik och DaemonSet för att skrapa mått. DaemonSet skrapar alla mål på nodnivå, till exempel cAdvisor, kubelet och nodexportör. Du kan också konfigurera den för att skrapa alla anpassade mål på nodnivå med statiska konfigurationer. Replikuppsättningen skrapar allt annat, till exempel kube-state-metrics eller anpassade skrapjobb som använder tjänstidentifiering.
Jämförelse mellan små och stora kluster för replikering
| Skrapmål | Skickade exempel/minut | Antal noder | Antal poddar | Prometheus-Collector cpu-användning (kärnor) | Prometheus-Collector minnesanvändning (byte) |
|---|---|---|---|---|---|
| standardmål | 11,344 | 3 | 40 | 12.9 mc | 148 Mi |
| standardmål | 260,000 | 340 | 13000 | 1.10 c | 1,70 GB |
| standardmål + anpassade mål |
3,56 miljoner | 340 | 13000 | 5.13 c | 9,52 GB |
Jämförelse mellan små och stora kluster för DaemonSets
| Skrapmål | Skickade exempel/minutsumma | Skickade exempel/minut/podd | Antal noder | Antal poddar | Prometheus-Collector total CPU-användning (kärnor) | Prometheus-Collector total minnesanvändning (byte) | Prometheus-Collector cpu-användning/podd (kärnor) | Prometheus-Collector minnesanvändning/podd (byte) |
|---|---|---|---|---|---|---|---|---|
| standardmål | 9,858 | 3,327 | 3 | 40 | 41.9 mc | 581 Mi | 14.7 mc | 189 Mi |
| standardmål | 2,3 miljoner | 14,400 | 340 | 13000 | 805 mc | 305,34 GB | 2.36 mc | 898 Mi |
För fler anpassade mått fungerar den enskilda podden på samma sätt som replikpodden beroende på volymen av anpassade mått.
Schemalägga en ama-måttreplikpodd på en nodpool med fler resurser
En stor mängd mått per podd kräver en tillräckligt stor nod för att kunna hantera processor- och minnesanvändningen som krävs. Om ama-metrics-replikpodden inte schemaläggs på en nod eller nodpool som har tillräckligt med resurser, kan den fortsätta att få OOMKilled och gå till CrashLoopBackoff. Om du har en nod eller nodpool i klustret som har högre resurser (i systemnodpoolen) och vill att repliken ska schemaläggas på noden, kan du lägga till etiketten azuremonitor/metrics.replica.preferred=true på noden så schemaläggs replikpodden på den här noden. Du kan också skapa ytterligare systempooler, om det behövs, med större noder och lägga till samma etikett i noderna eller nodpoolen. Det är också bättre att lägga till etiketter i nodpoolen i stället för noder så att nyare noder i samma pool också kan användas för schemaläggning när den här etiketten gäller för alla noder i poolen.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"