Metrische gegevens van Prometheus scrapen op schaal 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 elk voorbeeld en het aantal gesloopte voorbeelden. Deze benchmarks zijn gebaseerd op de standaarddoelen die zijn gesloopt, het aantal aangepaste metrische gegevens dat is gesloopt 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 maximale volumelimiet per pod is momenteel ongeveer 3-3,5 miljoen samples per minuut, afhankelijk van het aantal bytes per steekproef. Deze beperking wordt verholpen 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 schraapt 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 schraapt al het andere, zoals kube-state-metrics of aangepaste scrape-taken die gebruikmaken van servicedetectie.
Vergelijking tussen klein en groot cluster voor replica
| Scrape-doelen | 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
| Scrape-doelen | Verzonden voorbeelden/minutentotaal | Verzonden voorbeelden / minuut / pod | Aantal knooppunten | Aantal pods | Prometheus-Collector TOTAAL CPU-gebruik (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 met ama-metrische gegevens plannen in een knooppuntgroep met meer resources
Een groot aantal metrische gegevens per pod vereist een groot genoeg knooppunt om het vereiste CPU- en geheugengebruik te kunnen verwerken. Als de replicapod ama-metrics niet wordt gepland op een knooppunt of knooppuntpool met voldoende resources, wordt deze mogelijk OOMKilled en gaat deze naar CrashLoopBackoff. Als u dit probleem wilt oplossen, kunt u het label azuremonitor/metrics.replica.preferred=true op het knooppunt toevoegen aan het knooppunt en de replicapod op dit knooppunt toevoegen om dit probleem op te lossen. Als u een knooppunt of knooppuntpool in uw cluster hebt met hogere resources (in de systeemknooppuntgroep) en de replicapod op dit knooppunt wilt plannen. U kunt ook extra systeemgroepen maken, indien nodig, met grotere knooppunten en hetzelfde label toevoegen aan hun knooppunt(en) of knooppuntpool. Het is ook beter om labels toe te voegen aan nodepool in plaats van knooppunten, zodat nieuwere knooppunten in dezelfde pool ook kunnen worden gebruikt voor planning wanneer dit label van toepassing is op alle knooppunten in de pool.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"