{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 skalowalny Prometheus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

T\u0142umaczenie artyku\u0142u przygotowano specjalnie dla student\u00f3w kursu \u201ePraktyki i narz\u0119dzia DevOps\u201c<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> jest programist\u0105, entuzjast\u0105 Go i mi\u0142o\u015bnikiem rozwi\u0105zywania skomplikowanych problem\u00f3w. Jest r\u00f3wnie\u017c konserwatorem Prometheus i wsp\u00f3\u0142za\u0142o\u017cycielem Kubernetes SIG instrumentation. W przesz\u0142o\u015bci by\u0142 in\u017cynierem produkcji w SoundCloud i kierowa\u0142 zespo\u0142em monitorowania w CoreOS. Obecnie pracuje w Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> jest in\u017cynierem infrastruktury w Improbable. Interesuje si\u0119 nowymi technologiami i problemami system\u00f3w rozproszonych. Ma do\u015bwiadczenie w programowaniu niskopoziomowym w Intel, do\u015bwiadczenie w roli kontrybutora w Mesos oraz globalne do\u015bwiadczenie SRE w Improbable. Pracuje nad popraw\u0105 \u015bwiata mikroserwis\u00f3w. Jego trzy pasje to: Golang, open source i siatk\u00f3wka.<\/i><\/p>\n

Patrz\u0105c na nasz flagowy produkt SpatialOS, mo\u017cna si\u0119 domy\u015bli\u0107, \u017ce Improbable potrzebuje wysokowydajnej, globalnej infrastruktury chmurowej z dziesi\u0105tkami klastr\u00f3w Kubernetes. Byli\u015bmy jednymi z pierwszych, kt\u00f3rzy zacz\u0119li korzysta\u0107 z systemu monitorowania Prometheus<\/a><\/noindex>. Prometheus jest w stanie \u015bledzi\u0107 miliony metryk w czasie rzeczywistym i dostarczany jest z pot\u0119\u017cnym j\u0119zykiem zapyta\u0144, umo\u017cliwiaj\u0105cym wydobycie potrzebnych informacji.<\/p>\n

Prostota i niezawodno\u015b\u0107 Prometheus jest jednym z jego g\u0142\u00f3wnych atut\u00f3w. Jednak po osi\u0105gni\u0119ciu okre\u015blonego rozmiaru napotkali\u015bmy kilka niedoci\u0105gni\u0119\u0107. Aby rozwi\u0105za\u0107 te problemy, opracowali\u015bmy Thanos<\/a><\/noindex> projekt open source stworzony przez firm\u0119 Improbable, maj\u0105cy na celu bezproblemow\u0105 transformacj\u0119 istniej\u0105cych klastr\u00f3w Prometheus w jedn\u0105, zintegrowan\u0105 system monitorowania z nieograniczonym przechowywaniem danych historycznych. Thanos jest dost\u0119pny na Github tutaj<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

B\u0105d\u017a na bie\u017c\u0105co z najnowszymi wiadomo\u015bciami od Improbable.<\/a><\/noindex><\/p>\n

Nasze cele z Thanos<\/h2>\n

\nW miar\u0119 rozwoju pojawiaj\u0105 si\u0119 problemy wykraczaj\u0105ce poza mo\u017cliwo\u015bci standardowego Prometheus. Jak pewnie i ekononomicznie przechowywa\u0107 petabajty danych historycznych? Czy mo\u017cna to zrobi\u0107 bez uszczerbku dla czasu odpowiedzi na zapytania? Czy mo\u017cna uzyska\u0107 dost\u0119p do wszystkich metryk znajduj\u0105cych si\u0119 na r\u00f3\u017cnych serwerach Prometheus za pomoc\u0105 jednego zapytania API? Czy mo\u017cna jako\u015b po\u0142\u0105czy\u0107 zreplikowane dane zebrane przy u\u017cyciu Prometheus HA?<\/p>\n

Aby odpowiedzie\u0107 na te pytania, stworzyli\u015bmy Thanos. W kolejnych sekcjach opisujemy, jak podeszli\u015bmy do rozwi\u0105zywania tych problem\u00f3w oraz wyja\u015bniamy cele, kt\u00f3re mieli\u015bmy na my\u015bli.<\/p>\n

Zg\u0142aszanie danych z kilku instancji Prometheus (globalne zapytanie)<\/h4>\n

\nPrometheus oferuje funkcjonalne podej\u015bcie do shardingu. Nawet jeden serwer Prometheus zapewnia wystarczaj\u0105c\u0105 skalowalno\u015b\u0107, aby uwolni\u0107 u\u017cytkownik\u00f3w od z\u0142o\u017cono\u015bci poziomego shardingu w praktycznie wszystkich zastosowaniach.<\/p>\n

Chocia\u017c to doskona\u0142y model wdro\u017cenia, cz\u0119sto konieczny jest dost\u0119p do danych z r\u00f3\u017cnych serwer\u00f3w Prometheus za po\u015brednictwem jednego API lub UI \u2014 globalny widok. Oczywi\u015bcie istnieje mo\u017cliwo\u015b\u0107 przedstawienia wielu zapyta\u0144 w jednym panelu Grafana, ale ka\u017cde zapytanie mo\u017ce by\u0107 wykonane tylko na jednym serwerze Prometheus. Z drugiej strony, u\u017cywaj\u0105c Thanos, mo\u017cesz zapytywa\u0107 i agregowa\u0107 dane z kilku serwer\u00f3w Prometheus, poniewa\u017c wszystkie s\u0105 dost\u0119pne z jednego punktu ko\u0144cowego.<\/p>\n

Wcze\u015bniej, aby uzyska\u0107 globalny widok w Improbable, zorganizowali\u015bmy nasze instancje Prometheus w wielopoziomow\u0105 Hierarchiczn\u0105 Federacj\u0119<\/a><\/noindex>Oznacza\u0142o to stworzenie jednego meta-serwera Prometheus, kt\u00f3ry zbiera cz\u0119\u015b\u0107 metryk z ka\u017cdego 'li\u015bciowego' serwera.<\/p>\n

\"Thanos
\n
\nTo podej\u015bcie okaza\u0142o si\u0119 problematyczne. Doprowadzi\u0142o do skomplikowania konfiguracji, dodania dodatkowego potencjalnego punktu awarii oraz zastosowania skomplikowanych zasad do udost\u0119pnienia federacyjnego punktu ko\u0144cowego tylko potrzebnych danych. Ponadto, federacja tego rodzaju nie pozwala na uzyskanie rzeczywistego globalnego widoku, poniewa\u017c nie wszystkie dane s\u0105 dost\u0119pne z jednego zapytania API.<\/p>\n

Niezwykle zwi\u0105zane z tym jest jednolite przedstawienie danych, zbieranych na wysoko dost\u0119pnych (high-availability, HA) serwerach Prometheus. Model HA Prometheus zbiera dane niezale\u017cnie dwukrotnie, co jest na tyle proste, \u017ce prostsze by\u0107 nie mo\u017ce. Jednak\u017ce korzystanie ze zintegrowanego i deduplikowanego widoku obu strumieni by\u0142oby znacznie wygodniejsze.<\/p>\n

Oczywi\u015bcie, w wysoko dost\u0119pnych serwerach Prometheus istnieje potrzeba. W Improbable powa\u017cnie traktujemy monitorowanie danych w czasie rzeczywistym, ale posiadanie jednego egzemplarza Prometheus w klastrze jest jedynym punktem awarii. Ka\u017cdy b\u0142\u0105d konfiguracji lub awaria sprz\u0119tu mog\u0105 potencjalnie prowadzi\u0107 do utraty wa\u017cnych danych. Nawet proste wdro\u017cenie mo\u017ce prowadzi\u0107 do ma\u0142ych problem\u00f3w w zbieraniu metryk, poniewa\u017c ponowne uruchomienie mo\u017ce zaj\u0105\u0107 znacznie wi\u0119cej czasu ni\u017c interwa\u0142 skanowania.<\/p>\n

Niezawodne przechowywanie danych historycznych<\/h4>\n

\nTanie, szybkie i d\u0142ugoterminowe przechowywanie metryk to nasz wsp\u00f3lny cel (dzielony przez wi\u0119kszo\u015b\u0107 u\u017cytkownik\u00f3w Prometheus). W Improbable musieli\u015bmy ustawi\u0107 czas przechowywania metryk na dziewi\u0119\u0107 dni (dla Prometheus 1.8). To wprowadza oczywiste ograniczenia w zakresie tego, jak daleko mo\u017cemy spojrze\u0107 wstecz.<\/p>\n

Prometheus 2.0 w tym zakresie sta\u0142 si\u0119 lepszy, poniewa\u017c liczba serii czasowych nie wp\u0142ywa ju\u017c na og\u00f3ln\u0105 wydajno\u015b\u0107 serwera (zob. kluczowe wyst\u0105pienie KubeCon na temat Prometheus 2<\/a><\/noindex>). Niemniej jednak Prometheus przechowuje dane na lokalnym dysku. Chocia\u017c wysokoefektywne kompresowanie danych mo\u017ce znacznie zmniejszy\u0107 zu\u017cycie lokalnego SSD, ostatecznie wci\u0105\u017c istnieje ograniczenie na ilo\u015b\u0107 przechowywanych danych historycznych.<\/p>\n

Ponadto, w Improbable dbamy o niezawodno\u015b\u0107, prostot\u0119 i koszt. Du\u017ce lokalne dyski s\u0105 trudniejsze w eksploatacji i tworzeniu kopii zapasowych. S\u0105 dro\u017csze i wymagaj\u0105 wi\u0119cej narz\u0119dzi do tworzenia kopii zapasowych, co prowadzi do zb\u0119dnej z\u0142o\u017cono\u015bci.<\/p>\n

Pr\u00f3bkowanie w d\u00f3\u0142<\/h4>\n

\nGdy zacz\u0119li\u015bmy pracowa\u0107 z danymi historycznymi, zrozumieli\u015bmy, \u017ce istniej\u0105 fundamentalne trudno\u015bci zwi\u0105zane z O-wielko\u015bci\u0105, kt\u00f3re sprawiaj\u0105, \u017ce zapytania staj\u0105 si\u0119 coraz wolniejsze, je\u015bli pracujemy z danymi z tygodni, miesi\u0119cy i lat.<\/p>\n

Standardowym rozwi\u0105zaniem tego problemu b\u0119dzie pr\u00f3bkowanie w d\u00f3\u0142<\/a><\/noindex> \u2014 zmniejszanie cz\u0119stotliwo\u015bci pr\u00f3bkowania sygna\u0142u. Dzi\u0119ki obni\u017ceniu pr\u00f3bkowania mo\u017cemy \"zmniejszy\u0107 skal\u0119\" do wi\u0119kszego zakresu czasowego i zachowa\u0107 tak\u0105 sam\u0105 liczb\u0119 pr\u00f3bek, co pozwoli na utrzymanie responsywno\u015bci zapyta\u0144.<\/p>\n

Pr\u00f3bkowanie w d\u00f3\u0142 starych danych jest nieuniknionym wymaganiem ka\u017cdego rozwi\u0105zania do d\u0142ugoterminowego przechowywania i wykracza poza standardowy Prometheus.<\/p>\n

Dodatkowe cele<\/h4>\n

\nJednym z pocz\u0105tkowych cel\u00f3w projektu Thanos by\u0142a bezproblemowa integracja z dowolnymi istniej\u0105cymi instalacjami Prometheus. Drugim celem by\u0142a \u0142atwa eksploatacja z minimaln\u0105 barier\u0105 wej\u015bcia. Wszystkie zale\u017cno\u015bci powinny by\u0107 \u0142atwe do zaspokojenia zar\u00f3wno dla ma\u0142ych, jak i du\u017cych u\u017cytkownik\u00f3w, co r\u00f3wnie\u017c wi\u0105\u017ce si\u0119 z nieznacznymi kosztami podstawowymi.<\/p>\n

Architektura Thanos<\/h2>\n

\nPo wymienieniu naszych cel\u00f3w w poprzedniej sekcji, przyjrzyjmy si\u0119, jak Thanos rozwi\u0105zuje te problemy.<\/p>\n

Globalny widok<\/h4>\n

\nAby uzyska\u0107 widok globalny na istniej\u0105ce instancje Prometheusa, musimy po\u0142\u0105czy\u0107 jednolit\u0105 bram\u0119 zapyta\u0144 ze wszystkimi serwerami. To w\u0142a\u015bnie robi komponent Thanos. Sidecar<\/a><\/noindex>. Jest wdra\u017cany obok ka\u017cdego serwera Prometheus i dzia\u0142a jako proxy, obs\u0142uguj\u0105c lokalne dane Prometheusa przez interfejs gRPC Store API, kt\u00f3ry pozwala na wybieranie danych szereg\u00f3w czasowych wed\u0142ug etykiet i zakresu czasowego.<\/p>\n

Z drugiej strony znajduje si\u0119 komponent Querier, kt\u00f3ry jest skalowalny horyzontalnie i nie przechowuje stanu, kt\u00f3ry robi nieco wi\u0119cej ni\u017c tylko odpowiada na zapytania PromQL przez standardowe API HTTP Prometheusa. Komponenty Querier, Sidecar i inne elementy Thanos komunikuj\u0105 si\u0119 za pomoc\u0105 protoko\u0142u gossip.<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. Querier, odbieraj\u0105c zapytanie, \u0142\u0105czy si\u0119 z odpowiednim serwerem Store API, czyli z naszymi Sidecar'ami, i uzyskuje dane szereg\u00f3w czasowych z odpowiednich serwer\u00f3w Prometheus.<\/li>\n
  2. Nast\u0119pnie \u0142\u0105czy odpowiedzi i wykonuje zapytanie PromQL. Querier mo\u017ce \u0142\u0105czy\u0107 zar\u00f3wno nieprzechodz\u0105ce dane, jak i dane zduplikowane z serwer\u00f3w HA Prometheusa.<\/li>\n<\/ol>\n

    \nTo rozwi\u0105zuje g\u0142\u00f3wn\u0105 cz\u0119\u015b\u0107 naszej zagadki \u2014 scalenie danych z izolowanych serwer\u00f3w Prometheusa w jednolite przedstawienie. W rzeczywisto\u015bci Thanos mo\u017cna u\u017cywa\u0107 tylko dla tej funkcji. Nie wymaga si\u0119 \u017cadnych zmian w istniej\u0105cych serwerach Prometheusa!<\/p>\n

    Nielimitowany czas przechowywania!<\/h4>\n

    \nJednak pr\u0119dzej czy p\u00f3\u017aniej b\u0119dziemy chcieli zachowa\u0107 dane, kt\u00f3re przekraczaj\u0105 standardowy czas przechowywania Prometheusa. Do przechowywania danych historycznych wybrali\u015bmy magazyn obiektowy. Jest on szeroko dost\u0119pny w ka\u017cdej chmurze, a tak\u017ce w lokalnych centrach danych i jest bardzo ekonomiczny. Co wi\u0119cej, niemal ka\u017cdy magazyn obiektowy jest dost\u0119pny przez dobrze znany interfejs API S3.<\/p>\n

    Prometheus zapisuje dane z pami\u0119ci operacyjnej na dysk co oko\u0142o dwie godziny. Blok zapisywanych danych zawiera wszystkie dane za okre\u015blony przedzia\u0142 czasu i jest niezmienny. To bardzo wygodne, poniewa\u017c Thanos Sidecar mo\u017ce po prostu przegl\u0105da\u0107 katalog danych Prometheusa i, w miar\u0119 pojawiania si\u0119 nowych blok\u00f3w, \u0142adowa\u0107 je do koszyk\u00f3w magazynu obiektowego.<\/p>\n

    \"Thanos
    \n
    \n\u0141adowanie do magazynu obiektowego bezpo\u015brednio po zapisaniu na dysk pozwala r\u00f3wnie\u017c zachowa\u0107 prostot\u0119 'skrapera' (Prometheus i Thanos Sidecar). Co upraszcza utrzymanie, koszty i projektowanie systemu.<\/p>\n

    Jak wida\u0107, kopia zapasowa danych jest realizowana bardzo prosto. A co z zapytaniami do danych w obiektowej pami\u0119ci masowej?<\/p>\n

    Komponent Thanos Store dzia\u0142a jako proxy do pozyskiwania danych z obiektowej pami\u0119ci masowej. Tak jak Thanos Sidecar, uczestniczy w gossip-klastrze i implementuje Store API. W ten spos\u00f3b istniej\u0105ce Querier mog\u0105 traktowa\u0107 go jak Sidecar, jako dodatkowe \u017ar\u00f3d\u0142o danych czasowych \u2014 nie jest wymagane \u017cadne specjalne ustawienie.<\/p>\n

    \"Thanos
    \n
    \nBloki danych czasowych sk\u0142adaj\u0105 si\u0119 z kilku du\u017cych plik\u00f3w. Pobieranie ich na \u017c\u0105danie by\u0142oby do\u015b\u0107 nieefektywne, a lokalne buforowanie wymaga\u0142oby ogromnej pami\u0119ci i przestrzeni dyskowej.<\/p>\n

    Zamiast tego Store Gateway wie, jak obs\u0142ugiwa\u0107 format przechowywania Prometheus. Dzi\u0119ki inteligentnemu planowaniu zapyta\u0144 i buforowaniu tylko niezb\u0119dnych cz\u0119\u015bci indeksu blok\u00f3w, mo\u017cliwe sta\u0142o si\u0119 skr\u00f3cenie z\u0142o\u017conych zapyta\u0144 do minimalnej liczby zapyta\u0144 HTTP do plik\u00f3w obiektowej pami\u0119ci masowej. W ten spos\u00f3b mo\u017cna zredukowa\u0107 liczb\u0119 zapyta\u0144 o cztery do sze\u015bciu rz\u0119d\u00f3w i osi\u0105gn\u0105\u0107 czas odpowiedzi, kt\u00f3ry jest og\u00f3lnie trudny do odr\u00f3\u017cnienia od zapyta\u0144 do danych na lokalnym SSD.<\/p>\n

    \"Thanos
    \n
    \nJak pokazano na powy\u017cszym diagramie, Thanos Querier znacznie obni\u017ca koszty jednego zapytania do danych w obiektowej pami\u0119ci masowej, korzystaj\u0105c z formatu przechowywania Prometheus i umieszczaj\u0105c powi\u0105zane dane blisko siebie. U\u017cywaj\u0105c tego podej\u015bcia, mo\u017cemy po\u0142\u0105czy\u0107 wiele pojedynczych zapyta\u0144 w minimaln\u0105 liczb\u0119 operacji zbiorczych.<\/p>\n

    Dekompozycja i downsampling<\/h4>\n

    \nPo tym, jak nowy blok danych czasowych zostanie pomy\u015blnie za\u0142adowany do obiektowej pami\u0119ci masowej, traktujemy go jako \u201edane historyczne\u201d, kt\u00f3re natychmiast staj\u0105 si\u0119 dost\u0119pne za po\u015brednictwem Store Gateway.<\/p>\n

    Jednak po pewnym czasie bloki z jednego \u017ar\u00f3d\u0142a (Prometheus z Sidecar) gromadz\u0105 si\u0119 i ju\u017c nie wykorzystuj\u0105 ca\u0142ego potencja\u0142u indeksacji. Aby rozwi\u0105za\u0107 ten problem, wprowadzili\u015bmy kolejny komponent o nazwie Compactor. Po prostu stosuje lokalny mechanizm kompaktowania Prometheus do danych historycznych w obiektowej pami\u0119ci masowej i mo\u017ce by\u0107 uruchamiany jako prosty okresowy zada\u0144 wsadowe.<\/p>\n

    \"Thanos
    \n
    \nDzi\u0119ki efektywnemu kompresowaniu, zapytanie do magazynu przez d\u0142ugi czas nie stwarza problem\u00f3w z perspektywy rozmiaru danych. Jednak potencjalny koszt dekompresji miliarda warto\u015bci i przetwarzania ich przez silnik zapyta\u0144 nieuchronnie prowadzi do znacznego wyd\u0142u\u017cenia czasu wykonania zapytania. Z drugiej strony, poniewa\u017c na ka\u017cdy piksel ekranu przypada setki punkt\u00f3w danych, staje si\u0119 niemo\u017cliwe nawet wizualizowanie danych w pe\u0142nej rozdzielczo\u015bci. Tak wi\u0119c, downsampling nie tylko jest mo\u017cliwy, ale r\u00f3wnie\u017c nie prowadzi do zauwa\u017calnej utraty dok\u0142adno\u015bci. <\/p>\n

    \"Thanos
    \n
    \nDo downsample'ingu danych Compactor ci\u0105gle agreguje dane o rozdzielczo\u015bci pi\u0119ciu minut i jednej godziny. Dla ka\u017cdego nieprzetworzonego fragmentu, zakodowanego przy u\u017cyciu kompresji TSDB XOR, przechowywane s\u0105 r\u00f3\u017cne typy zagregowanych danych, takie jak min, max lub sum dla jednego bloku. Umo\u017cliwia to Querierowi automatyczne wybieranie agregatu, kt\u00f3ry pasuje do danego zapytania PromQL. <\/p>\n

    Aby korzysta\u0107 z danych o obni\u017conej precyzji, u\u017cytkownik nie potrzebuje \u017cadnej specjalnej konfiguracji. Querier automatycznie prze\u0142\u0105cza si\u0119 mi\u0119dzy r\u00f3\u017cnymi rozdzielczo\u015bciami a danymi surowymi w miar\u0119 powi\u0119kszania i zmniejszania skali przez u\u017cytkownika. W razie potrzeby u\u017cytkownik mo\u017ce zarz\u0105dza\u0107 tym bezpo\u015brednio poprzez parametr \u201estep\u201d w zapytaniu. <\/p>\n

    Poniewa\u017c koszt przechowywania jednego GB jest niewielki, domy\u015blnie Thanos przechowuje dane surowe, dane o rozdzielczo\u015bci pi\u0119ciu minut i jednej godziny. Nie ma potrzeby usuwania danych surowych.<\/p>\n

    Regu\u0142y rejestracji<\/h2>\n

    \nNawet z Thanos, regu\u0142y rejestracji s\u0105 istotn\u0105 cz\u0119\u015bci\u0105 stosu monitorowania. Zmniejszaj\u0105 z\u0142o\u017cono\u015b\u0107, op\u00f3\u017anienie i koszt zapyta\u0144. S\u0105 r\u00f3wnie\u017c wygodne dla u\u017cytkownik\u00f3w do uzyskiwania zagregowanych danych na podstawie metryk. Thanos opiera si\u0119 na standardowych instancjach Prometheus, wi\u0119c jak najbardziej dozwolone jest przechowywanie regu\u0142 rejestracji i regu\u0142 alertowania na istniej\u0105cym serwerze Prometheus. Jednak w niekt\u00f3rych przypadkach mo\u017ce to by\u0107 niewystarczaj\u0105ce:<\/p>\n