{"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\/hr\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 skalabilan Prometheus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Prijevod \u010dlanka pripremljen je posebno za studente te\u010daja \u201eDevOps prakse i alati\u201c<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabijan Reinartz<\/a><\/noindex> \u2014 programer, entuzijast Go jezika i zaljubljenik u re\u0161avanje slo\u017eenih problema. Tako\u0111e je odr\u017eavaoc Prometheusa i suosniva\u010d Kubernetes SIG instrumentation. U pro\u0161losti je bio in\u017eenjer produkcije u SoundCloudu i vodio je tim za nadgledanje u CoreOS-u. Trenutno radi u Google-u.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 in\u017eenjer infrastrukture u Improbable-u. Radoznalost ga vu\u010de ka novim tehnologijama i problemima distribuiranih sistema. Ima iskustvo niskonivojnog programiranja u Intel-u, iskustvo doprinositelja u Mesos-u i produkcijsko iskustvo SRE svetskog nivoa u Improbable-u. Fokusira se na pobolj\u0161anje sveta mikroslu\u017ebi. Tri njegove ljubavi su: Golang, open source i odbojka.<\/i><\/p>\n

Gledaju\u0107i na\u0161 vode\u0107i proizvod SpatialOS, mo\u017eete naslutiti da je Improbable-u potrebna visoko dinami\u010dna obla\u010dna infrastruktura globalnog obima sa desetinama Kubernetes klastera. Bili smo jedni od prvih koji su po\u010deli koristiti sistem nadgledanja Prometheus<\/a><\/noindex>. Prometheus je sposoban da prati milionske metrike u realnom vremenu i dolazi sa mo\u0107nim jezikom upita koji omogu\u0107ava izvla\u010denje potrebnih informacija.<\/p>\n

Jednostavnost i pouzdanost Prometheusa su jedna od njegovih glavnih prednosti. Me\u0111utim, dostigav\u0161i odre\u0111eni obim, suo\u010dili smo se s nekoliko nedostataka. Da bismo re\u0161ili te probleme, razvili smo Thanos<\/a><\/noindex> \u2014 projekat otvorenog koda, razvijen od strane Improbable-a, za besprekorno transformisanje postoje\u0107ih Prometheus klastera u jedinstveni sistem nadgledanja s neograni\u010denim skladi\u0161tem istorijskih podataka. Thanos je dostupan na Github-u. ovdje<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Budite u toku s najnovijim vestima iz Improbable-a.<\/a><\/noindex><\/p>\n

Na\u0161i ciljevi s Thanosom<\/h2>\n

\nNa odre\u0111enom obimu javljaju se problemi koji nadilaze mogu\u0107nosti klasi\u010dnog Prometheusa. Kako pouzdano i ekonomi\u010dno skladi\u0161titi petabajte istorijskih podataka? Mo\u017ee li se to uraditi bez kompromitovanja vremena odgovora na upit? Mo\u017ee li se pristupiti svim metrima sme\u0161tenim na razli\u010ditim Prometheus serverima putem jednog API zahteva? Mo\u017ee li se na neki na\u010din spojiti replikovani podaci prikupljeni uz pomoc Prometheus HA?<\/p>\n

Da bismo odgovorili na ta pitanja, stvorili smo Thanos. U slede\u0107im odeljcima obja\u0161njavamo kako smo pristupili re\u0161enju ovih pitanja i obja\u0161njavamo ciljeve koje smo imali.<\/p>\n

Upit podataka iz vi\u0161e instanci Prometheusa (global query)<\/h4>\n

\nPrometheus nudi funkcionalan pristup sharding-u. \u010cak i jedan Prometheus server omogu\u0107ava dovoljnu skalabilnost da oslobodi korisnike od slo\u017eenosti horizontalnog sharding-a u prakti\u010dno svim slu\u010dajevima upotrebe.<\/p>\n

Iako je to sjajan model implementacije, \u010desto je potrebno pristupiti podacima na razli\u010ditim Prometheus serverima putem jednog API ili UI \u2014 globalnog pogleda. Naravno, mogu\u0107e je prikazati vi\u0161e upita na jednom Grafana panelu, ali svaki upit mo\u017ee biti izvr\u0161en samo na jedan Prometheus server. S druge strane, uz pomo\u0107 Thanosa mo\u017eete upititi i agregirati podatke s nekoliko Prometheus servera, budu\u0107i da su svi dostupni s jedne ta\u010dke.<\/p>\n

Ranije, za postizanje globalnog pogleda u Improbable-u, organizovali smo na\u0161e instance Prometheus u vi\u0161eslojnu Hijerarhijsku Federaciju<\/a><\/noindex>. To je zna\u010dilo stvaranje jednog meta-servera Prometheus, koji prikuplja dio metrika sa svakog \u201elistnog\u201c servera.<\/p>\n

\"Thanos
\n
\nOvaj pristup se pokazao problemati\u010dnim. Doveo je do komplikovanja konfiguracije, dodavanja dodatne potencijalne ta\u010dke kvara i primene slo\u017eenih pravila za omogu\u0107avanje federated ta\u010dki pristupa samo potrebnim podacima. Pored toga, takva federacija ne omogu\u0107ava pravilan globalni pregled, jer nisu svi podaci dostupni iz jednog API upita.<\/p>\n

Tome je blisko vezano jedinstveno predstavljanje podataka prikupljenih na visoko dostupnim (high-availability, HA) Prometheus serverima. HA model Prometheus-a samostalno prikuplja podatke dva puta, \u0161to je toliko jednostavno da ne mo\u017ee biti jednostavnije. Ipak, kori\u0161\u0107enje objedinjene i deduplikovane verzije oba toka bilo bi mnogo prakti\u010dnije.<\/p>\n

Naravno, u serverima Prometheus visoke dostupnosti postoji potreba. U Improbable-u ozbiljno shvatamo minutnu analizu podataka, ali postojanje jednog instance Prometheus u klasteru predstavlja jedinstvenu ta\u010dku kvara. Svaka gre\u0161ka u konfiguraciji ili kvar opreme mo\u017ee potencijalno dovesti do gubitka va\u017enih podataka. \u010cak i jednostavno implementiranje mo\u017ee dovesti do malih prekida u prikupljanju metrika, jer ponovno pokretanje mo\u017ee zna\u010dajno produ\u017eiti vreme izme\u0111u skrapinga.<\/p>\n

Pouzdano \u010duvanje istorijskih podataka<\/h4>\n

\nJeftina, brza i dugotrajna pohrana metrika je na\u0161 san (koji dijele ve\u0107ina korisnika Prometheusa). U Improbableu smo bili prisiljeni postaviti vrijeme pohrane metrika na devet dana (za Prometheus 1.8). To postavlja o\u010dite ograni\u010denja s obzirom na to koliko daleko mo\u017eemo pogledati unatrag.<\/p>\n

Prometheus 2.0 je u tom smislu bolji, jer broj vremenskih serija vi\u0161e ne utje\u010de na ukupnu izvedbu poslu\u017eitelja (vidi KubeCon keynote o Prometheusu 2<\/a><\/noindex>). Ipak, Prometheus pohranjuje podatke na lokalnom disku. Iako visoko u\u010dinkovito kompresiranje podataka mo\u017ee zna\u010dajno smanjiti kori\u0161tenje lokalnog SSD-a, na kraju i dalje postoji ograni\u010denje na koli\u010dinu pohranjenih povijesnih podataka.<\/p>\n

Osim toga, u Improbableu nam je stalo do pouzdanosti, jednostavnosti i tro\u0161ka. Veliki lokalni diskovi su slo\u017eeniji za upravljanje i sigurnosno kopiranje. Oni su skuplji i zahtijevaju vi\u0161e alata za sigurnosno kopiranje, \u0161to dovodi do suvi\u0161ne slo\u017eenosti.<\/p>\n

Downsampling<\/h4>\n

\n\u010cim smo po\u010deli raditi s povijesnim podacima, shvatili smo da postoje temeljni problemi s O-velikim, koji \u010dine upite sve sporijima i sporijima kada radimo s podacima iz tjedana, mjeseci i godina.<\/p>\n

Standardno rje\u0161enje za ovaj problem je downsampling<\/a><\/noindex> (downsampling) \u2014 smanjenje frekvencije uzorkovanja signala. Smanjenjem uzorkovanja mo\u017eemo \"skratiti\" do ve\u0107eg vremenskog raspona i odr\u017eavati isti broj uzoraka, \u0161to omogu\u0107uje odr\u017eavanje brzine upita.<\/p>\n

Downsampling starih podataka je neizbje\u017eni zahtjev bilo kakvog rje\u0161enja za dugoro\u010dnu pohranu i nadma\u0161uje obi\u010dni Prometheus.<\/p>\n

Dodatni ciljevi<\/h4>\n

\nJedan od prvotnih ciljeva projekta Thanos bio je besprijekorna integracija sa svim postoje\u0107im instalacijama Prometheusa. Drugi cilj je bio jednostavna upotreba s minimalnom barijerom ulaska. Sve ovisnosti trebaju biti lako zadovoljene kako za male, tako i za velike korisnike, \u0161to tako\u0111er podrazumijeva neznatnu osnovnu cijenu.<\/p>\n

Arhitektura Thanosa<\/h2>\n

\nNakon \u0161to su u prethodnom odjeljku navedeni na\u0161i ciljevi, ajmo raditi na njima i vidjeti kako Thanos rje\u0161ava ove probleme.<\/p>\n

Globalni prikaz<\/h4>\n

\nDa bismo dobili globalni pregled iznad postoje\u0107ih instanci Prometheusa, moramo povezati jedinstvenu ulaznu to\u010dku zahtjeva sa svim serverima. To upravo \u010dini komponenta Thanos. Sidecar<\/a><\/noindex>. Raspore\u0111uje se pored svakog servera Prometheus i djeluje kao proxy, opslu\u017euju\u0107i lokalne podatke Prometheus putem gRPC su\u010delja Store API, koje omogu\u0107ava odabir vremenskih serija podataka prema oznakama i vremenskom rasponu.<\/p>\n

S druge strane nalazi se horizontalno skalabilna komponenta Querier bez stanja, koja radi malo vi\u0161e od jednostavnog odgovaranja na zahtjeve PromQL putem standardnog Prometheus HTTP API. Komponente Querier, Sidecar i drugi Thanos komuniciraju putem gossip protokola.<\/a><\/noindex>.<\/p>\n

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

    \n
  1. Querier, prilikom primanja zahtjeva, povezuje se s odgovaraju\u0107im serverom Store API, odnosno s na\u0161im Sidecar-ima, i dobiva vremenske serije podataka s odgovaraju\u0107ih Prometheus servera.<\/li>\n
  2. Nakon toga spaja odgovore i izvr\u0161ava PromQL upit. Querier mo\u017ee spajati kako nepoklapaju\u0107e podatke, tako i duplicirane podatke s HA servera Prometheus.<\/li>\n<\/ol>\n

    \nTo rje\u0161ava najve\u0107i dio na\u0161e zagonetke \u2014 spajanje podataka s izoliranih servera Prometheus u jedinstveni prikaz. U stvari, Thanos se mo\u017ee koristiti samo zbog ove mogu\u0107nosti. Nema potrebe za promjenama na postoje\u0107im Prometheus serverima!<\/p>\n

    Neograni\u010deno vrijeme pohrane!<\/h4>\n

    \nMe\u0111utim, prije ili kasnije, \u017eeljet \u0107emo pohraniti podatke koji izlaze izvan uobi\u010dajenog vremena pohrane Prometheus. Za pohranu povijesnih podataka odabrali smo objektno skladi\u0161te. Ono je \u0161iroko dostupno u bilo kojem oblaku, kao i u lokalnim podatkovnim centrima, i vrlo je ekonomski isplativo. Osim toga, gotovo svako objektno skladi\u0161te dostupno je putem dobro poznatog S3 API.<\/p>\n

    Prometheus zapisuje podatke iz radne memorije na disk otprilike svaka dva sata. Blok pohranjenih podataka sadr\u017ei sve podatke za fiksni vremenski interval i nepromjenjiv je. To je vrlo zgodno, jer Thanos Sidecar mo\u017ee jednostavno pregledati katalog podataka Prometheus, a kako se novi blokovi pojavljuju, u\u010ditavati ih u ba\u010dve objektne pohrane.<\/p>\n

    \"Thanos
    \n
    \nU\u010ditavanje u objektno skladi\u0161te odmah nakon zapisivanja na disk tako\u0111er omogu\u0107ava zadr\u017eavanje jednostavnosti \u201cscrapera\u201d (Prometheus i Thanos Sidecar). \u0160to pojednostavljuje odr\u017eavanje, tro\u0161kove i dizajn sustava.<\/p>\n

    Kao \u0161to vidite, backup podataka se ostvaruje vrlo jednostavno. No, \u0161to je s upitima podacima u objektnoj pohrani?<\/p>\n

    Thanos Store komponenta djeluje kao proxy za dohva\u0107anje podataka iz objektne pohrane. Poput Thanos Sidecara, sudjeluje u gossip klasteru i implementira Store API. Tako postoje\u0107i Querieri mogu gledati na njega kao Sidecar, kao jo\u0161 jedan izvor vremenskih serija podataka \u2014 nije potrebno nikakvo posebno pode\u0161avanje.<\/p>\n

    \"Thanos
    \n
    \nBlokovi vremenskih serija podataka se sastoje od nekoliko velikih datoteka. Dohva\u0107anje po zahtjevu bi bilo prili\u010dno neefikasno, a lokalno ke\u0161iranje bi zahtijevalo ogromnu memoriju i diskovni prostor.<\/p>\n

    Umjesto toga, Store Gateway zna kako upravljati formatom pohrane Prometheusa. Zahvaljuju\u0107i inteligentnom planerima upita i ke\u0161iranju samo potrebnih indeksnih dijelova blokova, postalo je mogu\u0107e smanjiti slo\u017eene upite na minimalan broj HTTP zahtjeva prema datotekama objektne pohrane. Tako je mogu\u0107e smanjiti broj zahtjeva za \u010detiri do \u0161est redoslijeda i posti\u0107i vrijeme odgovora koje je u cjelini te\u0161ko razlikovati od zahtjeva za podacima na lokalnom SSD-u.<\/p>\n

    \"Thanos
    \n
    \nKao \u0161to je prikazano na gornjem dijagramu, Thanos Querier zna\u010dajno smanjuje tro\u0161kove za jedan zahtjev za podacima u objektnoj pohrani, koriste\u0107i format pohrane Prometheusa i grupiraju\u0107i povezane podatke blizu sebe. Koriste\u0107i ovaj pristup, mo\u017eemo spojiti mno\u0161tvo pojedina\u010dnih zahtjeva u minimalan broj bulk operacija.<\/p>\n

    Kompaktiranje i downsampling<\/h4>\n

    \nNakon \u0161to je novi blok vremenskih serija podataka uspje\u0161no u\u010ditan u objektno skladi\u0161te, tretiramo ga kao \"historijske\" podatke koji su odmah dostupni putem Store Gateway-a.<\/p>\n

    Me\u0111utim, nakon nekog vremena, blokovi iz jednog izvora (Prometheus s Sidecarom) se kumuliraju i vi\u0161e ne koriste sav potencijal indeksiranja. Da bismo rije\u0161ili ovaj problem, uveli smo jo\u0161 jednu komponentu pod nazivom Compactor. Ona jednostavno primjenjuje lokalni mehanizam kompresije Prometheusa na povijesne podatke u objektnoj pohrani i mo\u017ee se pokrenuti kao jednostavna periodi\u010dna batch zada\u0107a.<\/p>\n

    \"Thanos
    \n
    \nZahvaljuju\u0107i u\u010dinkovitoj kompresiji, zahtjev za pohranu tijekom du\u017eeg vremenskog razdoblja ne predstavlja problem s aspekta veli\u010dine podataka. Me\u0111utim, potencijalni tro\u0161ak dekompresije milijarde vrijednosti i njihovo propu\u0161tanje kroz obradu zahtjeva neizbje\u017eno \u0107e dovesti do o\u0161trog pove\u0107anja vremena izvr\u0161enja zahtjeva. S druge strane, budu\u0107i da na svaki piksel ekrana dolazi stotine to\u010daka podataka, postaje nemogu\u0107e \u010dak ni vizualizirati podatke u punoj rezoluciji. Stoga, downsampling nije samo mogu\u0107, ve\u0107 ne\u0107e dovesti do zna\u010dajnog gubitka to\u010dnosti. <\/p>\n

    \"Thanos
    \n
    \nZa downsampling podataka, Compactor neprekidno agregira podatke s rezolucijom od pet minuta i jednog sata. Za svaki neobraden fragment, kodiran uz pomo\u0107 TSDB XOR kompresije, pohranjuju se razli\u010dite vrste agregiranih podataka, poput min, max ili sum za jedan blok. To omogu\u0107uje Querieru da automatski odabere agregat koji odgovara danom PromQL zahtjevu. <\/p>\n

    Za kori\u0161tenje podataka s ni\u017eom precizno\u0161\u0107u korisniku nije potrebna nikakva posebna konfiguracija. Querier automatski prelazi izme\u0111u razli\u010ditih rezolucija i neobra\u0111enih podataka dok korisnik pove\u0107ava ili smanjuje zoom. Ako se \u017eeli, korisnik mo\u017ee izravno upravljati tim putem parametra \u201cstep\u201d u zahtjevu. <\/p>\n

    Budu\u0107i da je tro\u0161ak pohrane jednog GB mali, Thanos po defaultu pohranjuje izvorne podatke, podatke s rezolucijom od pet minuta i jednog sata. Nema potrebe za brisanjem izvornih podataka.<\/p>\n

    Recording pravila<\/h2>\n

    \n\u010cak i s Thanos recording pravilima predstavljaju bitan dio stacka za nadzor. Smanjuju slo\u017eenost, ka\u0161njenje i tro\u0161ak zahtjeva. Tako\u0111er su zgodni korisnicima za dobivanje agregiranih podataka o metrikama. Thanos se temelji na standardnim instancama Prometheusa, stoga je sasvim prihvatljivo pohranjivati recording i alerting pravila na postoje\u0107em Prometheus serveru. Me\u0111utim, u nekim slu\u010dajevima to mo\u017ee biti nedovoljno:<\/p>\n