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 behöver en nod med tillräckligt med processor och minne. Om replikpodden ama-metrics inte är schemalagd på en nod- eller nodpool med tillräckligt med resurser kan den hämta OOMKilled och gå till CrashLoopBackoff. Du kan åtgärda detta genom att lägga till etiketten azuremonitor/metrics.replica.preferred=true i en nod- eller nodpool i klustret med högre resurser (i systemnodpoolen). Detta säkerställer att replikpodden schemaläggs på den noden. Du kan också skapa extra systempooler med större noder och lägga till samma etikett. Det är bättre att märka nodpooler i stället för enskilda noder så att nya noder i poolen också kan användas för schemaläggning.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"