VictoriaMetrics to szybki i skalowalny system DBMS służący do przechowywania i przetwarzania danych w postaci szeregów czasowych (rekord składa się z czasu i zestawu wartości odpowiadających temu czasowi, uzyskanych np. poprzez okresowe odpytywanie stanu czujników lub zbiór metryk).
Nazywam się Kolobaev Pavel. DevOps, SRE, LeroyMerlin, wszystko jest jak kod – wszystko dotyczy nas: mnie i innych pracowników LeroyMerlin.
Istnieje chmura oparta na OpenStack. Istnieje małe łącze do radaru technicznego.
Jest zbudowany na sprzęcie Kubernetes, a także na wszystkich powiązanych usługach dla OpenStack i rejestrowania.
To jest schemat, który mieliśmy w fazie rozwoju. Kiedy to wszystko opracowywaliśmy, mieliśmy operator Prometheus, który przechowywał dane w samym klastrze K8. Automatycznie znajduje to, co trzeba wyszorować i, z grubsza mówiąc, kładzie to pod nogami.
Będziemy musieli przenieść wszystkie dane poza klaster Kubernetes, bo jeśli coś się stanie, musimy zrozumieć, co i gdzie.
Pierwsze rozwiązanie jest takie, że z federacji korzystamy wtedy, gdy mamy zewnętrznego Prometheusa, gdy przechodzimy do klastra Kubernetes poprzez mechanizm federacyjny.
Ale są tu pewne małe problemy. W naszym przypadku problemy zaczęły się, gdy mieliśmy 250 000 metryk, a gdy było ich 400 000, zdaliśmy sobie sprawę, że nie możemy tak pracować. Zwiększyliśmy scrape_timeout do 25 sekund.
Dlaczego musieliśmy to zrobić? Prometeusz zaczyna odliczanie przerwy od początku płotu. Nie ma znaczenia, że dane nadal płyną. Jeżeli w tym określonym czasie dane nie zostaną scalone i sesja nie zostanie zamknięta przez http, wówczas sesję uważa się za nieudaną i dane nie dostają się do samego Prometheusa.
Każdy zna wykresy, które otrzymujemy, gdy brakuje niektórych danych. Harmonogramy są naderwane i nie jesteśmy z tego zadowoleni.
Następną opcją jest sharding w oparciu o dwa różne Prometheusy za pomocą tego samego mechanizmu federacji.
Na przykład po prostu weź je i podziel na kawałki według nazwy. Można to również wykorzystać, ale zdecydowaliśmy się przejść dalej.
Będziemy teraz musieli jakoś przetworzyć te odłamki. Możesz wziąć promxy, który przechodzi do obszaru fragmentu i mnoży dane. Działa z dwoma fragmentami jako pojedynczym punktem wejścia. Można to wdrożyć za pomocą promxy, ale nadal jest to zbyt trudne.
Pierwsza opcja jest taka, że chcemy porzucić mechanizm federacyjny, ponieważ jest on bardzo powolny.
Twórcy Prometheusa wyraźnie mówią: „Chłopaki, użyjcie innego TimescaleDB, ponieważ nie będziemy wspierać długoterminowego przechowywania metryk”. To nie jest ich zadanie.
Zapisujemy na kartce, którą musimy jeszcze wyładować na zewnątrz, aby nie przechowywać wszystkiego w jednym miejscu.
Drugą wadą jest zużycie pamięci. Tak, rozumiem, że wielu powie, że w 2020 roku kilka gigabajtów pamięci kosztuje ani grosza, ale nadal.
Teraz mamy środowisko deweloperskie i prod. W wersji deweloperskiej jest to około 9 gigabajtów na 350 000 wskaźników. W prodzie jest to 14 gigabajtów i nieco ponad 780 000 danych. Jednocześnie nasz czas retencji wynosi tylko 30 minut. To jest złe. A teraz wyjaśnię dlaczego.
Wykonujemy kalkulację, czyli z półtora miliona metryk i już jesteśmy blisko nich, na etapie projektowania otrzymujemy 35-37 gigabajtów pamięci. Ale już 4 miliony metryk wymaga około 90 gigabajtów pamięci. Oznacza to, że został obliczony przy użyciu wzoru dostarczonego przez twórców Prometheusa. Przyjrzeliśmy się korelacji i zdaliśmy sobie sprawę, że nie chcemy płacić kilku milionów za serwer tylko za monitorowanie.
Nie tylko zwiększymy liczbę maszyn, ale także będziemy monitorować same maszyny wirtualne. Zatem im więcej maszyn wirtualnych, tym więcej różnego rodzaju metryk itp. Szczególny wzrost naszego klastra będziemy mieli pod względem metryk.
Z miejscem na dysku nie wszystko jest tutaj takie złe, ale chciałbym to poprawić. W sumie w 15 dni otrzymaliśmy 120 gigabajtów, z czego 100 to dane skompresowane, 20 to dane nieskompresowane, ale zawsze chcemy mniej.
W związku z tym zapisujemy jeszcze jeden punkt - jest to duże zużycie zasobów, które nadal chcemy oszczędzać, ponieważ nie chcemy, aby nasz klaster monitorujący zużywał więcej zasobów niż nasz klaster, który zarządza OpenStack.
Jest jeszcze jedna wada Prometeusza, którą sami zidentyfikowaliśmy, jest to przynajmniej pewnego rodzaju ograniczenie pamięci. Z Prometeuszem tutaj wszystko jest dużo gorsze, bo w ogóle nie ma takich zwrotów akcji. Użycie limitu w oknie dokowanym również nie wchodzi w grę. Jeśli nagle Twój RAF spadnie i będzie 20-30 gigabajtów, wzrost zajmie bardzo dużo czasu.
To kolejny powód, dla którego Prometheus nie jest dla nas odpowiedni, tj. nie możemy ograniczać zużycia pamięci.
Można byłoby wymyślić taki schemat. Potrzebujemy tego schematu, aby zorganizować klaster HA. Chcemy, aby nasze metryki były dostępne zawsze i wszędzie, nawet jeśli serwer przechowujący te metryki ulegnie awarii. I dlatego będziemy musieli zbudować taki schemat.
Schemat ten mówi, że będziemy mieli duplikację odłamków, a co za tym idzie, duplikację kosztów zużytych zasobów. Można go skalować niemal poziomo, ale mimo to zużycie zasobów będzie piekielne.
Wady w takiej formie w jakiej sami je spisaliśmy:
- Wymaga przesyłania danych na zewnątrz.
- Wysokie zużycie zasobów.
- Nie ma możliwości ograniczenia zużycia pamięci.
- Złożone i wymagające dużych zasobów wdrożenie HA.
Sami zdecydowaliśmy, że odchodzimy od Prometeusza jako magazynu.
Zidentyfikowaliśmy dla siebie dodatkowe wymagania, których potrzebujemy. Ten:
- Jest to obsługa promql, ponieważ dla Prometheusa napisano już wiele rzeczy: zapytania, alerty.
- A potem mamy Grafanę, która jest już napisana dokładnie w ten sam sposób dla Prometheusa jako backend. Nie chcę przepisywać dashboardów.
- Chcemy zbudować normalną architekturę HA.
- Chcemy ograniczać zużycie wszelkich zasobów.
- Jest jeszcze jeden mały niuans. Nie możemy korzystać z różnych typów systemów zbierania metryk w chmurze. Nie wiemy jeszcze, co będzie wchodzić w zakres tych wskaźników. A ponieważ wszystko może tam latać, musimy ograniczyć się do rozmieszczenia lokalnego.
Nie było wielkiego wyboru. Zebraliśmy wszystko, z czym mieliśmy doświadczenie. Zajrzeliśmy na stronę Prometheus w sekcji integracji, przeczytaliśmy kilka artykułów i zobaczyliśmy, co tam jest. A dla nas wybraliśmy VictoriaMetrics jako zamiennik Prometheusa.
Dlaczego? Ponieważ:
- Można zrobić promql.
- Istnieje architektura modułowa.
- Nie wymaga zmian w Grafanie.
- A co najważniejsze, prawdopodobnie przechowywanie metryk będziemy udostępniać w ramach naszej firmy w formie usługi, dlatego z wyprzedzeniem patrzymy na różnego rodzaju ograniczenia, aby użytkownicy mogli w jakiś ograniczony sposób korzystać ze wszystkich zasobów klastra, ponieważ jest szansa że będzie wielodostępny.
Dokonajmy pierwszego porównania. Bierzemy tego samego Prometeusza do wnętrza gromady, zewnętrzny Prometeusz trafia do niego. Dodaj przez RemoteWrite VictoriaMetrics.
Od razu zastrzegam, że tutaj zaobserwowaliśmy niewielki wzrost zużycia procesora od VictoriaMetrics. Wiki VictoriaMetrics informuje, które parametry są najlepsze. Sprawdziliśmy je. Bardzo dobrze zmniejszyli zużycie procesora.
W naszym przypadku zużycie pamięci Prometheusa, który znajduje się w klastrze Kubernetes, nie wzrosło znacząco.
Porównujemy dwa źródła danych tych samych danych. W Prometeuszu widzimy te same brakujące dane. W VictoriaMetrics wszystko jest w porządku.
Wyniki testu miejsca na dysku. W Prometheusie otrzymaliśmy łącznie 120 gigabajtów. W VictoriaMetrics otrzymujemy już 4 gigabajty dziennie. Istnieje nieco inny mechanizm niż ten, do którego jesteśmy przyzwyczajeni w Prometeuszu. Oznacza to, że dane są już dość dobrze skompresowane w ciągu jednego dnia, w ciągu pół godziny. Zostały już zebrane w ciągu jednego dnia, w pół godziny, mimo że dane nadal zostaną utracone później. W rezultacie zaoszczędziliśmy miejsce na dysku.
Oszczędzamy także na zużyciu zasobów pamięci. W czasie testów Prometheus był zainstalowany na maszynie wirtualnej – 8 rdzeni, 24 gigabajty. Prometeusz zjada prawie wszystko. Wpadł na OOM Killera. Jednocześnie wlano do niego jedynie 900 000 aktywnych metryk. To około 25 000–27 000 wskaźników na sekundę.
Uruchomiliśmy VictoriaMetrics na dwurdzeniowej maszynie wirtualnej z 8 gigabajtami pamięci RAM. Udało nam się sprawić, że VictoriaMetrics dobrze działało, poprawiając kilka rzeczy na komputerze o pojemności 8 GB. Ostatecznie ograniczyliśmy go do 7 gigabajtów. Jednocześnie szybkość dostarczania treści, czyli metryk, była jeszcze większa niż w przypadku Prometheusa.
Procesor stał się znacznie lepszy w porównaniu do Prometheusa. Tutaj Prometheus zużywa 2,5 rdzenia, a VictoriaMetrics zużywa tylko 0,25 rdzenia. Na początek - 0,5 rdzenia. Kiedy się łączy, dociera do jednego rdzenia, ale zdarza się to niezwykle, niezwykle rzadko.
W naszym przypadku wybór padł na VictoriaMetrics z oczywistych powodów – chcieliśmy zaoszczędzić pieniądze i to nam się udało.
Skreślmy od razu dwa punkty – przesyłanie metryk i wysokie zużycie zasobów. Musimy tylko zdecydować o dwóch punktach, które wciąż pozostawiliśmy sobie.
Tutaj od razu dokonam rezerwacji, uważamy VictoriaMetrics za magazyn metryk. Ponieważ jednak najprawdopodobniej udostępnimy VictoriaMetrics jako pamięć masową dla całego Leroy, musimy ograniczyć liczbę osób, które będą korzystać z tego klastra, aby nie udostępniały go nam.
Istnieje wspaniały parametr, który pozwala ograniczyć czas, objętość danych i czas wykonania.
Istnieje również doskonała opcja, która pozwala nam ograniczyć zużycie pamięci, dzięki czemu możemy znaleźć równowagę, która pozwoli nam uzyskać normalną prędkość działania i odpowiednie zużycie zasobów.
Minus jeszcze jeden punkt, czyli przekreślić punkt - nie można ograniczać zużycia pamięci.
W pierwszych iteracjach testowaliśmy pojedynczy węzeł VictoriaMetrics. Następnie przechodzimy do wersji klastra VictoriaMetrics.
Tutaj mamy wolną rękę, aby oddzielić różne usługi w VictoriaMetrics w zależności od tego, na czym będą działać i jakie zasoby będą zużywać. To bardzo elastyczne i wygodne rozwiązanie. Użyliśmy tego na sobie.
Głównymi składnikami wersji klastra VictoriaMetrics są vmstsorage. Może być ich N. W naszym przypadku są na razie 2 z nich.
Jest też vminsert. To jest serwer proxy, który pozwala nam: zorganizować sharding pomiędzy wszystkimi magazynami, o których wspominaliśmy, a także umożliwia replikę, tj. będziesz mieć zarówno sharding, jak i replikę.
Vminsert obsługuje protokoły OpenTSDB, Graphite, InfluxDB i RemoteWrite firmy Prometheus.
Istnieje również vmselect. Jego głównym zadaniem jest udanie się do vmstorage, odebranie od nich danych, deduplikacja tych danych i przekazanie ich klientowi.
Istnieje cudowna rzecz zwana vmagent. Naprawdę ją lubimy. Pozwala skonfigurować dokładnie tak jak Prometheus i nadal robić wszystko dokładnie tak jak Prometheus. Oznacza to, że zbiera metryki od różnych podmiotów i usług i wysyła je do vminsert. Wtedy wszystko zależy od Ciebie.
Kolejną świetną usługą jest vmalert, który pozwala używać VictoriaMetrics jako backendu, odbierać przetworzone dane z vminsert i wysyłać je do vmselect. Przetwarza same alerty, a także reguły. W przypadku alertów alert otrzymujemy poprzez menedżera alertów.
Istnieje komponent wmauth. Możemy, ale nie musimy (jeszcze o tym nie zdecydowaliśmy) wykorzystać go jako system autoryzacji dla wielodostępnej wersji klastrów. Obsługuje RemoteWrite dla Prometheusa i może autoryzować na podstawie adresu URL, a raczej jego drugiej części, gdzie możesz pisać lub nie.
Istnieje również vmbackup, vmrestore. Zasadniczo jest to przywracanie i tworzenie kopii zapasowych wszystkich danych. Potrafi wykonać S3, GCS, plik.
Pierwsza iteracja naszego klastra została wykonana podczas kwarantanny. W tamtym czasie nie było jeszcze repliki, więc nasza iteracja składała się z dwóch różnych i niezależnych klastrów, do których otrzymywaliśmy dane za pomocą metody RemoteWrite.
Tutaj zastrzegam, że kiedy przeszliśmy z VictoriaMetrics Single Node na VictoriaMetrics Cluster Version, nadal pozostaliśmy przy tych samych zużytych zasobach, czyli głównym z nich jest pamięć. Tak mniej więcej rozłożyły się nasze dane, czyli zużycie zasobów.
Replika została już tutaj dodana. Połączyliśmy to wszystko w jeden stosunkowo duży klaster. Wszystkie nasze dane są zarówno fragmentowane, jak i replikowane.
Cały klaster ma N punktów wejścia, co oznacza, że Prometheus może dodawać dane za pośrednictwem HAPROXY. Tutaj mamy ten punkt wejścia. Za pośrednictwem tego punktu wejścia możesz zalogować się z Grafany.
W naszym przypadku HAPROXY jest jedynym portem, który pośredniczy w wybieraniu, wstawianiu i innych usługach w tym klastrze. W naszym przypadku nie było możliwości zrobienia jednego adresu, musieliśmy zrobić kilka punktów wejścia, ponieważ same maszyny wirtualne, na których działa klaster VictoriaMetrics, znajdują się w różnych strefach tego samego dostawcy chmury, czyli nie wewnątrz naszej chmury, ale na zewnątrz .
Mamy alarmowanie. Używamy tego. Używamy alertmanager od Prometheus. Używamy Opsgenie i Telegramu jako kanału dostarczania alertów. W Telegramie napływają od dewelopera, może coś od prod, ale głównie coś statystycznego, potrzebnego inżynierom. A Opsgenie jest krytyczne. To są rozmowy telefoniczne i zarządzanie incydentami.
Odwieczne pytanie: „Kto monitoruje monitoring?” W naszym przypadku monitorowanie monitoruje samo monitorowanie, ponieważ na każdym węźle używamy vmagent. A ponieważ nasze węzły są rozproszone w różnych centrach danych tego samego dostawcy, każde centrum danych ma swój własny kanał, są one niezależne i nawet jeśli pojawi się podzielony mózg, nadal będziemy otrzymywać alerty. Tak, będzie ich więcej, ale lepiej otrzymać więcej alertów niż żadnego.
Kończymy naszą listę implementacją HA.
Ponadto chciałbym zwrócić uwagę na doświadczenie w komunikacji ze społecznością VictoriaMetrics. Wyszło bardzo pozytywnie. Chłopaki reagują. Starają się zagłębić w każdy zaproponowany przypadek.
Zacząłem problemy na GitHubie. Zostały one rozwiązane bardzo szybko. Jest jeszcze kilka kwestii, które nie są całkowicie zamknięte, ale już widzę po kodzie, że prace w tym kierunku trwają.
Głównym problemem podczas iteracji było to, że jeśli zamknę węzeł, to przez pierwsze 30 sekund vminsert nie mógł zrozumieć, że nie ma backendu. To zostało teraz postanowione. I dosłownie za sekundę lub dwie dane są pobierane ze wszystkich pozostałych węzłów, a żądanie przestaje czekać na ten brakujący węzeł.
W pewnym momencie chcieliśmy, aby VictoriaMetrics była operatorem VictoriaMetrics. Czekaliśmy na niego. Obecnie aktywnie budujemy framework dla operatora VictoriaMetrics, który będzie uwzględniał wszystkie reguły przedobliczeniowe itp. Prometheus, ponieważ dość aktywnie korzystamy z reguł dostarczonych z operatorem Prometheus.
Istnieją propozycje usprawnienia wdrażania klastrów. Opisałem je powyżej.
I naprawdę chcę zmniejszyć próbkowanie. W naszym przypadku downsampling jest potrzebny wyłącznie do oglądania trendów. Mniej więcej w ciągu dnia wystarczy mi jeden miernik. Te trendy są potrzebne na rok, trzy, pięć, dziesięć lat. I jedna wartość metryki wystarczy.
- Podobnie jak niektórzy z naszych kolegów, zaznaliśmy bólu podczas stosowania leku Prometheus.
- Wybraliśmy dla siebie VictoriaMetrics.
- Skaluje się dość dobrze zarówno w pionie, jak i w poziomie.
- Możemy dystrybuować różne komponenty do różnej liczby węzłów w klastrze, ograniczać je pamięcią, dodawać pamięć itp.
Będziemy korzystać z VictoriaMetrics w domu, bo bardzo nam się spodobało. To jest to, co było i co się stało.
Kilka kodów QR do czatu VictoriaMetrics, moich kontaktów, radaru technicznego LeroyMerlin.
Źródło: www.habr.com