Tłumaczenie artykułu zostało przygotowane specjalnie dla studentów kursu .
jest programistą, fanatykiem i osobą rozwiązującą problemy. Jest także opiekunem Prometheusa i współzałożycielem oprzyrządowania Kubernetes SIG. W przeszłości był inżynierem produkcji w SoundCloud i kierował zespołem monitorującym w CoreOS. Obecnie pracuje w Google.
- Inżynier infrastruktury w Improbable. Interesują go nowe technologie i problemy systemów rozproszonych. Ma doświadczenie w programowaniu niskiego poziomu w firmie Intel, doświadczenie jako współpracownik w Mesos i światowej klasy doświadczenie w produkcji SRE w Improbable. Zaangażowany w ulepszanie świata mikrousług. Jego trzy miłości: Golang, open source i siatkówka.
Patrząc na nasz flagowy produkt SpatialOS, można się domyślić, że Improbable wymaga wysoce dynamicznej infrastruktury chmurowej o skali globalnej z kilkudziesięciu klastrów Kubernetes. Jako jedni z pierwszych zastosowaliśmy system monitoringu . Prometheus może śledzić miliony wskaźników w czasie rzeczywistym i jest wyposażony w potężny język zapytań, który pozwala wyodrębnić potrzebne informacje.
Prostota i niezawodność Prometheusa to jedna z jego głównych zalet. Jednak po przekroczeniu pewnej skali napotkaliśmy kilka wad. Aby rozwiązać te problemy, opracowaliśmy to projekt open source stworzony przez Improbable w celu płynnego przekształcenia istniejących klastrów Prometheus w jeden system monitorowania z nieograniczonym przechowywaniem danych historycznych. Thanos jest dostępny na Githubie .
Nasze cele z Thanosem
W pewnej skali pojawiają się problemy przekraczające możliwości zwykłego Prometeusza. Jak niezawodnie i ekonomicznie przechowywać petabajty danych historycznych? Czy można to zrobić bez skracania czasu reakcji? Czy można uzyskać dostęp do wszystkich metryk znajdujących się na różnych serwerach Prometheus za pomocą jednego żądania API? Czy istnieje sposób na połączenie zreplikowanych danych zebranych przy użyciu Prometheus HA?
Aby rozwiązać te problemy, stworzyliśmy Thanos. W poniższych sekcjach opisano, jak podeszliśmy do tych kwestii i wyjaśniliśmy nasze cele.
Zapytanie o dane z wielu instancji Prometheusa (zapytanie globalne)
Prometheus oferuje funkcjonalne podejście do shardingu. Nawet pojedynczy serwer Prometheus zapewnia wystarczającą skalowalność, aby uwolnić użytkowników od złożoności poziomego fragmentowania w prawie wszystkich przypadkach użycia.
Chociaż jest to świetny model wdrażania, często konieczne jest uzyskanie dostępu do danych na różnych serwerach Prometheus za pośrednictwem jednego interfejsu API lub interfejsu użytkownika — widok globalny. Oczywiście możliwe jest wyświetlenie wielu zapytań w jednym panelu Grafana, jednak każde zapytanie może zostać wykonane tylko na jednym serwerze Prometheus. Z drugiej strony dzięki Thanos możesz wysyłać zapytania i agregować dane z wielu serwerów Prometheus, ponieważ wszystkie są dostępne z jednego punktu końcowego.
Wcześniej, aby uzyskać globalny widok w Improbable, organizowaliśmy nasze instancje Prometheusa na wielu poziomach . Oznaczało to utworzenie jednego metaserwera Prometheus, który zbierałby niektóre metryki z każdego serwera-liścia.
To podejście okazało się problematyczne. Doprowadziło to do bardziej złożonych konfiguracji, dodania dodatkowego potencjalnego punktu awarii i zastosowania złożonych reguł zapewniających, że stowarzyszony punkt końcowy otrzyma tylko te dane, których potrzebuje. Ponadto tego rodzaju federacja nie pozwala uzyskać prawdziwego widoku globalnego, ponieważ nie wszystkie dane są dostępne w ramach pojedynczego żądania API.
Ściśle z tym powiązany jest ujednolicony widok danych gromadzonych na serwerach Prometheus o wysokiej dostępności (HA). Model HA Prometheusa niezależnie zbiera dane dwukrotnie, co jest tak proste, że nie może być prostsze. Jednak użycie połączonego i zdeduplikowanego widoku obu strumieni byłoby znacznie wygodniejsze.
Oczywiście istnieje zapotrzebowanie na serwery Prometheus o wysokiej dostępności. W Improbable bardzo poważnie podchodzimy do monitorowania danych minuta po minucie, ale posiadanie jednej instancji Prometheusa na klaster oznacza pojedynczy punkt awarii. Każdy błąd konfiguracji lub awaria sprzętu może potencjalnie prowadzić do utraty ważnych danych. Nawet proste wdrożenie może spowodować drobne zakłócenia w zbieraniu metryk, ponieważ ponowne uruchomienie może być znacznie dłuższe niż interwał skrobania.
Niezawodne przechowywanie danych historycznych
Naszym marzeniem ( podzielanym przez większość użytkowników Prometheusa) jest tanie, szybkie i długoterminowe przechowywanie metryk. W Improbable zmuszeni byliśmy skonfigurować okres przechowywania metryk na dziewięć dni (dla Prometheusa 1.8). To dodaje oczywistych ograniczeń temu, jak daleko możemy spojrzeć wstecz.
Prometheus 2.0 poprawił się pod tym względem, ponieważ liczba szeregów czasowych nie wpływa już na ogólną wydajność serwera (patrz. ). Jednak Prometheus przechowuje dane na dysku lokalnym. Chociaż wysokowydajna kompresja danych może znacznie zmniejszyć wykorzystanie lokalnego dysku SSD, ostatecznie nadal istnieje ograniczenie ilości danych historycznych, które można przechowywać.
Dodatkowo w Improbable dbamy o niezawodność, prostotę i cenę. Duże dyski lokalne są trudniejsze w obsłudze i tworzeniu kopii zapasowych. Kosztują więcej i wymagają większej liczby narzędzi do tworzenia kopii zapasowych, co powoduje niepotrzebną złożoność.
Próbkowanie w dół
Kiedy zaczęliśmy pracować z danymi historycznymi, zdaliśmy sobie sprawę, że istnieją zasadnicze problemy z dużym-O, które powodują, że zapytania stają się coraz wolniejsze w miarę pracy z danymi tygodniami, miesiącami i latami.
Standardowym rozwiązaniem tego problemu byłoby (downsampling) - zmniejszenie częstotliwości próbkowania sygnału. Dzięki próbkowaniu w dół możemy „skalować” do większego zakresu czasu i utrzymywać tę samą liczbę próbek, zapewniając responsywność zapytań.
Próbkowanie w dół starych danych jest nieuniknionym wymogiem każdego rozwiązania do długoterminowego przechowywania danych i wykracza poza możliwości zwykłego Prometheusa.
Dodatkowe cele
Jednym z pierwotnych celów projektu Thanos była płynna integracja z dowolnymi istniejącymi instalacjami Prometheus. Drugim celem była łatwość obsługi przy minimalnych barierach wejścia. Wszelkie zależności powinny być łatwo spełnione zarówno dla małych, jak i dużych użytkowników, co oznacza również niski koszt bazowy.
Architektura Thanosa
Po wymienieniu naszych celów w poprzedniej sekcji, przeanalizujmy je i zobaczmy, jak Thanos rozwiązuje te problemy.
Widok globalny
Aby uzyskać globalny widok na istniejące instancje Prometheus, musimy połączyć pojedynczy punkt wejścia żądań ze wszystkimi serwerami. Dokładnie to robi komponent Thanos. . Jest wdrażany obok każdego serwera Prometheus i działa jako serwer proxy, obsługując lokalne dane Prometheus za pośrednictwem interfejsu API sklepu gRPC, umożliwiając pobieranie danych szeregów czasowych według znaczników i zakresu czasu.
Z drugiej strony znajduje się skalowalny, bezstanowy komponent Querier, który nie robi nic więcej niż tylko odpowiadanie na zapytania PromQL za pośrednictwem standardowego interfejsu API HTTP Prometheus. Querier, Sidecar i inne komponenty Thanos komunikują się za pośrednictwem .
- Querier po otrzymaniu żądania łączy się z odpowiednim serwerem Store API, czyli z naszymi Sidecarami i odbiera dane szeregów czasowych z odpowiednich serwerów Prometheus.
- Następnie łączy odpowiedzi i wykonuje na nich zapytanie PromQL. Querier może łączyć zarówno dane rozłączne, jak i zduplikowane dane z serwerów Prometheus HA.
To rozwiązuje główny element naszej układanki — połączenie danych z izolowanych serwerów Prometheus w jeden widok. W rzeczywistości Thanos może być używany tylko do tej funkcji. Nie trzeba wprowadzać żadnych zmian w istniejących serwerach Prometheus!
Nieograniczony okres przydatności do spożycia!
Jednak prędzej czy później będziemy chcieli przechowywać dane dłużej niż normalny czas przechowywania Prometheusa. Do przechowywania danych historycznych wybraliśmy magazyn obiektowy. Jest powszechnie dostępny w dowolnej chmurze, a także w lokalnych centrach danych i jest bardzo opłacalny. Ponadto prawie każda pamięć obiektowa jest dostępna za pośrednictwem dobrze znanego interfejsu API S3.
Prometheus zapisuje dane z pamięci RAM na dysk mniej więcej co dwie godziny. Przechowywany blok danych zawiera wszystkie dane przez ustalony okres czasu i jest niezmienny. Jest to bardzo wygodne, ponieważ Thanos Sidecar może po prostu zajrzeć do katalogu danych Prometheusa i, gdy pojawią się nowe bloki, załadować je do zasobników przechowywania obiektów.
Załadowanie do magazynu obiektów od razu po zapisie na dysk pozwala także zachować prostotę skrobaka (Prometheus i Thanos Sidecar). Co upraszcza wsparcie, koszty i projektowanie systemu.
Jak widać, tworzenie kopii zapasowych danych jest bardzo proste. Ale co z zapytaniami o dane w pamięci obiektowej?
Komponent Thanos Store działa jako serwer proxy do pobierania danych z pamięci obiektowej. Podobnie jak Thanos Sidecar uczestniczy w klastrze plotkarskim i implementuje Store API. W ten sposób istniejący Querier może traktować go jak wózek boczny, jako kolejne źródło danych szeregów czasowych - nie jest wymagana żadna specjalna konfiguracja.
Bloki danych szeregów czasowych składają się z kilku dużych plików. Ładowanie ich na żądanie byłoby dość nieefektywne, a lokalne buforowanie wymagałoby ogromnej ilości pamięci i miejsca na dysku.
Zamiast tego Store Gateway wie, jak obsługiwać format pamięci Prometheus. Dzięki inteligentnemu harmonogramowi zapytań i buforowaniu tylko niezbędnych części indeksowych bloków, możliwa jest redukcja złożonych zapytań do minimalnej liczby żądań HTTP do plików obiektowych. W ten sposób można zmniejszyć liczbę żądań o cztery do sześciu rzędów wielkości i osiągnąć czasy odpowiedzi, które na ogół trudno odróżnić od żądań do danych na lokalnym dysku SSD.
Jak pokazano na powyższym diagramie, Thanos Querier znacznie zmniejsza koszt zapytania dotyczącego danych obiektowych, wykorzystując format pamięci Prometheus i umieszczając powiązane dane obok siebie. Stosując takie podejście, możemy połączyć wiele pojedynczych żądań w minimalną liczbę operacji masowych.
Kompaktowanie i downsampling
Po pomyślnym załadowaniu nowego bloku danych szeregów czasowych do magazynu obiektowego traktujemy go jako dane „historyczne”, które są natychmiast dostępne za pośrednictwem Store Gateway.
Jednak po pewnym czasie bloki z jednego źródła (Prometeusz z Sidecar) kumulują się i nie wykorzystują już pełnego potencjału indeksującego. Aby rozwiązać ten problem, wprowadziliśmy kolejny komponent o nazwie Compactor. Po prostu stosuje lokalny silnik kompaktowania Prometheusa do danych historycznych w pamięci obiektowej i można go uruchomić jako proste, okresowe zadanie wsadowe.
Dzięki wydajnej kompresji odpytywanie pamięci przez dłuższy okres czasu nie stwarza problemu pod względem wielkości danych. Jednak potencjalny koszt rozpakowania miliarda wartości i uruchomienia ich przez procesor zapytań nieuchronnie spowoduje dramatyczne wydłużenie czasu wykonania zapytania. Z drugiej strony, ponieważ na ekranie znajdują się setki punktów danych na piksel, nawet wizualizacja danych w pełnej rozdzielczości staje się niemożliwa. Zatem downsampling jest nie tylko możliwy, ale także nie doprowadzi do zauważalnej utraty dokładności.
Aby zmniejszyć próbkowanie danych, Compactor w sposób ciągły agreguje dane z rozdzielczością pięciu minut i jednej godziny. Dla każdego surowego fragmentu zakodowanego przy użyciu kompresji TSDB XOR przechowywane są różne typy danych zagregowanych, takie jak min, max lub suma dla jednego bloku. Dzięki temu Querier może automatycznie wybrać agregat odpowiedni dla danego zapytania PromQL.
Aby użytkownik mógł korzystać z danych o zmniejszonej precyzji, nie jest wymagana żadna specjalna konfiguracja. Querier automatycznie przełącza się pomiędzy różnymi rozdzielczościami i surowymi danymi w miarę powiększania i pomniejszania obrazu przez użytkownika. W razie potrzeby użytkownik może kontrolować to bezpośrednio za pomocą parametru „krok” w żądaniu.
Ponieważ koszt przechowywania jednego GB jest niski, Thanos domyślnie przechowuje dane surowe, dane w rozdzielczości pięciominutowej i jednogodzinnej. Nie ma potrzeby usuwania oryginalnych danych.
Zasady nagrywania
Nawet w przypadku Thanos zasady nagrywania są istotną częścią stosu monitorowania. Zmniejszają złożoność, opóźnienia i koszty zapytań. Są także wygodne dla użytkowników w celu uzyskania zagregowanych danych według metryk. Thanos opiera się na prostych instancjach Prometheusa, dlatego całkowicie akceptowalne jest przechowywanie reguł nagrywania i alertów na istniejącym serwerze Prometheus. Jednak w niektórych przypadkach może to nie wystarczyć:
- Globalny alert i reguła (na przykład alert, gdy usługa nie działa w więcej niż dwóch z trzech klastrów).
- Reguła dotycząca danych poza pamięcią lokalną.
- Chęć przechowywania wszystkich reguł i alertów w jednym miejscu.
We wszystkich tych przypadkach Thanos zawiera oddzielny komponent o nazwie Linijka, który oblicza reguły i alerty za pomocą zapytań Thanos. Udostępniając dobrze znany StoreAPI, węzeł Query może uzyskać dostęp do świeżo obliczonych metryk. Później są one również przechowywane w magazynie obiektowym i udostępniane poprzez Store Gateway.
Moc Thanosa
Thanos jest na tyle elastyczny, że można go dostosować do własnych potrzeb. Jest to szczególnie przydatne podczas migracji ze zwykłego Prometeusza. Podsumujmy szybko, czego dowiedzieliśmy się o komponentach Thanos, za pomocą krótkiego przykładu. Oto jak przenieść zwykłego Prometeusza w świat „nieograniczonego przechowywania danych”:
- Dodaj Thanos Sidecar do swoich serwerów Prometheus — na przykład kontener sidecar w podze Kubernetes.
- Wdróż wiele replik Thanos Querier, aby móc przeglądać dane. Na tym etapie łatwo jest ustalić plotkę pomiędzy Scraperem a Querierem. Aby sprawdzić interakcję komponentów, użyj metryki „thanos_cluster_members”.
Tylko te dwa kroki wystarczą, aby zapewnić globalny widok i bezproblemową deduplikację danych z potencjalnych replik Prometheus HA! Po prostu podłącz swoje pulpity nawigacyjne do punktu końcowego HTTP Querier lub użyj bezpośrednio interfejsu użytkownika Thanos.
Jeśli jednak potrzebujesz kopii zapasowej metryk i długoterminowego przechowywania, musisz wykonać jeszcze trzy kroki:
- Utwórz segment AWS S3 lub GCS. Skonfiguruj Sidecar, aby kopiował dane do tych zasobników. Lokalne przechowywanie danych można teraz zminimalizować.
- Wdróż Store Gateway i połącz go z istniejącym klastrem plotek. Teraz możesz przeglądać dane z kopii zapasowej!
- Wdróż Compactor, aby poprawić wydajność zapytań w długich okresach czasu, korzystając z kompresji i próbkowania w dół.
Jeśli chcesz dowiedzieć się więcej, nie wahaj się i zajrzyj do naszego и !
W zaledwie pięciu krokach przekształciliśmy Prometheusa w niezawodny system monitorowania z widokiem globalnym, nieograniczonym czasem przechowywania i potencjalnie wysoką dostępnością metryk.
Pull request: potrzebujemy Cię!
od samego początku był projektem open source. Bezproblemowa integracja z Prometheusem i możliwość wykorzystania tylko części Thanos sprawia, że jest to doskonały wybór do łatwego skalowania systemu monitorowania.
Zawsze jesteśmy otwarci na prośby i problemy dotyczące ściągania GitHub. W międzyczasie skontaktuj się z nami za pośrednictwem Github Issues lub Slackjeśli masz pytania, uwagi lub chcesz podzielić się swoimi doświadczeniami z korzystania z niego! Jeśli podoba Ci się to, co robimy w Improbable, nie wahaj się z nami skontaktować - !
Źródło: www.habr.com