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 insamlingsmå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 exempel som skrapats. Dessa riktmärken baseras på de skrapade standardmålen, mängden anpassade mått som skrapats och antalet noder, poddar och containrar. Dessa tal är avsedda som en 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 exempel per minut, beroende på antalet byte per exempel. 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 replik
Skrapmål | Skickade exempel/minut | Antal noder | Antal poddar | Prometheus-Collector CPU-användning (kärnor) | Minnesanvändning för Prometheus-Collector (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 | Antal skickade exempel/minut totalt | Skickade exempel/minut/podd | Antal noder | Antal poddar | Prometheus-Collector CPU Usage Total (kärnor) | Total minnesanvändning för Prometheus-Collector (byte) | Prometheus-Collector CPU-användning/podd (kärnor) | Minnesanvändning för Prometheus-Collector/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 replikpodden ama-metrics 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 den processor- och minnesanvändning som krävs. Om replikpodden ama-metrics inte schemaläggs på en nod eller nodpool som har tillräckligt med resurser kan den fortsätta att hämta OOMKilled och gå till CrashLoopBackoff. Om du har en nod eller nodpool i klustret som har högre resurser (i systemnodpoolen) och vill schemalägga repliken 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"