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 schrapt alle andere taken, zoals metrische gegevens van kube-state of aangepaste scrapetaken 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
Een groot aantal metrische gegevens per pod heeft een knooppunt met voldoende CPU en geheugen nodig. Als de replicapod van ama-metrische gegevens niet is gepland op een knooppunt of knooppuntgroep met voldoende resources, wordt deze mogelijk door OOMKilled uitgevoerd en gaat u naar CrashLoopBackoff. U kunt dit oplossen door het label azuremonitor/metrics.replica.preferred=true toe te voegen aan een knooppunt of knooppuntgroep in uw cluster met hogere resources (in systeemknooppuntgroep). Dit zorgt ervoor dat de replicapod wordt gepland op dat knooppunt. U kunt ook extra systeemgroepen met grotere knooppunten maken en hetzelfde label toevoegen. Het is beter om knooppuntgroepen te labelen in plaats van afzonderlijke knooppunten, zodat nieuwe knooppunten in de pool ook kunnen worden gebruikt voor planning.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Volgende stappen
- Problemen met het verzamelen van Prometheus-gegevens oplossen.