Scrape Prometheus metryki na dużą skalę w usłudze Azure Monitor
Ten artykuł zawiera wskazówki dotyczące wydajności, które można oczekiwać, gdy metryki kolekcji na dużą skalę dla usługi zarządzanej Azure Monitor dla rozwiązania Prometheus.
Procesor i pamięć
Użycie procesora CPU i pamięci jest skorelowane z liczbą bajtów każdej próbki i liczbą próbek zeskrobanych. Te testy porównawcze są oparte na domyślnych miejscach docelowych zeskropanych, ilości niestandardowych metryk oraz liczbie węzłów, zasobników i kontenerów. Te liczby są przeznaczone jako odwołanie, ponieważ użycie może nadal znacznie się różnić w zależności od liczby szeregów czasowych i bajtów na metrykę.
Górny limit objętości na zasobnik wynosi obecnie około 3–3,5 miliona próbek na minutę, w zależności od liczby bajtów na próbkę. To ograniczenie zostało rozwiązane podczas dodawania fragmentowania w przyszłości.
Agent składa się z wdrożenia z jedną repliką i elementem DaemonSet na potrzeby złomowania metryk. Zestaw DaemonSet złomuje wszystkie cele na poziomie węzła, takie jak cAdvisor, kubelet i eksporter węzłów. Można go również skonfigurować tak, aby zeskrobać wszystkie niestandardowe obiekty docelowe na poziomie węzła ze statycznymi konfiguracjami. Zestaw replik zeskroba wszystkie inne elementy, takie jak kube-state-metrics lub niestandardowe zadania zeskrobywania, które korzystają z odnajdywania usługi.
Porównanie małych i dużych klastrów dla repliki
| Elementy docelowe zeskrobania | Przykłady wysłane /minuta | Liczba węzłów | Liczba zasobników | Użycie procesora CPU modułu zbierającego Prometheus (rdzenie) | Użycie pamięci modułu zbierającego Prometheus (bajty) |
|---|---|---|---|---|---|
| domyślne elementy docelowe | 11,344 | 3 | 40 | 12,9 mc | 148 Mi |
| domyślne elementy docelowe | 260,000 | 340 | 13000 | 1.10 c | 1,70 GB |
| domyślne elementy docelowe + niestandardowe elementy docelowe |
3,56 mln | 340 | 13000 | 5.13 c | 9,52 GB |
Porównanie małych i dużych klastrów dla zestawów DaemonSet
| Elementy docelowe zeskrobania | Liczba wysłanych próbek na minutę | Przykłady wysłane/minutowe/zasobnik | Liczba węzłów | Liczba zasobników | Prometheus-Collector Cpu Total (rdzenie) | Prometheus-Collector Memory Usage Total (bajty) | Użycie procesora CPU modułu zbierającego Prometheus/Zasobnik (rdzenie) | Użycie pamięci modułu zbierającego prometheus/zasobnik (bajty) |
|---|---|---|---|---|---|---|---|---|
| domyślne elementy docelowe | 9,858 | 3,327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 Mi |
| domyślne elementy docelowe | 2,3 mln | 14,400 | 340 | 13000 | 805 mc | 305,34 GB | 2.36 mc | 898 Mi |
W przypadku większej liczby metryk niestandardowych pojedynczy zasobnik zachowuje się tak samo jak zasobnik repliki w zależności od liczby metryk niestandardowych.
Planowanie zasobnika repliki ama-metrics w puli węzłów z większą ilością zasobów
Duża liczba metryk na zasobnik wymaga węzła z wystarczającą ilością procesora CPU i pamięci. Jeśli zasobnik repliki ama-metrics nie jest zaplanowany w węźle lub puli węzłów z wystarczającą ilością zasobów, może to spowodować zabicie OOM i przejście do elementu CrashLoopBackoff. Aby rozwiązać ten problem, możesz dodać etykietę azuremonitor/metrics.replica.preferred=true do puli węzłów lub węzłów w klastrze z wyższymi zasobami (w puli węzłów systemowych). Dzięki temu zasobnik repliki zostanie zaplanowany na tym węźle. Możesz również utworzyć dodatkowe pule systemowe z większymi węzłami i dodać tę samą etykietę. Lepiej jest oznaczyć pule węzłów, a nie poszczególne węzły, aby można było również używać nowych węzłów w puli do planowania.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Następne kroki
- Rozwiązywanie problemów z zbieraniem danych rozwiązania Prometheus.