Thanos - Prometheus eskalagarria

Artikuluaren itzulpena ikastaroko ikasleentzat bereziki prestatu zen "DevOps praktikak eta tresnak".

Fabian Reinartz software garatzailea da, Go fanatic eta arazoen konpontzailea da. Prometheusen mantentzailea eta Kubernetes SIG tresneriaren sortzailekidea ere bada. Iraganean, SoundCloud-en ekoizpen ingeniaria izan zen eta CoreOSeko monitorizazio taldea zuzendu zuen. Gaur egun Googlen egiten du lan.

Bartek Plotka - Improbableko Azpiegitura Ingeniaria. Teknologia berrietan eta sistema banatuen arazoetan interesatzen da. Behe-mailako programazio esperientzia du Intel-en, kolaboratzaile-esperientzia Mesos-en eta mundu mailako SRE ekoizpen esperientzia du Improbable-n. Mikrozerbitzuen mundua hobetzera dedikatua. Bere hiru maitasunak: Golang, kode irekia eta boleibola.

SpatialOS gure produktu enblematikoari erreparatuz, Improbable-k eskala globaleko hodei azpiegitura oso dinamikoa behar duela igarri dezakezu Kubernetesen dozenaka klusterrekin. Monitorizazio sistema bat erabiltzen lehenetariko bat izan ginen Prometeo. Prometheus-ek milioika metrika jarraitzeko gai da denbora errealean eta behar duzun informazioa ateratzeko aukera ematen dizun kontsulta-lengoaia indartsu batekin dator.

Prometheus-en sinpletasuna eta fidagarritasuna da bere abantaila nagusietako bat. Hala ere, eskala jakin bat gaindituta, hainbat eragozpen topatu genituen. Arazo hauek konpontzeko garatu ditugu Thanos Improbable-k sortutako kode irekiko proiektu bat da, dauden Prometheus klusterrak ezin hobeto eraldatzeko datu historikoen biltegiratze mugagabea duen monitorizazio sistema bakar batean. Thanos Github-en dago eskuragarri Hemen.

Egon eguneratuta Improbable-ren azken berriekin.

Thanosekin ditugun helburuak

Eskala jakin batean, bainila Prometheus-en gaitasunetatik at dauden arazoak sortzen dira. Nola gorde datu historikoen petabyte fidagarri eta ekonomikoki? Egin al daiteke erantzun denbora arriskuan jarri gabe? Posible al da Prometheus zerbitzari desberdinetan kokatutako metrika guztietara sartzea API eskaera bakarrarekin? Ba al dago Prometheus HA erabiliz bildutako datu errepikatuak konbinatzeko modurik?

Arazo horiei aurre egiteko, Thanos sortu dugu. Hurrengo ataletan gai horiei nola heldu genion azaltzen eta gure helburuak azaltzen dira.

Prometheus-en hainbat instantziatako datuak kontsultatzea (kontsulta globala)

Prometheus-ek zatiketaren ikuspegi funtzional bat eskaintzen du. Prometheus zerbitzari bakar batek ere eskalagarritasun nahikoa eskaintzen du erabiltzaileak zatiketa horizontalaren konplexutasunetatik askatzeko ia erabilera kasu guztietan.

Inplementazio-eredu bikaina den arren, askotan beharrezkoa da Prometheus zerbitzari desberdinetako datuak API edo UI bakar baten bidez atzitzea - ​​ikuspegi globala. Jakina, posible da hainbat kontsulta bistaratzea Grafana panel batean, baina kontsulta bakoitza Prometheus zerbitzari batean bakarrik exekutatu daiteke. Bestalde, Thanos-ekin Prometheus zerbitzari anitzetako datuak kontsultatu eta batu ditzakezu, guztiak amaiera-puntu bakar batetik eskura daitezkeelako.

Aurretik, Improbable-n ikuspegi globala lortzeko, gure Prometheus instantziak maila anitzeko moduan antolatu genituen. Federazio Hierarkikoa. Honek Prometheus meta zerbitzari bat sortzea ekarri zuen hosto zerbitzari bakoitzeko metrika batzuk biltzen dituena.

Thanos - Prometheus eskalagarria

Planteamendu hori arazotsua izan zen. Honen ondorioz, konfigurazio konplexuagoak, hutsegite-puntu potentzial gehigarri bat gehitu da eta arau konplexuak aplikatu dira, azken puntu federatuak behar dituen datuak soilik jasotzen dituela ziurtatzeko. Gainera, federazio mota honek ez dizu benetako ikuspegi globala lortzen uzten, datu guztiak ez baitaude eskuragarri API eskaera bakar batetik.

Horrekin oso lotuta dago erabilgarritasun handiko (HA) Prometheus zerbitzarietan bildutako datuen ikuspegi bateratua. Prometheus-en HA ereduak modu independentean bi aldiz biltzen ditu datuak, hain sinplea ez den errazagoa izan. Hala ere, bi korronteen ikuspegi konbinatua eta deduplicatua erabiltzea askoz erosoagoa izango litzateke.

Jakina, eskuragarri dauden Prometheus zerbitzarien beharra dago. Improbable-n, oso serio hartzen dugu minutuz minutuko datuen jarraipena, baina kluster bakoitzeko Prometheus instantzia bat izatea hutsegite puntu bakarra da. Edozein konfigurazio-erroreak edo hardware-akatsak datu garrantzitsuak galtzea ekar dezake. Inplementazio sinple batek ere eten txikiak eragin ditzake metrika-bilketan, berrabiarazteko scraping tartea baino nabarmen luzeagoak izan daitezkeelako.

Datu historikoen biltegiratze fidagarria

Biltegiratze merke, azkar eta epe luzerako metrics da gure ametsa (Prometheus-eko erabiltzaile gehienek partekatzen dute). Improbable-n, metrikak gordetzeko epea bederatzi egunetara konfiguratzera behartuta egon ginen (Prometheus 1.8rako). Horrek muga nabariak gehitzen dizkio zenbat atzera begiratu dezakegun.

Prometheus 2.0 hobetu egin da zentzu honetan, denbora serie kopuruak ez baitu zerbitzariaren errendimendu orokorrari eragiten (ikus. Prometheus 2-ri buruzko KubeCon hitzaldia). Hala ere, Prometheus-ek disko lokalean gordetzen ditu datuak. Eraginkortasun handiko datuen konpresioak tokiko SSD erabilera nabarmen murrizten badu ere, azken finean, gorde daitezkeen datu historikoen kopuruaren muga dago oraindik.

Gainera, Improbablen fidagarritasuna, sinpletasuna eta kostua zaintzen ditugu. Tokiko disko handiak zailagoak dira funtzionatzea eta babeskopia egitea. Gehiago kostatzen dira eta babeskopia-tresna gehiago behar dituzte, eta ondorioz, alferrikako konplexutasuna sortzen da.

Behe-laginketa

Datu historikoekin lanean hasi ginenean, konturatu ginen big-O-rekin oinarrizko zailtasunak daudela, eta horrek kontsultak gero eta motelagoak egiten ditu aste, hilabete eta urteen datuekin lan egiten dugun heinean.

Arazo honen konponbide estandarra litzateke azpilaginketa (downsampling) - seinalearen laginketa maiztasuna murriztea. Behe-laginketarekin, denbora-tarte handiago batera "eskalatu" dezakegu eta lagin kopuru bera mantendu, kontsultei erantzuna emanez.

Datu zaharrak txikiagotzea epe luzerako biltegiratze-irtenbide guztien ezinbesteko baldintza da eta bainila Prometheus-en esparrutik kanpo dago.

Helburu osagarriak

Thanos proiektuaren jatorrizko helburuetako bat lehendik zeuden Prometheus instalazioekin ezin hobeto integratzea zen. Bigarren helburua funtzionatzeko erraztasuna zen, sartzeko oztopo minimoekin. Edozein menpekotasun erraz ase behar da erabiltzaile txiki zein handientzat, eta horrek oinarrizko kostu txikia ere esan nahi du.

Thanos arkitektura

Aurreko atalean gure helburuak zerrendatu ondoren, lan ditzagun eta ikus ditzagun Thanosek arazo hauek nola konpontzen dituen.

Ikuspegi globala

Dauden Prometheus instantzien gainean ikuspegi global bat lortzeko, eskaera-sarrera-puntu bakarra lotu behar dugu zerbitzari guztiei. Horixe da Thanos osagaiak egiten duena. sidecar. Prometheus zerbitzari bakoitzaren ondoan zabaltzen da eta proxy gisa funtzionatzen du, Prometheus-en tokiko datuak gRPC Store APIaren bidez hornitzen dituena, denbora serieko datuak etiketa eta denbora tartearen arabera berreskuratzeko aukera emanez.

Beste aldean, eskalatzeko, estaturik gabeko Querier osagaia dago, Prometheus HTTP API estandarraren bidez PromQL kontsultak erantzutea baino ezer gehiago egiten duena. Querier, Sidecar eta Thanoseko beste osagai batzuen bidez komunikatzen dira esamesak protokoloa.

Thanos - Prometheus eskalagarria

  1. Querier, eskaera bat jasotzean, dagokion Store API zerbitzariarekin konektatzen da, hau da, gure Sidecars-etara eta dagozkion Prometheus zerbitzarietatik denbora-serieen datuak jasotzen ditu.
  2. Horren ondoren, erantzunak konbinatzen ditu eta PromQL kontsulta bat exekutatzen du. Querier-ek Prometheus HA zerbitzarietako datu deskonbinatuak eta bikoiztuak batu ditzake.

Honek gure puzzlearen pieza garrantzitsu bat konpontzen du: Prometheus zerbitzari isolatuetako datuak ikuspegi bakarrean konbinatuz. Izan ere, Thanos funtzio honetarako bakarrik erabil daiteke. Ez da aldaketarik egin behar dauden Prometheus zerbitzarietan!

Iraupen mugagabea!

Hala ere, lehenago edo beranduago Prometheus-en atxikipen-denboratik haratago gorde nahi ditugu datuak. Objektuen biltegiratzea aukeratu dugu datu historikoak gordetzeko. Oso eskuragarri dago edozein hodeitan eta baita datu-zentro lokaletan ere eta oso errentagarria da. Gainera, ia edozein objektu biltegiratze eskuragarri dago S3 API ezagunaren bidez.

Prometheus-ek bi orduz behin idazten ditu datuak RAMetik diskora. Biltegiratutako datu-blokeak datu guztiak ditu denbora-tarte finko batean eta aldaezina da. Hau oso erosoa da Thanos Sidecar-ek Prometheus datuen direktorioa begiratu besterik ez duelako eta, bloke berriak eskuragarri dauden heinean, objektuak biltegiratzeko kuboetan kargatu.

Thanos - Prometheus eskalagarria

Diskoan idatzi eta berehala objektuen biltegian kargatzeak scraper (Prometheus eta Thanos Sidecar) sinpletasunari eusteko aukera ematen du. Horrek laguntza, kostua eta sistemaren diseinua errazten ditu.

Ikus dezakezunez, datuen babeskopia oso erraza da. Baina zer gertatzen da objektuen biltegian datuak kontsultatzea?

Thanos Store osagaiak proxy gisa funtzionatzen du objektuen biltegitik datuak berreskuratzeko. Thanos Sidecar-ek bezala, esamesak multzoan parte hartzen du eta Store APIa ezartzen du. Modu honetan, lehendik dagoen Querier-ek Sidecar bat bezala trata dezake, denbora serieko datuen beste iturri gisa, ez da konfigurazio berezirik behar.

Thanos - Prometheus eskalagarria

Denbora serieko datu-blokeek hainbat fitxategi handiz osatuta daude. Eskaeraren arabera kargatzea nahiko ez litzateke eraginkorra izango, eta lokalean gordetzeak memoria eta diskoko espazio handia beharko luke.

Horren ordez, Store Gateway-k badaki Prometheus biltegiratze formatua nola kudeatu. Kontsulta programatzaile adimendunari esker eta blokeen indize-zatiak soilik gordetzeari esker, posible da kontsulta konplexuak gutxieneko HTTP eskaera kopuru batera murriztea objektuak biltegiratzeko fitxategietarako. Modu honetan, eskaera kopurua lau edo sei magnitudeko ordenatan murriztu dezakezu eta, oro har, SSD lokaleko eskaeretatik datuetara bereizteko zailak diren erantzun-denborak lor ditzakezu.

Thanos - Prometheus eskalagarria

Goiko diagraman erakusten den bezala, Thanos Querier-ek objektuen biltegiratze-datuen kontsulta bakoitzeko kostua nabarmen murrizten du Prometheus biltegiratze formatua aprobetxatuz eta erlazionatutako datuak elkarren ondoan jarriz. Ikuspegi hau erabiliz, eskaera bakar asko konbina ditzakegu gutxieneko eragiketa multzo batean.

Trinkotzea eta azpilaginketa

Denbora serieko datu-bloke berri bat objektuen biltegian behar bezala kargatu ondoren, datu "historiko" gisa tratatzen dugu, eta berehala eskuragarri daude Store Gateway bidez.

Hala ere, denbora pixka bat igaro ondoren, iturri bateko blokeak (Prometheus Sidecar-ekin) pilatzen dira eta jada ez dute indexatzeko potentzial osoa erabiltzen. Arazo hau konpontzeko, Compactor izeneko beste osagai bat sartu dugu. Prometheus-en tokiko trinkotze-motorra besterik ez du aplikatzen objektuen biltegiratze datu historikoei eta aldizkako sorta-lan soil gisa exekutatu daiteke.

Thanos - Prometheus eskalagarria

Konpresio eraginkorrari esker, biltegiratzea denbora luzez kontsultatzeak ez du arazorik sortzen datuen tamainari dagokionez. Hala ere, mila milioi balio deskonprimitu eta kontsulta-prozesadore baten bidez exekutatzeko kostu potentzialak kontsultaren exekuzio-denbora izugarri handitzea eragingo du ezinbestean. Bestalde, pantailan pixel bakoitzeko ehunka datu-puntu daudenez, ezinezkoa bihurtzen da datuak bereizmen osoan ikustea ere. Beraz, beheranzko laginketa ez da posible bakarrik, baizik eta ez du zehaztasun-galera nabarmenik ekarriko.

Thanos - Prometheus eskalagarria

Datuak gutxitzeko, Compactor-ek etengabe gehitzen ditu datuak bost minutu eta ordu bateko bereizmenarekin. TSDB XOR konpresioa erabiliz kodetutako zati gordina bakoitzeko, datu agregatu mota desberdinak gordetzen dira, hala nola, bloke baterako min, max edo batura. Horri esker, Querier-ek automatikoki hautatzen du PromQL kontsulta baterako egokia den agregatua.

Ez da konfigurazio berezirik behar erabiltzaileak doitasun murriztuko datuak erabiltzeko. Querier-ek automatikoki bereizmen eta datu gordinaren artean aldatzen du erabiltzaileak handitu eta txikiagotu ahala. Nahi izanez gero, erabiltzaileak zuzenean kontrola dezake eskaerako "urrats" parametroaren bidez.

GB bat gordetzeko kostua baxua denez, lehenespenez Thanos-ek datu gordinak, bost minutuko eta ordu bateko bereizmen datuak gordetzen ditu. Ez dago jatorrizko datuak ezabatu beharrik.

Grabaketa-arauak

Thanos-ekin ere, grabazio-arauak monitorizazio-pilaren funtsezko zati dira. Kontsulten konplexutasuna, latentzia eta kostua murrizten dute. Erabiltzaileentzat ere erosoak dira neurgailuen arabera datu agregatuak lortzeko. Thanos bainila Prometheus instantzian oinarritzen da, beraz, guztiz onargarria da grabazio-arauak eta alerta-arauak lehendik dagoen Prometheus zerbitzari batean gordetzea. Hala ere, kasu batzuetan hau nahikoa ez da:

  • Alerta eta arau globala (adibidez, zerbitzu batek hiru multzotik bitan baino gehiagotan funtzionatzen ez duenean alerta bat).
  • Biltegiratze lokaletik kanpoko datuetarako araua.
  • Arau eta alerta guztiak leku bakarrean gordetzeko nahia.

Thanos - Prometheus eskalagarria

Kasu guztietarako, Thanosek Ruler izeneko osagai bereizia barne hartzen du, araua eta alerta Thanos Queries bidez kalkulatzen dituena. StoreAPI ezaguna eskainiz, Kontsulta-nodoak kalkulatu berri diren neurketak atzi ditzake. Geroago objektuen biltegian ere gordetzen dira eta Store Gateway-ren bidez eskuragarri jartzen dira.

Thanosen boterea

Thanos nahikoa malgua da zure beharretara egokitu ahal izateko. Hau bereziki erabilgarria da Prometheus arruntetik migratzean. Azkar labur dezagun Thanos osagaiei buruz ikasi duguna adibide azkar batekin. Hona hemen zure bainila Prometheus "neurri mugagabeko biltegiratze" mundura nola eraman:

Thanos - Prometheus eskalagarria

  1. Gehitu Thanos Sidecar zure Prometheus zerbitzarietan; adibidez, sidecar edukiontzi bat Kubernetes pod batean.
  2. Inplementatu Thanos Querier-en hainbat erreplika datuak ikusi ahal izateko. Fase honetan erraza da Scraper eta Querier-en arteko esamesak konfiguratzea. Osagaien elkarrekintza egiaztatzeko, erabili 'thanos_cluster_members' metrika.

Bi urrats hauek nahikoak dira ikuspegi globala eta Prometheus HA erreplika potentzialetatik datuen desduplicazio zuzena emateko! Konektatu zure aginte-panelak Querier HTTP amaierako puntura edo erabili zuzenean Thanos UI.

Hala ere, neurrien babeskopia eta epe luzerako biltegiratzea behar baduzu, beste hiru urrats egin beharko dituzu:

  1. Sortu AWS S3 edo GCS ontzi bat. Konfiguratu Sidecar-a kubo hauetan datuak kopiatzeko. Tokiko datuen biltegiratzea minimizatu daiteke orain.
  2. Inplementatu Store Gateway eta konektatu lehendik duzun esamesak multzora. Orain babeskopiko datuak kontsulta ditzakezu!
  3. Inplementatu Compactor kontsultaren eraginkortasuna hobetzeko denbora-tarte luzeetan trinkotzea eta azpilaginketa erabiliz.

Gehiago jakin nahi baduzu, ez izan zalantzarik gure begirada bat botatzeko kubernetes manifest adibide и hasten!

Bost urrats bakarrik, Prometheus kontrol-sistema fidagarri bihurtu dugu ikuspegi globalarekin, biltegiratze denbora mugagabearekin eta neurgailuen erabilgarritasun handiko potentziala.

Tira eskaera: behar zaitugu!

Thanos kode irekiko proiektua izan da hasiera-hasieratik. Prometheus-en integrazio ezin hobea eta Thanos-en zati bat soilik erabiltzeko gaitasunak aukera bikaina da zure monitorizazio sistema esfortzurik gabe eskalatzeko.

Beti ongi etorria ematen diogu GitHub Pull eskaerak eta arazoak. Bitartean, jar zaitez gurekin harremanetan Github Issues edo slack bidez Improbable-eng #thanosgaldera edo iritzia baduzu, edo zure esperientzia partekatu nahi baduzu! Improbablen egiten duguna gustatzen bazaizu, jarri gurekin harremanetan - beti ditugu hutsik!

Ikastaroari buruzko informazio gehiago.

Iturria: www.habr.com

Gehitu iruzkin berria