Metrische gegevens van Prometheus op schaal schrooten in Azure Monitor
Dit artikel bevat richtlijnen voor prestaties die kunnen worden verwacht bij het verzamelen van metrische gegevens op grote schaal voor de beheerde Azure Monitor-service voor Prometheus.
CPU en geheugen
Het CPU- en geheugengebruik is gecorreleerd met het aantal bytes van elke steekproef en het aantal gesroote steekproeven. Deze benchmarks zijn gebaseerd op de standaarddoelen die zijn geschraapt, het volume van aangepaste metrische gegevens wordt gesroot en het aantal knooppunten, pods en containers. Deze getallen zijn bedoeld als referentie omdat het gebruik nog steeds aanzienlijk kan variëren, afhankelijk van het aantal tijdreeksen en bytes per metrische waarde.
De bovengrens per pod is momenteel ongeveer 3-3,5 miljoen steekproeven per minuut, afhankelijk van het aantal bytes per steekproef. Deze beperking wordt opgelost wanneer sharding in de toekomst wordt toegevoegd.
De agent bestaat uit een implementatie met één replica en DaemonSet voor het scrapen van metrische gegevens. De DaemonSet schrapt alle doelen op knooppuntniveau, zoals cAdvisor, kubelet en knooppuntexporteur. U kunt deze ook configureren om aangepaste doelen op knooppuntniveau te scrapen met statische configuraties. De replicaset scrapt alles anders, zoals kube-state-metrics of aangepaste scrape jobs die gebruikmaken van servicedetectie.
Vergelijking tussen klein en groot cluster voor replica
| Knipdoelen | Verzonden voorbeelden per minuut | Aantal knooppunten | Aantal pods | Prometheus-Collector CPU-gebruik (kernen) | Prometheus-Collector Geheugengebruik (bytes) |
|---|---|---|---|---|---|
| standaarddoelen | 11,344 | 3 | 40 | 12,9 mc | 148 mi |
| standaarddoelen | 260,000 | 340 | 13000 | 1,10 c | 1,70 GB |
| standaarddoelen + aangepaste doelen |
3,56 miljoen | 340 | 13000 | 5,13 c | 9,52 GB |
Vergelijking tussen klein en groot cluster voor DaemonSets
| Knipdoelen | Voorbeelden verzonden / minuuttotaal | Voorbeelden verzonden / minuut / pod | Aantal knooppunten | Aantal pods | Totaal CPU-gebruik prometheus-collector (kernen) | Totaal geheugengebruik prometheus-collector (bytes) | Prometheus-Collector CPU-gebruik / pod (kernen) | Prometheus-Collector-geheugengebruik/pod (bytes) |
|---|---|---|---|---|---|---|---|---|
| standaarddoelen | 9,858 | 3,327 | 3 | 40 | 41,9 mc | 581 mi | 14,7 mc | 189 mi |
| standaarddoelen | 2,3 miljoen | 14,400 | 340 | 13000 | 805 mc | 305,34 GB | 2,36 mc | 898 Mi |
Voor meer aangepaste metrische gegevens gedraagt de ene pod zich hetzelfde als de replicapod, afhankelijk van het volume van aangepaste metrische gegevens.
Een replicapod voor ama-metrische gegevens plannen in een knooppuntgroep met meer resources
Voor een groot aantal metrische gegevens per pod is een groot genoeg knooppunt vereist om het VEREISTE CPU- en geheugengebruik te kunnen verwerken. Als de replicapod met metrische gegevens van ama niet wordt gepland op een knooppunt of knooppuntpool met voldoende resources, blijft deze mogelijk OOMKilled krijgen en naar CrashLoopBackoff gaan. Om dit probleem op te lossen, kunt u, als u een knooppunt of knooppuntpool op uw cluster hebt met hogere resources (in de systeemknooppuntgroep) en de replica op dat knooppunt wilt laten plannen, het label azuremonitor/metrics.replica.preferred=true op het knooppunt toevoegen en de replicapod wordt gepland op dit knooppunt. U kunt indien nodig ook extra systeemgroepen maken, met grotere knooppunten en hetzelfde label toevoegen aan hun knooppunt(en) of nodepool. Het is ook beter om labels toe te voegen aan knooppuntpool in plaats van knooppunten, zodat nieuwere knooppunten in dezelfde pool ook kunnen worden gebruikt voor het plannen wanneer dit label van toepassing is op alle knooppunten in de pool.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Volgende stappen
- Problemen met het verzamelen van Prometheus-gegevens oplossen.