Straipsnio vertimas buvo parengtas specialiai kurso studentams .
yra programinės įrangos kūrėjas, fanatikas ir problemų sprendimas. Jis taip pat yra „Prometheus“ prižiūrėtojas ir „Kubernetes SIG“ instrumentų įkūrėjas. Anksčiau jis buvo „SoundCloud“ gamybos inžinierius ir vadovavo „CoreOS“ stebėjimo komandai. Šiuo metu dirba Google.
- Improbable infrastruktūros inžinierius. Jis domisi naujomis technologijomis ir paskirstytų sistemų problemomis. Jis turi žemo lygio programavimo patirtį „Intel“, bendradarbio patirtį „Mesos“ ir pasaulinės klasės SRE gamybos patirtį „Improbable“. Skirta tobulinti mikro paslaugų pasaulį. Trys jo meilės: Golangas, atvirasis kodas ir tinklinis.
Žvelgdami į mūsų pavyzdinį produktą SpatialOS, galite spėti, kad Improbable reikalinga labai dinamiška, pasaulinio masto debesų infrastruktūra su daugybe Kubernetes grupių. Vieni pirmųjų pradėjome naudoti stebėjimo sistemą . „Prometheus“ gali stebėti milijonus metrikų realiuoju laiku ir turi galingą užklausų kalbą, leidžiančią išgauti reikiamą informaciją.
Prometheus paprastumas ir patikimumas yra vienas pagrindinių jo privalumų. Tačiau peržengę tam tikrą mastą susidūrėme su keliais trūkumais. Norėdami išspręsti šias problemas, sukūrėme yra atviro kodo projektas, sukurtas Improbable, siekiant sklandžiai paversti esamas Prometheus grupes į vieną stebėjimo sistemą su neribota istorinių duomenų saugykla. „Thanos“ galima rasti „Github“. .
Mūsų tikslai su Thanosu
Tam tikru mastu iškyla problemų, kurios viršija vanilės Prometėjo galimybes. Kaip patikimai ir ekonomiškai saugoti istorinių duomenų petabaitus? Ar tai galima padaryti nepažeidžiant reakcijos laiko? Ar galima pasiekti visas metrikas skirtinguose Prometheus serveriuose su viena API užklausa? Ar yra koks nors būdas sujungti pakartotinius duomenis, surinktus naudojant Prometheus HA?
Norėdami išspręsti šias problemas, sukūrėme „Thanos“. Tolesniuose skyriuose aprašoma, kaip sprendėme šias problemas, ir paaiškinami mūsų tikslai.
Duomenų užklausa iš kelių „Prometheus“ egzempliorių (visuotinė užklausa)
„Prometheus“ siūlo funkcinį požiūrį į smulkinimą. Netgi vienas „Prometheus“ serveris suteikia pakankamai mastelio, kad beveik visais naudojimo atvejais vartotojai būtų išlaisvinti nuo sudėtingo horizontalaus dalijimosi.
Nors tai puikus diegimo modelis, dažnai reikia pasiekti duomenis skirtinguose Prometheus serveriuose per vieną API arba vartotojo sąsają – visuotinį vaizdą. Žinoma, viename Grafana skydelyje galima rodyti kelias užklausas, tačiau kiekviena užklausa gali būti vykdoma tik viename Prometheus serveryje. Kita vertus, naudodami „Thanos“ galite pateikti užklausas ir kaupti duomenis iš kelių „Prometheus“ serverių, nes jie visi pasiekiami iš vieno galutinio taško.
Anksčiau norėdami gauti visuotinį vaizdą Improbable, savo Prometheus egzempliorius suskirstėme į kelių lygių . Tai reiškė, kad reikia sukurti vieną Prometheus meta serverį, kuris renka kai kurias metrikas iš kiekvieno lapų serverio.
Šis požiūris pasirodė problemiškas. Dėl to susidarė sudėtingesnės konfigūracijos, buvo pridėtas papildomas galimas gedimo taškas ir taikomos sudėtingos taisyklės, užtikrinančios, kad susietasis galutinis taškas gautų tik tuos duomenis, kurių jam reikia. Be to, tokio tipo susiejimas neleidžia gauti tikro pasaulinio vaizdo, nes ne visi duomenys pasiekiami iš vienos API užklausos.
Su tuo glaudžiai susijęs vieningas didelio prieinamumo (HA) Prometheus serveriuose surinktų duomenų vaizdas. „Prometheus“ HA modelis savarankiškai renka duomenis du kartus, o tai yra taip paprasta, kad paprasčiau ir negali būti. Tačiau būtų daug patogiau naudoti abiejų srautų kombinuotą ir pašalintą vaizdą.
Žinoma, reikia labai prieinamų Prometheus serverių. „Improbable“ labai rimtai žiūri į kas minutę atliekamų duomenų stebėjimą, tačiau vienas „Prometheus“ egzempliorius klasteryje yra vienintelis gedimo taškas. Bet kokia konfigūracijos klaida arba aparatinės įrangos gedimas gali sukelti svarbių duomenų praradimą. Netgi paprastas diegimas gali sukelti nedidelių metrikos rinkimo trikdžių, nes paleidimai iš naujo gali būti žymiai ilgesni nei nuskaitymo intervalas.
Patikimas istorinių duomenų saugojimas
Pigus, greitas, ilgalaikis metrikų saugojimas yra mūsų svajonė (dalija dauguma Prometheus vartotojų). Neįtikėtina, mes buvome priversti konfigūruoti metrikos saugojimo laikotarpį iki devynių dienų (Prometheus 1.8). Tai prideda akivaizdžių ribų, kiek toli galime žiūrėti atgal.
Šiuo atžvilgiu „Prometheus 2.0“ pagerėjo, nes laiko eilučių skaičius nebeturi įtakos bendram serverio veikimui (žr. ). Tačiau „Prometheus“ saugo duomenis vietiniame diske. Nors labai efektyvus duomenų glaudinimas gali žymiai sumažinti vietinio SSD naudojimą, galiausiai vis dar yra apribojimas, kiek istorinių duomenų galima saugoti.
Be to, Improbable mums rūpi patikimumas, paprastumas ir kaina. Didelius vietinius diskus sunkiau valdyti ir kurti atsargines kopijas. Jie kainuoja daugiau ir reikalauja daugiau atsarginių įrankių, todėl nereikalingas sudėtingumas.
Sumažinti atranką
Pradėję dirbti su istoriniais duomenimis, supratome, kad yra esminių sunkumų, susijusių su big-O, dėl kurių užklausos lėtėja ir lėtėja, kai dirbame su savaičių, mėnesių ir metų duomenimis.
Standartinis šios problemos sprendimas būtų (downsampling) – signalo diskretizavimo dažnio mažinimas. Sumažinę atranką galime „sumažinti“ iki didesnio laiko intervalo ir išlaikyti tą patį mėginių skaičių, kad užklausos būtų atsakingos.
Senų duomenų atrinkimas yra neišvengiamas bet kokio ilgalaikio saugojimo sprendimo reikalavimas ir nepatenka į vanilinio Prometheus taikymo sritį.
Papildomi tikslai
Vienas iš pirminių „Thanos“ projekto tikslų buvo sklandžiai integruotis su bet kokiais esamais „Prometheus“ įrenginiais. Antrasis tikslas buvo paprastas valdymas su minimaliomis kliūtimis patekti į rinką. Bet kokios priklausomybės turėtų būti lengvai patenkintos tiek mažiems, tiek dideliems vartotojams, o tai taip pat reiškia mažą bazinę kainą.
Thanos architektūra
Išvardinę savo tikslus ankstesniame skyriuje, pabandykime juos pasiekti ir pažiūrėkime, kaip Thanos išsprendžia šias problemas.
Globalus vaizdas
Norėdami gauti bendrą vaizdą apie esamus Prometheus egzempliorius, turime susieti vieną užklausos įvesties tašką su visais serveriais. Būtent tai daro Thanos komponentas. . Jis įdiegtas šalia kiekvieno Prometheus serverio ir veikia kaip tarpinis serveris, aptarnaujantis vietinius Prometheus duomenis per gRPC Store API, leidžiantis gauti laiko eilučių duomenis pagal žymą ir laiko intervalą.
Kitoje pusėje yra išplėstinis, be būsenos „Querier“ komponentas, kuris ne tik atsako į „PromQL“ užklausas per standartinę „Prometheus“ HTTP API. „Querier“, „Sidecar“ ir kiti „Thanos“ komponentai bendrauja per .
- Querier, gavęs užklausą, prisijungia prie atitinkamo Store API serverio, tai yra prie mūsų Sidecars ir gauna laiko eilučių duomenis iš atitinkamų Prometheus serverių.
- Po to jis sujungia atsakymus ir vykdo PromQL užklausą. „Querier“ gali sujungti ir atskirtus duomenis, ir pasikartojančius duomenis iš „Prometheus HA“ serverių.
Tai išsprendžia pagrindinę mūsų galvosūkio dalį – sujungiame duomenis iš izoliuotų Prometheus serverių į vieną vaizdą. Tiesą sakant, „Thanos“ gali būti naudojamas tik šiai funkcijai. Esamuose Prometheus serveriuose keisti nereikia!
Neribotas galiojimo laikas!
Tačiau anksčiau ar vėliau mes norėsime saugoti duomenis ilgiau nei įprastas Prometheus saugojimo laikas. Istoriniams duomenims saugoti pasirinkome objektų saugyklą. Jis yra plačiai prieinamas bet kuriame debesyje, taip pat vietiniuose duomenų centruose ir yra labai ekonomiškas. Be to, beveik bet kokia objektų saugykla pasiekiama per gerai žinomą S3 API.
Prometėjas įrašo duomenis iš RAM į diską maždaug kas dvi valandas. Išsaugotame duomenų bloke yra visi duomenys tam tikrą laiką ir jis yra nekintamas. Tai labai patogu, nes „Thanos Sidecar“ gali tiesiog pažvelgti į „Prometheus“ duomenų katalogą ir, atsiradus naujiems blokams, įkelti juos į objektų saugojimo kibirus.
Įkėlimas į objektų saugyklą iš karto po įrašymo į diską taip pat leidžia išlaikyti grandiklio (Prometheus ir Thanos Sidecar) paprastumą. Tai supaprastina palaikymą, išlaidas ir sistemos projektavimą.
Kaip matote, duomenų atsarginė kopija yra labai paprasta. Bet kaip su duomenų užklausa objektų saugykloje?
„Thanos Store“ komponentas veikia kaip tarpinis serveris duomenims iš objektų saugyklos nuskaityti. Kaip ir „Thanos Sidecar“, jis dalyvauja paskalų grupėje ir diegia „Store API“. Tokiu būdu esama užklausa gali ją traktuoti kaip šoninį vežimėlį, kaip kitą laiko eilučių duomenų šaltinį – nereikia jokios specialios konfigūracijos.
Laiko eilučių duomenų blokai susideda iš kelių didelių failų. Jų įkėlimas pagal poreikį būtų gana neefektyvus, o talpyklos saugojimas vietoje pareikalautų daug atminties ir vietos diske.
Vietoj to, „Store Gateway“ žino, kaip elgtis su „Prometheus“ saugojimo formatu. Dėl išmaniojo užklausų planuoklio ir tik būtinų blokų indekso dalių talpyklos saugojimo galima sumažinti sudėtingas užklausas iki minimalaus HTTP užklausų skaičiaus objektų saugojimo failams. Tokiu būdu galite sumažinti užklausų skaičių nuo keturių iki šešių dydžių ir pasiekti atsakymo laiką, kurį paprastai sunku atskirti nuo užklausų į duomenis vietiniame SSD.
Kaip parodyta aukščiau esančioje diagramoje, „Thanos Querier“ žymiai sumažina objektų saugojimo duomenų užklausos kainą, naudodama „Prometheus“ saugojimo formatą ir padėdamas susijusius duomenis greta. Naudodami šį metodą galime sujungti daug pavienių užklausų į minimalų masinių operacijų skaičių.
Sutankinimas ir sumažinimas
Kai naujas laiko eilučių duomenų blokas sėkmingai įkeliamas į objektų saugyklą, mes traktuojame jį kaip „istorinius“ duomenis, kurie iš karto pasiekiami per „Store Gateway“.
Tačiau po kurio laiko blokai iš vieno šaltinio („Prometheus with Sidecar“) kaupiasi ir nebeišnaudoja viso indeksavimo potencialo. Norėdami išspręsti šią problemą, pristatėme kitą komponentą, vadinamą Compactor. Jis tiesiog pritaiko „Prometheus“ vietinį tankinimo variklį istoriniams duomenims objektų saugykloje ir gali būti paleistas kaip paprastas periodinis paketinis darbas.
Dėl veiksmingo glaudinimo ilgą laiką užklausos dėl saugyklos nesukelia problemų dėl duomenų dydžio. Tačiau galimos išlaidos, susijusios su milijardo verčių išpakavimu ir paleidimu per užklausų procesorių, neišvengiamai smarkiai padidins užklausos vykdymo laiką. Kita vertus, kadangi ekrane yra šimtai duomenų taškų viename pikselyje, tampa neįmanoma net vizualizuoti duomenų visa raiška. Taigi mėginių mažinimas yra ne tik įmanomas, bet ir nesukels pastebimo tikslumo praradimo.
Norėdami sumažinti duomenų atranką, Compactor nuolat kaupia duomenis penkių minučių ir vienos valandos skiriamąja geba. Kiekvienam neapdorotam gabalui, užkoduotam naudojant TSDB XOR glaudinimą, saugomi skirtingų tipų suvestiniai duomenys, pvz., min, max arba suma vienam blokui. Tai leidžia „Querier“ automatiškai pasirinkti agregatą, tinkamą tam tikrai PromQL užklausai.
Kad vartotojas naudotų mažesnio tikslumo duomenis, specialios konfigūracijos nereikia. „Querier“ automatiškai perjungia skirtingą skiriamąją gebą ir neapdorotus duomenis, kai vartotojas priartina ir tolina. Jei pageidaujama, vartotojas gali tai valdyti tiesiogiai per užklausos parametrą „step“.
Kadangi vieno GB saugojimo kaina yra maža, pagal numatytuosius nustatymus „Thanos“ saugo neapdorotus duomenis, penkių minučių ir vienos valandos skiriamosios gebos duomenis. Pradinių duomenų ištrinti nereikia.
Įrašymo taisyklės
Net naudojant „Thanos“, įrašymo taisyklės yra esminė stebėjimo rinkinio dalis. Jie sumažina užklausų sudėtingumą, delsą ir kainą. Jie taip pat yra patogūs vartotojams gauti apibendrintus duomenis pagal metriką. „Thanos“ yra pagrįsta vaniliniais „Prometheus“ egzemplioriais, todėl visiškai priimtina įrašymo ir įspėjimų taisykles saugoti esamame „Prometheus“ serveryje. Tačiau kai kuriais atvejais to gali nepakakti:
- Visuotinis įspėjimas ir taisyklė (pavyzdžiui, įspėjimas, kai paslauga neveikia daugiau nei dviejuose iš trijų grupių).
- Duomenų už vietinės saugyklos ribų taisyklė.
- Noras saugoti visas taisykles ir įspėjimus vienoje vietoje.
Visais šiais atvejais „Thanos“ turi atskirą komponentą, vadinamą „Ruler“, kuris apskaičiuoja taisyklę ir įspėjimą per „Thanos Queries“. Teikdamas gerai žinomą StoreAPI, užklausos mazgas gali pasiekti naujai apskaičiuotą metriką. Vėliau jie taip pat saugomi objektų saugykloje ir pasiekiami per „Store Gateway“.
Thanoso galia
Thanos yra pakankamai lankstus, kad būtų pritaikytas pagal jūsų poreikius. Tai ypač naudinga migruojant iš paprasto Prometėjo. Greitai apibendrinkime, ką sužinojome apie „Thanos“ komponentus, pateikdami trumpą pavyzdį. Štai kaip perkelti savo vanilinį „Prometheus“ į „neribotos metrikos saugyklos“ pasaulį:
- Pridėkite „Thanos Sidecar“ prie savo „Prometheus“ serverių, pavyzdžiui, „Kubernetes“ dėžutėje esantį konteinerį prie šoninio priekabos.
- Įdiekite kelias „Thanos Querier“ kopijas, kad galėtumėte peržiūrėti duomenis. Šiame etape nesunku užmegzti apkalbas tarp Scraper ir Querier. Norėdami patikrinti komponentų sąveiką, naudokite metriką „thanos_cluster_members“.
Tik šių dviejų žingsnių pakanka, kad būtų pateiktas pasaulinis vaizdas ir sklandžiai pašalintumėte duomenų dubliavimą iš galimų Prometheus HA kopijų! Tiesiog prijunkite savo prietaisų skydelius prie Querier HTTP galutinio taško arba naudokite tiesiogiai Thanos vartotojo sąsają.
Tačiau, jei jums reikia atsarginės metrikos kopijos ir ilgalaikio saugojimo, turėsite atlikti dar tris veiksmus:
- Sukurkite AWS S3 arba GCS kibirą. Konfigūruokite „Sidecar“ kopijuoti duomenis į šiuos segmentus. Dabar galima sumažinti vietos duomenų saugyklą.
- Įdiekite „Store Gateway“ ir prijunkite jį prie esamos paskalų grupės. Dabar galite pateikti užklausą dėl atsarginių duomenų!
- Įdiekite Compactor, kad padidintumėte užklausos efektyvumą ilgą laiką, naudodami sutankinimą ir sumažinimą.
Jei norite sužinoti daugiau, nedvejodami peržiūrėkite mūsų и !
Vos penkiais žingsniais „Prometheus“ pavertėme patikima stebėjimo sistema su visuotiniu vaizdu, neribotu saugojimo laiku ir galimu dideliu metrikos prieinamumu.
Ištraukite užklausą: mums reikia jūsų!
nuo pat pradžių buvo atvirojo kodo projektas. Sklandi integracija su „Prometheus“ ir galimybė naudoti tik dalį „Thanos“ daro jį puikiu pasirinkimu norint be vargo keisti stebėjimo sistemos mastelį.
Visada laukiame „GitHub Pull“ užklausų ir problemų. Tuo tarpu nedvejodami susisiekite su mumis per „Github Issues“ arba „slack“.Jei turite klausimų ar atsiliepimų arba norite pasidalinti savo patirtimi naudojant jį! Jei jums patinka tai, ką darome Improbable, nedvejodami susisiekite su mumis - !
Šaltinis: www.habr.com