Auslesen von Prometheus-Metriken im großen Umfang in Azure Monitor
Dieser Artikel bietet einen Leitfaden zur Leistung, die bei der Sammlung von Metriken im großen Umfang für den verwalteten Azure Monitor-Dienst für Prometheus erzielt werden kann.
CPU und Arbeitsspeicher
Die CPU- und Speicherauslastung korreliert mit der Anzahl der Bytes jeder Stichprobe und der Anzahl ausgelesener Stichproben. Diese Benchmarks basieren auf den ausgelesenen Standardzielen, dem Volumen der ausgelesenen benutzerdefinierten Metriken und der Anzahl von Knoten, Pods und Containern. Diese Zahlen sind als Anhaltspunkte zu verstehen, da die Auslastung je nach Anzahl der Zeitreihen und Bytes pro Metrik erheblich variieren kann.
Die Volumenobergrenze pro Pod liegt derzeit bei etwa 3–3,5 Millionen Stichproben pro Minute, je nach Anzahl der Bytes pro Stichprobe. Diese Einschränkung wird behoben, wenn Sharding demnächst hinzugefügt wird.
Der Agent besteht aus einer Bereitstellung mit einem Replikat und DaemonSet für das Auslesen von Metriken. Das DaemonSet liest alle Ziele auf Knotenebene aus, wie cAdvisor, Kubelet und Node-Exporter. Sie können die Konfiguration auch ändern, sodass alle benutzerdefinierten Ziele auf Knotenebene mit statischen Konfigurationen ausgelesen werden. Die Replikatgruppe liest alle anderen Daten aus, z. B. kube-state-metrics oder benutzerdefinierte Ausleseaufträge, die die Dienstermittlung nutzen.
Vergleich zwischen kleinen und großen Clustern für Replikate
| Ausleseziele | Gesendete Stichproben/Minute | Anzahl von Knoten | Podanzahl | Prometheus-Collector: CPU-Auslastung (Kerne) | Prometheus-Collector: Speicherauslastung (Bytes) |
|---|---|---|---|---|---|
| Standardziele | 11.344 | 3 | 40 | 12,9 mc | 148 Mi |
| Standardziele | 260.000 | 340 | 13.000 | 1,10 c | 1,70 GB |
| Standardziele + benutzerdefinierte Ziele |
3,56 Mio. | 340 | 13.000 | 5,13 c | 9,52 GB |
Vergleich zwischen kleinen und großen Clustern für DeamonSets
| Ausleseziele | Gesendete Stichproben/Minute insgesamt | Gesendete Stichproben/Minute/Pod | Anzahl von Knoten | Podanzahl | Prometheus-Collector: CPU-Auslastung insgesamt (Kerne) | Prometheus-Collector: Speicherauslastung insgesamt (Bytes) | Prometheus-Collector: CPU-Auslastung/Pod (Kerne) | Prometheus-Collector: Speicherauslastung/Pod (Bytes) |
|---|---|---|---|---|---|---|---|---|
| Standardziele | 9.858 | 3.327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 Mi |
| Standardziele | 2,3 Mio. | 14\.400 | 340 | 13.000 | 805 mc | 305,34 GB | 2,36 mc | 898 Mi |
Bei weiteren benutzerdefinierten Metriken verhält sich der einzelne Pod abhängig vom Volumen der benutzerdefinierten Metriken genauso wie der Replikatpod.
Planen eines ama-metrics-Replikatpods für einen Knotenpool mit weiteren Ressourcen
Eine große Anzahl von Metriken pro Pod benötigt einen Knoten mit ausreichend CPU und Arbeitsspeicher. Wenn der Replikatpod ama-metrics nicht für einen Knoten- oder Knotenpool mit ausreichend Ressourcen geplant ist, wird möglicherweise OOMKilled angewendet, und er wechselt in CrashLoopBackoff. Um dies zu beheben, können Sie einem Knoten- oder Knotenpool in Ihrem Cluster mit mehr Ressourcen die Bezeichnung azuremonitor/metrics.replica.preferred=true hinzufügen (im Systemknotenpool). Dadurch wird sichergestellt, dass der Replikatpod auf diesem Knoten geplant wird. Sie können auch zusätzliche Systempools mit größeren Knoten erstellen und dieselbe Bezeichnung hinzufügen. Es ist besser, Knotenpools anstelle einzelner Knoten zu bezeichnen, damit neue Knoten im Pool auch für die Planung verwendet werden können.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"