Udostępnij za pośrednictwem

Złomowanie metryk Prometheus na dużą skalę w usłudze Azure Monitor

  • Artykuł

Ten artykuł zawiera wskazówki dotyczące wydajności, które mogą być oczekiwane w przypadku metryk zbierania na dużą skalę dla usługi zarządzanej Azure Monitor dla usługi Prometheus.

Procesor CPU 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 obiektach docelowych złomowanych, woluminach metryk niestandardowych oraz liczbie węzłów, zasobników i kontenerów. Liczby te są przeznaczone jako odwołanie, ponieważ użycie nadal może się znacznie 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 zestawem DaemonSet na potrzeby złomowania metryk. DaemonSet złomuje wszystkie cele na poziomie węzła, takie jak cAdvisor, kubelet i eksporter węzłów. Można ją również skonfigurować tak, aby usuwała wszystkie niestandardowe obiekty docelowe na poziomie węzła ze statycznymi konfiguracjami. Zestaw replik zeskrapuje wszystkie inne elementy, takie jak kube-state-metrics lub niestandardowe zadania złomowania korzystające z odnajdywania usług.

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 Prometheus-Collector użycie procesora CPU (rdzenie) Prometheus-Collector użycie pamięci (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 demonów

Elementy docelowe zeskrobania Przykłady wysłane / łączna liczba minut Przykłady wysłane / minuta / zasobnik Liczba węzłów Liczba zasobników Prometheus-Collector całkowite użycie procesora CPU (rdzenie) Prometheus-Collector łączna liczba użycia pamięci (bajty) Prometheus-Collector użycie procesora CPU/zasobnika (rdzenie) użycie pamięci Prometheus-Collector /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 ilości metryk niestandardowych.

Planowanie zasobnika repliki ama-metrics w puli węzłów z większą pulą zasobów

Duża liczba metryk na zasobnik wymaga wystarczająco dużego węzła, aby można było obsłużyć wymagane użycie procesora CPU i pamięci. Jeśli zasobnik repliki ama-metrics nie jest zaplanowany w węźle lub puli węzłów, która ma wystarczającą ilość zasobów, może to spowodować zatrzymanie operacji OOMKilled i przejście do pozycji CrashLoopBackoff. Aby rozwiązać ten problem, jeśli masz węzeł lub pulę węzłów w klastrze z wyższymi zasobami (w puli węzłów systemowych) i chcesz uzyskać replikę zaplanowaną w tym węźle, możesz dodać etykietę azuremonitor/metrics.replica.preferred=true w węźle, a zasobnik repliki zostanie zaplanowany na tym węźle. W razie potrzeby można również utworzyć dodatkowe pule systemowe z większymi węzłami i dodać tę samą etykietę do ich węzłów lub puli węzłów. Lepiej jest również dodać etykiety do puli węzłów , a nie węzłów, aby nowsze węzły w tej samej puli mogły być również używane do planowania, gdy ta etykieta ma zastosowanie do wszystkich węzłów w puli.

kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"

Następne kroki