Cześć wszystkim. Poniżej przedstawiam transkrypcję .
– system monitorowania różnych systemów i usług, dzięki któremu administratorzy systemów mogą zbierać informacje o aktualnych parametrach systemów i ustawiać powiadomienia, aby otrzymywać informacje o odchyleniach w pracy systemów.
Referat zawiera porównanie i — projektów do długoterminowego przechowywania metryk Prometheus.
Najpierw opowiem o Prometheusie. To system monitorowania, który zbiera metryki z określonych targetów i zapisuje je w lokalnym magazynie. Prometheus potrafi zapisywać metryki w zdalnym magazynie, generować alerty i reguły nagrywania.
Ograniczenia Prometheusa:
- Nie ma globalnego widoku zapytań. To wtedy, gdy masz kilka niezależnych instancji Prometheusa. Zbierają one metryki, a ty chcesz zrobić zapytanie nad wszystkimi tymi metrykami, zebranymi z różnych instancji Prometheusa. Prometheus tego nie pozwala.
- Wydajność Prometheusa jest ograniczona tylko do jednego serwera. Prometheus automatycznie nie może skalować się na kilka serwerów. Możesz tylko ręcznie podzielić swoje targety między kilka instancji Prometheusa.
- Objętość metryk w Prometheusie jest ograniczona tylko do jednego serwera z tego samego powodu, dla którego nie może automatycznie skalować się na kilka serwerów.
- W Prometheusie nie jest łatwo zorganizować przechowywanie danych.
Rozwiązania tych problemów/zadań?
Rozwiązania są następujące:
Wszystkie te rozwiązania dotyczą zdalnego przechowywania danych, zbieranych przez Prometheusa. Rozwiązują problem zdalnego magazynu z poprzedniego slajdu na różne sposoby. W tej prezentacji opowiem tylko o dwóch pierwszych rozwiązaniach: i .
Po raz pierwszy informacje o pojawiły się w . Tam opisana jest architektura i jak to działa.
Thanos bierze dane, które zostały zapisane przez Prometheusa na lokalnym dysku, i kopiuje je do S3, do lub do innego obiektu magazynowego.
W ten sposób Thanos zapewnia globalny widok zapytań. Możesz zapytywać dane zapisane w obiekcie magazynowym z kilku instancji Prometheusa.
Thanos obsługuje PromQL i .
Thanos wykorzystuje kod Prometheusa do przechowywania danych.
Thanos jest rozwijany przez tych samych programistów, którzy pracują nad Prometheusem.
O . Oto , gdzie po raz pierwszy opowiedziano o .
VictoriaMetrics pobiera dane z kilku Prometheusa przez protokół wspierany przez Prometheusa.
VictoriaMetrics zapewnia globalny widok zapytań, ponieważ wiele instancji Prometheus może zapisywać dane w jednej instancji VictoriaMetrics. Możesz zatem wykonywać zapytania na podstawie wszystkich tych danych.
VictoriaMetrics obsługuje również, podobnie jak Thanos — PromQL oraz API zapytań Prometheusa.
W przeciwieństwie do Thanos, kod źródłowy VictoriaMetrics został napisany od podstaw i zoptymalizowany pod kątem szybkości oraz zużycia zasobów.
VictoriaMetrics, w przeciwieństwie do Thanos, skalowalnie rozwija się zarówno pionowo, jak i poziomo. Istnieje , która skalowalnie rozwija się pionowo. Możesz zacząć z jednym procesorem i 1 GB pamięci, a następnie stopniowo rozwijać do setek procesorów i 1 TB pamięci. VictoriaMetrics potrafi wykorzystać wszystkie te zasoby. Jej wydajność wzrośnie około 100 razy w porównaniu do systemu z jednym rdzeniem.
Historia Thanos zaczęła się w listopadzie 2017 roku, kiedy to pojawił się pierwszy publiczny commit. Wcześniej Thanos był rozwijany wewnętrznie w firmie .
W czerwcu 2019 roku miała miejsce znacząca wersja 0.5.0, w której Został usunięty z Thanos, ponieważ nie sprawdził się najlepiej. Często klaster Thanos działał niewłaściwie, węzły łączyły się błędnie z powodu protokołu gossip. Dlatego postanowiono go usunąć. Uważam, że to właściwa decyzja.
W tym samym czerwcu 2019 roku złożyliśmy wniosek numer do .
I po kilku miesiącach przyjęto Thanos do , w którym znajdują się Prometheus, Kubernetes i inne popularne projekty.
W styczniu 2018 roku rozpoczęto rozwój VictoriaMetrics.
W wrześniu 2018 po raz pierwszy publicznie wspomniałem o VictoriaMetrics.
W grudniu 2018 roku opublikowano wersję jednostanowiskową.
W maju 2019 źródła zarówno wersji jednostanowiskowej, jak i klastrowej.
W czerwcu 2019, tak jak Thanos, złożyliśmy wniosek do fundacji CNCF pod numerem . Złożyliśmy wniosek dzień wcześniej niż Thanos.
Ale, niestety, do tej pory nie zostaliśmy tam przyjęci. Wymagana jest pomoc społeczności.
Przyjrzyjmy się najważniejszym slajdom, które przedstawiają architekturę Thanos i VictoriaMetrics.
Zacznijmy od Thanos. Żółte komponenty to komponenty Prometheus. Wszystko inne to komponenty Thanos. Zacznijmy od najważniejszego komponentu. Thanos Sidecar to komponent, który jest instalowany obok każdego Prometheusa. Zajmuje się on ładowaniem danych Prometheusa z lokalnej pamięci masowej do S3 lub innej pamięci obiektowej.
Jest jeszcze taki komponent jak Thanos Store Gateway, który potrafi odczytywać te dane z Object Storage przy przychodzących zapytaniach od Thanos Query. Thanos Query implementuje PromQL i API Prometheusa. Na zewnątrz wygląda jak Prometheus. Przyjmuje zapytania PromQL, wysyła je do Thanos Store Gateway, a Thanos Store Gateway pobiera potrzebne dane z Object Storage i wysyła je z powrotem.
Jednak w naszym Object Storage przechowywane są dane bez ostatnich dwóch godzin z powodu specyfiki działania Thanos Sidecar, który nie może załadować ostatnich dwóch godzin do Object Storage S3, ponieważ dla tych dwóch godzin Prometheus jeszcze nie stworzył plików w lokalnym magazynie.
Jak więc rozwiązano ten problem? Thanos Query, oprócz zapytań do Thanos Store Gateway, równolegle wysyła zapytania również do każdego Thanos Sidecar, które znajdują się blisko Prometheusa.
A Thanos Sidecar z kolei przekazuje zapytania dalej do Prometheusa i pobiera dane z ostatnich dwóch godzin.
Oprócz tych komponentów dostępny jest także opcjonalny komponent, bez którego Thanos będzie działał nieefektywnie. To Thanos Compact, który zajmuje się łączeniem małych plików w Object Storage w większe pliki, które zostały tam załadowane przez Thanos Sidecara. Thanos Sidecar ładował tam pliki z danymi za dwa godziny. Te pliki, jeśli nie są łączone w większe pliki, mogą znacznie zwiększyć swoją liczbę. Im więcej takich plików, tym więcej pamięci potrzebuje Thanos Store Gateway, tym więcej zasobów jest potrzebnych do przesyłania danych przez sieć, metadanych. Praca Thanos Store Gateway staje się nieefektywna. Dlatego należy koniecznie uruchomić Thanos Compact, który łączy małe pliki w większe, aby zmniejszyć ich liczbę i zredukować obciążenie na Thanos Store Gateway.
Jest jeszcze taki komponent jak Thanos Ruler. Realizuje on zasady alertów Prometheusa i może obliczać zasady rejestrowania Prometheusa, aby ponownie zapisywać dane w Object Storage. Jednak ten komponent nie jest zalecany do użycia, ponieważ jest .
Taka jest prosta schemat Thanos.
Teraz porównajmy to z schematem VictoriaMetrics.
VictoriaMetrics ma 2 wersje: Single-node i wersję klastrową. Single-node działa na jednym komputerze. W Single-node nie ma tych komponentów, po prostu jeden plik binarny. Ten plik binarny na slajdzie wygląda jak ten kwadrat. Wszystko, co znajduje się wewnątrz kwadratu, to zawartość pliku binarnego dla wersji Single-node. Nie musisz o nim wiedzieć. Po prostu uruchamiasz plik binarny - i wszystko działa.
Wersja klastra jest bardziej skomplikowana. Zawiera trzy różne komponenty: vmselect, vminsert i vmstorage. Z ich nazw powinno być jasne, czym się zajmuje każdy z nich. Komponent Insert przyjmuje dane w różnych formatach: z API Prometheus remote write, protokołu Influx line, protokołu Graphite oraz z protokołu OpenTSDB. Komponent Insert przyjmuje je, przetwarza i rozdziela pomiędzy dostępne komponenty storage, gdzie dane są już przechowywane. Komponent Select z kolei przyjmuje zapytania w PromQL. Realizuje , a także API zapytań Prometheus, i może być używany jako zamiennik Prometheus w Grafana lub innych klientach API Prometheus. Select przyjmuje zapytanie promql, przetwarza je, odczytuje potrzebne dane do realizacji tego zapytania z węzłów storage, przetwarza te dane i zwraca odpowiedź.
Porównajmy trudność instalacji Thanos i VictoriaMetrics.
Zacznijmy od Thanos. Zanim zaczniemy pracę z Thanos, należy utworzyć bucket w Object Storage, takim jak S3 lub GCS, aby Thanos Sidecar mógł zapisywać tam dane.
Następnie dla każdego Prometheusa należy zainstalować Thanos Sidecar. Przed tym nie zapomnij wyłączyć kompresji danych w Prometheus. Kompresja danych okresowo kompaktuje dane w lokalnym magazynie Prometheus, aby zmniejszyć zużycie zasobów.
Gdy instalujesz Thanos Sidecar do swoich Prometheów, musisz wyłączyć tę kompresję danych, ponieważ Thanos Sidecar nie działa poprawnie przy włączonej kompresji danych. Oznacza to, że Twój Prometheus zaczyna przechowywać dane w blokach po dwie godziny i przestaje scalać te bloki w większe. W związku z tym, jeśli wykonujesz zapytania, które wykraczają poza ostatnie dwie godziny, będą one działać mniej efektywnie w porównaniu do tego, jak mogłyby działać, gdyby kompresja danych była włączona.
Dlatego Thanos zaleca zmniejszenie czasu przechowywania danych w lokalnym storage do 6-8 godzin, aby zredukować overhead dużej liczby małych bloków.
Po zainstalowaniu Thanos Sidecar, musisz dla każdego bucketu Object Storage zainstalować dwa komponenty. To Thanos Compactor i Thanos Store Gateway.
Następnie należy zainstalować Thanos Query i skonfigurować go, aby mógł łączyć się ze wszystkimi Thanos Store Gateway, które posiadasz, a także umieć łączyć się ze wszystkimi Thanos Sidecar.
Może tu być mały problem.
Musisz skonfigurować niezawodne i bezpieczne połączenie z Thanos Query do tych komponentów. A jeśli twoje Prometheusy znajdują się w różnych centrach danych lub w różnych VPC, to połączenia zewnętrzne są zablokowane. Aby Thanos Query mogło działać, musisz jednak w jakiś sposób skonfigurować do nich połączenie i wymyślić rozwiązanie.
Jeśli masz wiele takich centrów danych, to odpowiednio zmniejsza to niezawodność całego systemu. Thanos Query musi stale utrzymywać połączenia ze wszystkimi Thanos Sidecar znajdującymi się w różnych centrach danych. Przy każdym przychodzącym żądaniu przekierowuje zapytania do wszystkich Thanos Sidecar. Jeśli połączenie zostanie przerwane, otrzymasz albo niepełny zestaw danych, albo odpowiedź „klaster nie działa”.
W VictoriaMetrics wszystko jest trochę prostsze. W wersji jednolotnej wystarczy uruchomić jeden binarny plik i wszystko działa.
W wersji klastrowej wystarczy uruchomić wszystkie powyżej wspomniane trzy typy komponentów w dowolnej, potrzebnej ci liczbie lub użyć do automatyzacji uruchamiania komponentów w Kubernetes. Planujemy również stworzyć operator Kubernetes. Helm chart nie pokrywa niektórych przypadków i może sprawić, że strzelisz sobie w stopę. Na przykład pozwala na zmniejszenie liczby węzłów storage, co spowoduje utratę danych.
Po uruchomieniu jednego binarnika lub wersji klastrowej wystarczy dodać w konfiguracji Prometheus , aby zaczął równolegle zapisywać dane zarówno w lokalnym storage, jak i w remote storage. Jak zauważyłeś, taka konfiguracja powinna działać znacznie niezawodniej w porównaniu z konfiguracją Thanos. Nie musimy utrzymywać połączenia z VictoriaMetrics do wszystkich Prometheusów, ponieważ to Prometheusy same podłączają się do VictoriaMetrics i przesyłają dane.
Rozważmy wsparcie dla Thanos i VictoriaMetrics.
Thanos musi monitorować Sidecar, aby nie przerywał przesyłania danych do Object Storage. Mogą nastąpić przerwy w przesyle danych z powodu błędów, na przykład jeśli chwilowo zerwie się połączenie sieciowe z Object Storage lub będzie on chwilowo niedostępny. W tym momencie Thanos Sidecar zauważy problem, zgłosi błąd, może ulec awarii i przestać działać. Jeśli nie będziesz go monitorować, przestaną docierać dane do Object Storage. Jeśli minie czas retencji (zalecane 6-8 godzin), zaczniesz tracić dane, które nie znalazły się w Object Storage.
Thanos compactor może przestać działać z powodu . Compactor pobiera dane z Object Storage i łączy je w większe fragmenty. Ponieważ compactor nie jest zsynchronizowany z Sidecar, może wystąpić sytuacja, w której: Sidecar jeszcze nie zapisał bloku, a Compactor zakłada, że blok jest w pełni zapisany. Compactor zaczyna go odczytywać. Odczytuje blok nie w pełnej postaci i przestaje działać. Zobacz szczegóły. .
Store Gateway może zwracać niespójne dane z powodu wyścigów między Compactor a Sidecar. Tutaj sytuacja jest podobna, ponieważ Store Gateway nie jest w żaden sposób zsynchronizowany z Compactorami i Sidecar. W związku z tym mogą wystąpić stany wyścigu, kiedy Store Gateway nie widzi części danych lub widzi dodatkowe dane.
Komponent zapytań w Thanos domyślnie zwraca częściowy wynik, jeżeli niektóre Sidecar lub Store Gateway są w danym momencie niedostępne. Otrzymasz część danych i nawet nie będziesz świadomy, że otrzymałeś nie wszystkie dane. Tak działa domyślnie. W podobnej sytuacji VictoriaMetrics zwraca oznaczone dane jako częściowe.
W przeciwieństwie do Thanos, VictoriaMetrics rzadko traci dane. Nawet jeśli połączenie z Prometheusem do VictoriaMetrics zostanie przerwane, to nie jest problem, ponieważ Prometheus kontynuuje zapisywanie przychodzących nowych danych w Write Ahead Log, którego rozmiar wynosi 2 godziny. Jeśli odzyskasz połączenie z VictoriaMetrics w ciągu dwóch godzin, dane nie zostaną utracone. Prometheus .
W przeciwieństwie do Thanos, który zapisuje dane do object storage dopiero po dwóch godzinach, Prometheus automatycznie replikuje dane za pomocą protokołu remote write do remote storage, takiego jak VictoriaMetrics. Nie musisz obawiać się utraty local storage w Prometheus. Jeśli nagle utraci on local storage, w najgorszym przypadku stracisz ostatnie sekundy danych, które nie zdążyły się zapisać w remote storage.
Kubernetes automatycznie zarządza klastrem, w przeciwieństwie do Thanos. Wszystkie komponenty Thanos trudno pomieścić w jednym klastrze Kubernetes, w przeciwieństwie do komponentów klastrowych VictoriaMetrics.
VictoriaMetrics ma bardzo prostą procedurę aktualizacji do nowej wersji. Wystarczy zatrzymać VictoriaMetrics, zaktualizować pliki binarne i uruchomić ją ponownie. Przy zatrzymywaniu za pomocą sygnału SIGINT wszystkie pliki binarne VictoriaMetrics wykonują graceful shutdown. Prawidłowo zapisują potrzebne dane i zamykają przychodzące połączenia, aby nic nie zostało utracone. Dlatego nic nie stracisz podczas aktualizacji.
W VictoriaMetrics łatwo rozszerzyć klaster. Wystarczy dodać potrzebne komponenty i kontynuować pracę.
O pułapkach w Thanos i VictoriaMetrics.
Thanos ma następujące pułapki. Prometheus musi przechowywać dane za ostatnie dwie godziny. Jeśli zostaną utracone, stracisz je całkowicie, ponieważ nie zdążyły się jeszcze zapisać w Object Storage, takim jak S3.
Komponent Store Gateway i komponent compactor mogą wymagać dużo pamięci do pracy z dużym Object Storage, jeśli przechowywanych jest wiele małych plików. Im większa liczba i rozmiar plików, tym więcej pamięci operacyjnej wymaga Store Gateway i compactor do przechowywania metainformacji. Thanos ma wiele problemów związanych z tym, że .
Thanos reklamuje się, że może skalować się w nieskończoność w odniesieniu do liczby twoich Prometheus. W rzeczywistości to nieprawda. Ponieważ wszystkie zapytania przechodzą przez komponent Query, który musi równolegle przeskanować wszystkie komponenty Store Gateway i wszystkie komponenty Sidecar, wydobyć stamtąd dane, a następnie je wstępnie przetworzyć. Oczywiście prędkość zapytań jest ograniczona przez najsłabsze ogniwo, najsłabszy Store Gateway albo najsłabszy Sidecar.
Te komponenty mogą być obciążone nierównomiernie. Na przykład, masz Prometheusa, który zbiera miliony metryk na sekundę. I jest Prometheus, który zbiera tysiące metryk na sekundę. Prometheus, który zbiera miliony metryk na sekundę, znacznie mocniej obciąża serwer, na którym działa. Odpowiednio, Sidecar będzie tam działał wolniej. W ogóle wszystko tam działa wolno. Komponent Query bardzo wolno będzie pobierał dane. W związku z tym wydajność całego twojego klastra będzie ograniczona przez ten wolny Sidecar.
Domyślnie Thanos zwraca częściowe dane, jeśli niektóre Sidecary lub Store Gateway są niedostępne. Na przykład, jeśli masz Sidecary rozrzucone po całym świecie w różnych centrach danych, to prawdopodobieństwo przerwania połączenia i niedostępności komponentów znacznie wzrasta. Odpowiednio, w większości przypadków będziesz otrzymywać częściowe dane, nawet nie zdając sobie z tego sprawy.
VictoriaMetrics ma też swoje pułapki. Pierwsza pułapka to opcja, która ogranicza ilość pamięci RAM używanej przez pamięć podręczną VictoriaMetrics. Domyślnie wynosi ona 60% pamięci RAM maszyny, na której działa VictoriaMetrics, lub 60% RAMu poda VictoriaMetrics w Kubernetes.
Jeśli niewłaściwie zmienisz tę wartość, możesz obniżyć wydajność VictoriaMetrics. Na przykład, jeśli ustawisz zbyt niską wartość, dane mogą przestać mieścić się w pamięci podręcznej VictoriaMetrics. W związku z tym będzie musiała wykonać dodatkową pracę i obciążyć procesor oraz dysk. Jeśli ta opcja będzie zbyt duża, po pierwsze, zwiększa to prawdopodobieństwo, że VictoriaMetrics będzie wybuchać z błędem out of memory, a po drugie, spowoduje to, że w systemie operacyjnym pozostanie zbyt mało pamięci RAM dla pamięci podręcznej plików. VictoriaMetrics polega na pamięci podręcznej plików dla wydajności. Jeśli jest jej za mało, może to znacznie zwiększyć obciążenie dysku. Dlatego rada: nie zmieniaj tego parametru bez konieczności.
Druga opcja. To retentionPeriod — okres, który domyślnie ustawiony jest na 1 miesiąc. To czas, przez jaki VictoriaMetrics przechowuje dane. Po upływie tego terminu VictoriaMetrics usuwa dane.
Wielu uruchamia VictoriaMetrics bez tego parametru, zapisując dane przez miesiąc. A potem pytają: dlaczego dane zniknęły w poprzednim miesiącu? Ponieważ retentionPeriod domyślnie wynosi 1 miesiąc. Dlatego trzeba znać i ustawiać odpowiedni retentionPeriod.
Przejdźmy do unikalnych możliwości.
Thanos ma taką funkcję jak downsampling: 5-minutowe i godzinowe interwały, które często Jeśli poszukać w Google i zobaczyć ich problemy na GitHubie, jest tam bardzo wiele zgłoszeń związanych z tym downsamplingiem, który czasami działa niepoprawnie lub działa inaczej, niż oczekują użytkownicy.
Thanos ma deduplikację danych dla par HA Prometheus. Kiedy dwa Prometheus'y zbierają te same metryki z tych samych targetów, Thanos je łączy w Object Storage. Thanos potrafi poprawnie deduplikować te dane, w przeciwieństwie do VictoriaMetrics.
Thanos ma komponent alertowy, który był na schemacie Thanos. Ale jego .
Thanos ma przewagę, że kod Thanos i Prometheus jest wspólny. Thanos i Prometheus są opracowywane przez tych samych deweloperów. Przy poprawkach w Thanos lub Prometheus korzysta druga strona.
Główną cechą VictoriaMetrics jest MetricsQL. To rozszerzenie VictoriaMetrics dla PromQL, o którym mówiłem na poprzednim wielkim spotkaniu monitoringu.
VictoriaMetrics obsługuje wprowadzanie danych za pomocą wielu różnych protokołów. VictoriaMetrics może nie tylko przyjmować dane z Prometheus, ale również przez protokoły Influx, OpenTSDB i Graphite.
Dane VictoriaMetrics zajmują zazwyczaj znacznie mniej miejsca w porównaniu do Thanos i Prometheus.
Jeśli zapisujesz rzeczywiste dane, użytkownicy mówią o 2-5-krotnym zmniejszeniu rozmiaru danych na dysku w porównaniu z Prometheus i Thanos.
Kolejną zaletą VictoriaMetrics jest to, że jest zoptymalizowana pod kątem szybkości.
Przejdźmy do kosztów infrastruktury.
Jedną z zalet Thanos jest to, że przechowuje dane w object storage, który jest stosunkowo tani.
Przy przechowywaniu danych w object storage musisz opłacać operacje zapisu i odczytu danych (10 dolarów za milion operacji). Kiedy zapisujesz dane w object storage, ponosisz koszty związane z Twoim hostingiem przy przesyłaniu danych do internetu, jeśli Twój klaster nie znajduje się w AWS — tam jest to bezpłatne. Kiedy odczytujesz dane, płacisz od 10 do 230 dolarów za 1TB. To może być znaczące, jeśli często żądasz historycznych danych z klastra Thanos.
Dla klastra Thanos trzeba opłacać serwery dla komponentów Compact, Store Gateway, Query, które wymagają dużej ilości pamięci i CPU do przetwarzania dużych zbiorów danych.
Koszty dla VictoriaMetrics są następujące. Jeśli dane są przechowywane na dyskach GCE HDD, wynosi to 40 dolarów za 1TB. Dla VictoriaMetrics wystarczą zwykłe dyski HDD, żadne SSD, które są pięć razy droższe, nie są potrzebne. VictoriaMetrics jest zoptymalizowana pod kątem HDD.
Dla VictoriaMetrics potrzebne są serwery dla komponentów: albo dla pojedynczego węzła, albo dla komponentów klastrowych, które w przeciwieństwie do komponentów Thanos wymagają znacznie mniej CPU i RAM — co oznacza niższe koszty.
Przykłady wdrożeń.
Przykład wdrożenia Thanos to Gitlab. Gitlab całkowicie działa na Thanos. Ale nie wszystko jest tak proste. Jeśli spojrzeć na ich , można zobaczyć, że ciągle napotykają na jakieś brakując pamięci dla komponentów Store Gateway lub Query. Muszą regularnie zwiększać ilość pamięci.
Z powodu tego rosną koszty rozwiązania tych problemów.
Drugie wdrożenie, które może być bardziej udane, to firma Improbable, która rozpoczęła rozwój Thanos. Opublikowali źródła Thanos. Improbable to firma zajmująca się opracowaniem silników gier.
Publiczne przykłady wdrożenia VictoriaMetrics to:
- wix.com — konstruktor stron internetowych,
- Adidas wdraża VictoriaMetrics i nawet wygłosił referat na ostatnim PromCon 2019,
- TrafficStars — sieć reklamowa,
- Seznam.cz — popularna czeska wyszukiwarka.
A potem przyszły firmy bez marki, których teraz nie mogę wymienić. Nie udzieliły zgody.
- Jeden dużym deweloper gier. Większy niż Improbable.
- Duży deweloper oprogramowania graficznego.
- Duży rosyjski bank.
- Europejski producent turbin wiatrowych, który z powodzeniem przetestował VictoriaMetrics. Ten producent wdraża VictoriaMetrics do monitorowania danych pozyskiwanych z turbin wiatrowych z szybkością 50 próbek na sekundę na każdy czujnik. W każdej turbinie wiatrowej jest kilka setek czujników. Mają kilka setek turbin wiatrowych.
- Rosyjskie linie lotnicze, które pragną wdrożyć VictoriaMetrics, ale jakoś im się to nie udaje. Jesteśmy na etapie negocjacji.
Wnioski.
VictoriaMetrics i Thanos rozwiązują podobne problemy, ale różnymi sposobami:
- Globalny widok zapytań,
- poziome skalowanie,
- dowolna retencja.
Dziękujemy.
Czekamy na Państwa na naszym .
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Czego używasz jako długoterminowego magazynu dla Prometheusa?
35,3%Thanos
0,0%Cortex
0,0%M3DB
41,2%VictoriaMetrics
23,5%inne
17 użytkowników oddało głos. 16 użytkowników wstrzymało się.
Źródło: habr.com
