Prijevod članka pripremljen je posebno za studente predmeta .
je programer softvera, Go fanatik i rješavanje problema. On je također održavatelj Prometheusa i suosnivač Kubernetes SIG instrumentacije. U prošlosti je bio inženjer produkcije u SoundCloud-u i vodio je tim za praćenje u CoreOS-u. Trenutno radi u Google-u.
- Inženjer infrastrukture u kompaniji Improbable. Voli nove tehnologije i probleme distribuiranih sistema. Ima iskustvo programiranja niskog nivoa u Intelu, iskustvo saradnika u Mesosu i iskustvo u proizvodnji SRE svjetske klase u Improbableu. Bavi se unapređenjem svijeta mikrousluga. Njegove tri ljubavi su Golang, open source i odbojka.
Gledajući naš vodeći proizvod SpatialOS, možete pretpostaviti da je Improbableu potrebna vrlo dinamična globalna cloud infrastruktura sa desetinama Kubernetes klastera. Među prvima smo počeli da koristimo sistem za praćenje . Prometheus je sposoban da prati milione metrika u realnom vremenu i dolazi sa moćnim jezikom upita za izdvajanje informacija koje su vam potrebne.
Jednostavnost i pouzdanost Prometheusa je jedna od njegovih glavnih prednosti. Međutim, nakon što smo prošli određenu skalu, naišli smo na nekoliko nedostataka. Da bismo riješili ove probleme, razvili smo se je projekat otvorenog koda koji je kreirao Improbable da neprimetno transformiše postojeće Prometheus klastere u jedan sistem za praćenje sa neograničenim skladištem istorijskih podataka. Thanos je dostupan na Githubu .
Naši ciljevi sa Tanosom
U određenom obimu javljaju se problemi koji su izvan mogućnosti Vanilla Prometheusa. Kako bezbedno i ekonomično pohraniti petabajte istorijskih podataka? Može li se to učiniti bez ugrožavanja vremena odgovora na upit? Da li je moguće pristupiti svim metrikama koje se nalaze na različitim Prometheus serverima sa jednim API zahtjevom? Postoji li neki način da se spoje replicirani podaci prikupljeni sa Prometheus HA?
Da bismo riješili ove probleme, kreirali smo Thanos. Sljedeći odjeljci opisuju kako smo pristupili ovim pitanjima i objašnjavaju ciljeve kojima smo težili.
Upitajte podatke iz više Prometheus instanci (globalni upit)
Prometheus nudi funkcionalan pristup shardingu. Čak i jedan Prometheus server pruža dovoljnu skalabilnost da oslobodi korisnike od složenosti horizontalnog dijeljenja u gotovo svim slučajevima upotrebe.
Iako je ovo odličan model implementacije, često je potrebno pristupiti podacima na različitim Prometheus serverima preko jednog API-ja ili korisničkog sučelja – globalnog pogleda. Naravno, moguće je prikazati više zahtjeva u jednom Grafana panelu, ali svaki zahtjev može biti upućen samo jednom Prometheus serveru. S druge strane, uz Thanos možete upiti i agregirati podatke sa više Prometheus servera jer su svi dostupni sa iste krajnje tačke.
Ranije, da bismo dobili globalni pogled na Improbable, organizirali smo naše Prometheus instance u više nivoa . To je značilo stvaranje jednog Prometheus meta servera koji prikuplja dio metrike sa svakog servera "lista".
Ovaj pristup se pokazao problematičnim. To je rezultiralo složenijom konfiguracijom, dodavanjem dodatne potencijalne tačke kvara i primjenom složenih pravila kako bi se federalnoj krajnjoj točki pružili samo podaci koji su joj potrebni. Osim toga, ova vrsta federacije vam ne dozvoljava da dobijete pravi globalni pogled, jer nisu svi podaci dostupni iz jednog API zahtjeva.
Usko povezan s ovim je jedan prikaz podataka prikupljenih na Prometheus serverima visoke dostupnosti (HA). Prometheus HA model samostalno prikuplja podatke dva puta, što je najjednostavnije. Međutim, korištenje kombiniranog i dedupliciranog prikaza oba toka bilo bi mnogo zgodnije.
Naravno, postoji potreba za visoko dostupnim Prometheus serverima. U Improbableu, zaista smo ozbiljni u pogledu praćenja podataka svakog minuta, ali imati jednu Prometheus instancu po klasteru je jedina tačka neuspjeha. Svaka greška u konfiguraciji ili hardverski kvar može potencijalno dovesti do gubitka važnih podataka. Čak i jednostavna implementacija može rezultirati malim problemima u prikupljanju metrika jer ponovno pokretanje može biti znatno duže od intervala scrapinga.
Pouzdano skladištenje istorijskih podataka
Jeftino, brzo i dugoročno skladištenje metrike je naš san (koji dijeli većina korisnika Prometheusa). U Improbable smo bili primorani da postavimo period zadržavanja metrike na devet dana (za Prometheus 1.8). Ovo dodaje očigledna ograničenja koliko daleko možemo gledati unazad.
Prometheus 2.0 je poboljšan u tom pogledu, pošto broj vremenskih serija više ne utiče na ukupne performanse servera (vidi dole). ). Međutim, Prometheus pohranjuje podatke na lokalni disk. Iako visoko efikasna kompresija podataka može uvelike smanjiti upotrebu lokalnog SSD-a, u konačnici postoji ograničenje količine povijesnih podataka koji se mogu pohraniti.
Osim toga, u Improbableu brinemo o pouzdanosti, jednostavnosti i cijeni. Velike lokalne diskove je teže održavati i praviti sigurnosne kopije. Oni koštaju više i zahtijevaju više alata za pravljenje rezervnih kopija, što rezultira nepotrebnom složenošću.
Downsampling
Čim smo počeli da radimo sa istorijskim podacima, shvatili smo da postoje fundamentalne poteškoće sa velikim O zbog kojih upiti postaju sve sporiji i sporiji ako radimo sa podacima nedeljama, mesecima i godinama.
Standardno rješenje ovog problema bi bilo (downsampling) - smanjenje frekvencije uzorkovanja signala. Sa smanjenjem uzorkovanja, možemo "smanjiti" na veći vremenski raspon i zadržati isti broj uzoraka, što će naše upite održavati odgovornim.
Smanjenje uzorkovanja starih podataka je neizbježan zahtjev svakog rješenja za dugotrajno skladištenje i nadilazi vanilla Prometheus.
Dodatni ciljevi
Jedan od prvobitnih ciljeva Thanos projekta bila je besprijekorna integracija sa bilo kojom postojećom instalacijom Prometheusa. Drugi cilj je bila jednostavna operacija sa minimalnom barijerom za ulazak. Bilo kakve zavisnosti treba lako zadovoljiti i za male i za velike korisnike, što takođe podrazumeva zanemarljiv osnovni trošak.
Thanos arhitektura
Nakon što smo naveli naše ciljeve u prethodnom dijelu, poradimo na njima i vidimo kako Thanos rješava ove probleme.
globalni pogled
Da bismo dobili globalni pogled na postojeće Prometheus instance, moramo povezati jednu ulaznu tačku zahtjeva sa svim serverima. To je upravo ono što Thanos komponenta radi. . Postavljen je pored svakog Prometheus servera i djeluje kao proxy koji opslužuje lokalne Prometheus podatke preko gRPC Store API-ja, koji vam omogućava da odaberete podatke vremenske serije prema vremenskoj oznaci i vremenskom rasponu.
S druge strane je horizontalno skalabilna, Querier komponenta bez stanja koja radi samo nešto više od odgovora na PromQL upite kroz standardni Prometheus HTTP API. Komponente Querier, Sidecar i drugi Thanos komuniciraju putem .
- Querier, po prijemu zahtjeva, povezuje se na odgovarajući Store API server, odnosno na naše Sidecars, i prima podatke vremenske serije od odgovarajućih Prometheus servera.
- Nakon toga kombinuje odgovore i izvršava PromQL upit na njima. Querier može agregirati podatke koji se ne preklapaju i duplicirane podatke sa Prometheus HA servera.
Ovo rješava glavni dio naše slagalice - kombiniranje podataka sa izolovanih Prometheus servera u jedan prikaz. Zapravo, Thanos se može iskoristiti samo za ovu priliku. Postojeći Prometheus serveri ne zahtijevaju nikakve modifikacije!
Neograničeno vrijeme skladištenja!
Međutim, prije ili kasnije poželjet ćemo pohraniti podatke koji prelaze uobičajeno vrijeme zadržavanja Prometheusa. Za pohranjivanje historijskih podataka odabrali smo pohranu objekata. Široko je dostupan u bilo kojem oblaku, kao iu lokalnim podatkovnim centrima i vrlo je isplativ. Osim toga, gotovo svaki objekt za pohranu dostupan je putem dobro poznatog S3 API-ja.
Prometheus upisuje podatke iz RAM-a na disk otprilike svaka dva sata. Pohranjeni blok podataka sadrži sve podatke za fiksni vremenski period i nepromjenjiv je. Ovo je vrlo zgodno, jer Thanos Sidecar može jednostavno pogledati Prometheusov direktorij podataka i, kako se pojavljuju novi blokovi, učitati ih u kante za pohranu objekata.
Učitavanje u pohranu objekata odmah nakon upisivanja na disk također održava jednostavnost "grebača" (Prometheus i Thanos Sidecar) netaknutom. Ovo pojednostavljuje održavanje, troškove i dizajn sistema.
Kao što vidite, sigurnosna kopija podataka je vrlo jednostavna za implementaciju. Ali šta je sa upitom podataka u skladištu objekata?
Komponenta Thanos Store djeluje kao proxy za dobivanje podataka iz skladišta objekata. Kao i Thanos Sidecar, on učestvuje u klasteru tračeva i implementira Store API. Prema tome, postojeći Queriers ga mogu tretirati kao Sidecar, kao još jedan izvor podataka vremenske serije - nije potrebna posebna konfiguracija.
Blokovi podataka vremenskih serija sastoje se od nekoliko velikih datoteka. Njihovo učitavanje na zahtjev bi bilo prilično neefikasno, a njihovo lokalno keširanje zahtijevalo bi ogromnu količinu memorije i prostora na disku.
Umjesto toga, Store Gateway zna kako da rukuje Prometheus formatom za skladištenje. Zahvaljujući pametnom planeru upita i keširanju samo neophodnih indeksnih dijelova blokova, postalo je moguće svesti složene zahtjeve na minimalni broj HTTP zahtjeva za datoteke za pohranu objekata. Tako je moguće smanjiti broj zahtjeva za četiri do šest reda veličine i postići vrijeme odgovora koje je općenito teško razlikovati od zahtjeva za podacima na lokalnom SSD-u.
Kao što je prikazano na dijagramu iznad, Thanos Querier značajno smanjuje cijenu po zahtjevu za podatke u skladištu objekata korištenjem Prometheus formata za skladištenje i postavljanjem povezanih podataka jedan pored drugog. Koristeći ovaj pristup, možemo kombinirati mnogo pojedinačnih zahtjeva u minimalan broj grupnih operacija.
Zbijanje i smanjenje uzorkovanja
Nakon što se novi blok podataka vremenske serije uspješno učita u skladište objekata, smatramo ga "povijesnim" podacima, koji su odmah dostupni preko Store Gateway-a.
Međutim, nakon nekog vremena, blokovi iz jednog izvora (Prometheus sa Sidecarom) se akumuliraju i više ne koriste puni potencijal indeksiranja. Da bismo riješili ovaj problem, uveli smo još jednu komponentu pod nazivom Compactor. Jednostavno primjenjuje lokalni Prometheus mehanizam sažimanja na historijske podatke u skladištu objekata i može se pokrenuti kao jednostavan periodični skupni posao.
Zbog efikasne kompresije, ispitivanje memorije tokom dužeg vremenskog perioda ne predstavlja problem u smislu veličine podataka. Međutim, potencijalni trošak raspakivanja milijarde vrijednosti i njihovog pokretanja kroz procesor upita neizbježno će dovesti do dramatičnog povećanja vremena izvršenja upita. S druge strane, pošto na ekranu postoje stotine tačaka podataka po pikselu, postaje nemoguće čak i prikazati podatke u punoj rezoluciji. Stoga je smanjenje uzorkovanja ne samo moguće, već neće dovesti do primjetnog gubitka tačnosti.
Za smanjenje uzorkovanja podataka, Compactor kontinuirano agregira podatke u rezoluciji od pet minuta i jednog sata. Za svaki sirovi fragment kodiran TSDB XOR kompresijom, pohranjuju se različiti tipovi agregiranih podataka, kao što su min, max ili zbroj za jedan blok. Ovo omogućava Querieru da automatski izabere agregat koji je prikladan za dati PromQL upit.
Nije potrebna posebna konfiguracija da bi korisnik koristio podatke smanjene preciznosti. Querier se automatski prebacuje između različitih rezolucija i sirovih podataka kako korisnik uvećava i umanjuje. Po želji, korisnik to može kontrolisati direktno preko parametra "korak" u zahtjevu.
Pošto je trošak skladištenja od jednog GB niski, Thanos podrazumevano sprema originalne podatke, podatke u rezoluciji od pet minuta i jednog sata. Nema potrebe za brisanjem originalnih podataka.
Pravila snimanja
Čak i sa Thanos-om, pravila snimanja su suštinski dio praćenja. Oni smanjuju složenost, kašnjenje i cijenu upita. Takođe su pogodni za korisnike da dobiju agregirane podatke prema metrikama. Thanos je baziran na vanilla instancama Prometheusa, tako da je sasvim prihvatljivo zadržati pravila snimanja i pravila upozorenja na postojećem Prometheus serveru. Međutim, u nekim slučajevima to možda neće biti dovoljno:
- Globalno upozorenje i pravilo (na primjer, upozorenje kada usluga ne radi na više od dva od tri klastera).
- Pravilo za podatke izvan lokalne memorije.
- Želja da se sva pravila i upozorenja pohrane na jednom mjestu.
Za sve ove slučajeve, Thanos uključuje zasebnu komponentu pod nazivom Ruler koja procjenjuje pravilo i upozorenje putem Thanos upita. Pružajući dobro poznati StoreAPI, čvor upita može pristupiti svježe izračunatim metrikama. Kasnije se takođe pohranjuju u skladištu objekata i stavljaju na raspolaganje preko Store Gateway-a.
Moć Tanosa
Thanos je dovoljno fleksibilan da se prilagodi vašim potrebama. Ovo je posebno korisno kada se migrira iz običnog Prometeja. Hajde da brzo pregledamo ono što smo naučili o Thanos komponentama koristeći mali primjer. Evo kako da svoj vanilin Prometheus dovedete u svijet "neograničene metričke pohrane":
- Dodajte Thanos Sidecar na svoje Prometheus servere - na primjer, susjedni kontejner u Kubernetes pod.
- Postavite više replika Thanos Querier-a za pregled podataka. U ovom trenutku, lako je postaviti trač između Scrapera i Queriera. Da biste provjerili interakciju komponenti, koristite metriku 'thanos_cluster_members'.
Ova dva koraka su dovoljna da obezbede globalni pogled i besprekornu deduplikaciju podataka iz potencijalnih Prometheus HA replika! Jednostavno povežite svoje kontrolne table sa krajnjom tačkom HTTP Queriera ili direktno koristite Thanos UI interfejs.
Međutim, ako vam je potrebna sigurnosna kopija metrike i dugotrajno zadržavanje, morate poduzeti još tri koraka:
- Kreirajte AWS S3 ili GCS korpu. Postavite Sidecar za kopiranje podataka u ove korpe. Sada možete minimizirati lokalnu pohranu podataka.
- Postavite Store Gateway i povežite ga sa postojećim klasterom tračeva. Sada možete slati zahtjeve za podatke u rezervnim kopijama!
- Implementirajte Compactor da poboljšate performanse upita tokom dugih vremenskih perioda koristeći zbijanje i smanjenje uzorkovanja.
Ako želite da saznate više, slobodno pogledajte našu и !
U samo pet koraka pretvorili smo Prometheus u robustan sistem za praćenje sa globalnim pogledom, neograničenim vremenom skladištenja i potencijalnom visokom dostupnošću metrike.
Zahtjev za povlačenjem: potrebni ste nam!
je od početka bio projekat otvorenog koda. Besprekorna integracija s Prometheusom i mogućnost korištenja samo dijela Thanosa čini ga odličnim izborom za skaliranje vašeg sistema za praćenje bez napora.
Uvijek pozdravljamo GitHub zahtjeve i probleme. U međuvremenu, slobodno nas kontaktirajte putem Github Issues ili slackako imate pitanja ili povratne informacije, ili želite podijeliti svoje iskustvo! Ako vam se sviđa ono što radimo u Improbable-u slobodno nas kontaktirajte - !
izvor: www.habr.com