Përkthimi i artikullit është përgatitur posaçërisht për studentët e kursit .
â zhvillues softueri, pasionant i Go dhe entuziast i zgjidhjes sĂ« problemeve tĂ« ndĂ«rlikuara. Ai gjithashtu Ă«shtĂ« menteri i Prometheus dhe bashkĂ«themelues i Kubernetes SIG instrumentation. MĂ« parĂ« ka qenĂ« inxhinier prodhimi nĂ« SoundCloud dhe udhĂ«hoqi grupin e monitorimit nĂ« CoreOS. Aktualisht punon nĂ« Google.
â inxhinier infrastrukture nĂ« Improbable. Ai Ă«shtĂ« i apasionuar pas teknologjive tĂ« reja dhe problemeve tĂ« sistemeve tĂ« shpĂ«rndara. Ka pĂ«rvojĂ« nĂ« programimin e nivelit tĂ« ulĂ«t nĂ« Intel, si dhe ka kontribuar nĂ« Mesos dhe ka pĂ«rvojĂ« prodhimi si SRE nĂ« shkallĂ« globale nĂ« Improbable. Punohet pĂ«r pĂ«rmirĂ«simin e botĂ«s sĂ« mikroshĂ«rbimeve. Tre dashuritĂ« e tij: Golang, open source dhe volejboll.
Duke parë produktin tonë kryesor SpatialOS, ju mund të kuptoni se për Improbable nevojitet një infrastrukturë cloud me dinamizëm të lartë dhe në shkallë globale me dhjetëra klasterë Kubernetes. Ne ishim disa nga të parët që filluam përdorimin e sistemit të monitorimit . Prometheus është në gjendje të monitorojë miliona metrika në kohë reale dhe vjen me një gjuhë të fuqishme pyetjesh që lejon nxjerrjen e informacionit të nevojshëm.
ThjeshtĂ«sia dhe besueshmĂ«ria e Prometheus janĂ« disa nga avantazhet e tij kryesore. MegjithatĂ«, pasi arritĂ«m njĂ« masĂ« tĂ« caktuar, u pĂ«rballĂ«m me disa disavantazhe. PĂ«r tĂ« zgjidhur kĂ«to probleme, ne zhvilluam â njĂ« projekt me kod tĂ« hapur, i krijuar nga Improbable, pĂ«r transformimin pa ndĂ«rprerje tĂ« klasterĂ«ve ekzistues tĂ« Prometheus nĂ« njĂ« sistem tĂ« vetĂ«m monitorimi me ruajtje tĂ« pakufizuar tĂ« tĂ« dhĂ«nave historike. Thanos Ă«shtĂ« i disponueshĂ«m nĂ« Github .
QĂ«llimet tona me Thanos
Në një masë të caktuar, lindin probleme që tejkalojnë kapacitetet e Prometheus vanilla. Si të ruajmë me besueshmëri dhe në mënyrë ekonomikë petabajt të të dhënave historike? A është e mundur të bëhet kjo pa ndikuar në kohën e përgjigjes për pyetje? A mund të aksesohen të gjitha metrikat të shpërndara në serverë të ndryshëm të Prometheus me një kërkesë API? A mund të kombinohen ndonjëherë të dhënat e riplikuar të mbledhura nga Prometheus HA?
Për të zgjidhur këto pyetje, ne krijuam Thanos. Në seksionet e ardhshme përshkruhet si iu qasëm zgjidhjeve të këtyre problemeve dhe shpjegohen qëllimet që ndjekim.
Kërkesa për të dhëna nga disa instanca të Prometheus (global query)
Prometheus ofron një qasje funksionale ndaj sharding. Edhe një server Prometheus siguron një shkallëzim të mjaftueshëm për t'i çliruar përdoruesit nga vështirësitë e sharding horizontal në pothuajse të gjitha rastet e përdorimit.
MegjithatĂ«, ndonjĂ«herĂ« kĂ«rkohet tĂ« aksesohen tĂ« dhĂ«nat nĂ« serverĂ« tĂ« ndryshĂ«m tĂ« Prometheus pĂ«rmes njĂ« API ose UI tĂ« vetĂ«m â pamja globale. Natyrisht, ka mundĂ«sinĂ« pĂ«r tĂ« shfaqur disa kĂ«rkesa nĂ« njĂ« tabelĂ« Grafana, por çdo kĂ«rkesĂ« mund tĂ« ekzekutohet vetĂ«m nĂ« njĂ« server Prometheus. Nga ana tjetĂ«r, me Thanos mund tĂ« kĂ«rkoni dhe tĂ« grumbulloni tĂ« dhĂ«na nga disa serverĂ« tĂ« Prometheus, pasi tĂ« gjithĂ« janĂ« tĂ« aksesueshĂ«m nga njĂ« pikĂ« fundore.
Më parë, për të marrë pamjen globale në Improbable, ne organizuam instancat tona të Prometheus në një sistem shumë-njësor . Kjo do të thoshte krijimin e një serveri meta të Prometheus, i cili grumbullonte një pjesë të metrikave nga çdo server "gjethe".
Ky qasje u tregua problematike. Kjo çoi në ndërlikimin e konfigurimit, shtimin e një pike të mundshme dështimi dhe aplikimin e rregullave të ndërlikuara për t'i ofruar pikët federale vetëm të dhënat e nevojshme. Për më tepër, një federatë e tillë nuk lejon të arrihet një pamje globale reale, pasi jo të gjitha të dhënat janë të aksesueshme nga një kërkesë API.
Kjo lidhet ngushtë me një paraqitje të vetme të të dhënave të mbledhura në serverëve të Prometheus me disponueshmëri të lartë (high-availability, HA). Modeli HA i Prometheus mbledh të dhëna dy herë në mënyrë të pavarur, gjë që është aq e thjeshtë, sa nuk mund të jetë më e thjeshtë. Megjithatë, përdorimi i një paraqitje të bashkuar dhe të dedupuar të dy flukseve do të ishte shumë më i përshtatshëm.
Sigurisht, ka njĂ« nevojĂ« pĂ«r servera Prometheus me disponueshmĂ«ri tĂ« lartĂ«. NĂ« Improbable ne e marrim shumĂ« seriozisht monitorimin e tĂ« dhĂ«nave çdo minutĂ«, por mbajtja e njĂ« instance Prometheus nĂ« klaster Ă«shtĂ« njĂ« pikĂ« e vetme dĂ«shtimi. Ădo gabim konfigurimi ose dĂ«shtim hardueri mund tĂ« çojĂ« potencialisht nĂ« humbje tĂ« tĂ« dhĂ«nave tĂ« rĂ«ndĂ«sishme. Edhe njĂ« shpĂ«rndarje e thjeshtĂ« mund tĂ« çojĂ« nĂ« ndonjĂ« ndĂ«rprerje tĂ« vogĂ«l nĂ« mbledhjen e metrikave, pasi riaktivizimi mund tĂ« zgjasĂ« shumĂ« mĂ« tepĂ«r se intervali i skanimit.
Ruajtja e besueshme e të dhënave historike
Ruajtja e lirisë dhe e shpejtë e metrikave për një periudhë të gjatë është ëndrra jonë (njësoj si shumicës së përdoruesve të Prometheus). Në Improbable, ishim të detyruar të caktomë një kohë ruajtjeje për metrikat prej nëntë ditësh (për Prometheus 1.8). Kjo vendos kufizime të dukshme për sa larg mund të shohim mbrapa.
Prometheus 2.0 ka përmirësuar këtë aspekt, pasi numri i serive të kohës nuk ndikon më në performancën e përgjithshme të serverit (shih ). Megjithatë, Prometheus ruan të dhënat në disqet vendase. Edhe pse kompresimi efikas i të dhënave mund të reduktojë ndjeshëm përdorimin e SSD-ve vendase, në fund të fundit, ka ende një kufizim mbi sasinë e të dhënave historike që mund të ruhen.
Përveç kësaj, në Improbable ne interesohemi për besueshmërinë, thjeshtësinë dhe kostot. Disqet vendase të mëdha janë më të vështira për t'u menaxhuar dhe për tu siguruar. Ato janë më të shtrenjta dhe kërkojnë më shumë mjete për sigurimin, duke sjellë kështu kompleksitet të panevojshëm.
E reduktuar
Sapo filluam të punojmë me të dhëna historike, kuptuam se ekzistojnë vështirësi themelore me O-madh, të cilat ngadalësojnë kërkesat ndërsa punojmë me të dhëna për javë, muaj dhe vite.
Zgjidhja standarde pĂ«r kĂ«tĂ« problem do tĂ« ishte (downsampling) - reduktimi i frekuencĂ«s sĂ« mostrave tĂ« sinjalit. Duke bĂ«rĂ« kĂ«tĂ«, ne mund tĂ« âpĂ«rfshijmĂ«â nĂ« njĂ« interval mĂ« tĂ« gjerĂ« kohor dhe tĂ« ruajmĂ« numrin e mĂ«parshĂ«m tĂ« mostrave, gjĂ« qĂ« ndihmon pĂ«r tĂ« mbajtur reagimin e kĂ«rkesave.
E reduktuar të dhënat e vjetra është një kërkesë e paevitueshme për çdo zgjidhje për ruajtjen afatgjatë dhe shkon përtej Prometheus-it standard.
Qëllime të tjera
NjĂ« nga objektivat e hershĂ«m tĂ« projektit Thanos ishte integrimi i pandĂ«rprerĂ« me çdo instalacion ekzistues tĂ« Prometheus. QĂ«llimi i dytĂ« ishte operimi i thjeshtĂ« me njĂ« barrierĂ« minimale hyrjeje. Ădo varĂ«si duhet tĂ« jetĂ« e lehtĂ« pĂ«r t'u pĂ«rmbushur si pĂ«r pĂ«rdorues tĂ« vegjĂ«l ashtu edhe pĂ«r ata tĂ« mĂ«dhenj, duke nĂ«nkuptuar gjithashtu njĂ« kosto bazĂ« tĂ« vogĂ«l.
Arkitektura Thanos
Pasi u përmendën qëllimet tona në seksionin e mëparshëm, le të punojmë për to dhe të shohim se si Thanos i trajton këto çështje.
Pamja globale
Për të marrë pamjen globale mbi instancat ekzistuese të Prometheus, na nevojitet një pikë e vetme hyrjeje për kërkesa që lidhet me të gjithë serverët. Ky është roli i komponentit Thanos . Ai është i vendosur pranë çdo serveri Prometheus dhe funksionon si një proxy, duke shërbyer të dhënat lokale të Prometheus nëpërmjet një ndërfaqeje gRPC të Store API, që lejon përzgjedhjen e të dhënave të serive të kohës sipas etiketimeve dhe intervaleve të kohës.
Nga ana tjetër, ndodhet komponenti Querier, që është horizontalisht i shkallëzueshëm dhe pa ruajtje, i cili bën pak më shumë se thjesht përgjigjet kërkesave PromQL përmes API-t standard të HTTP të Prometheus. Komponentët Querier, Sidecar, dhe Thanos të tjerë ndërveprojnë përmes .
- Querier, në marrjen e një kërkese, lidhet me serverin e duhur të Store API, d.m.th., me Sidecar-t tanë dhe merr të dhënat e serive të kohës nga serverët përkatës të Prometheus.
- Pas kësaj, ai bashkon përgjigjet dhe ekzekuton krahasimet me PromQL. Querier mund të bashkojë të dhëna që nuk përputhen dhe gjithashtu të dhëna të dyfishuara nga serverët e HA të Prometheus.
Kjo zgjidh nĂ« mĂ«nyrĂ« tĂ« konsiderueshme njĂ« pjesĂ« tĂ« thelbĂ«sore tĂ« misterit tonĂ« â bashkimin e tĂ« dhĂ«nave nga serverĂ« tĂ« izoluara tĂ« Prometheus nĂ« njĂ« pamje tĂ« vetme. NĂ« fakt, Thanos mund tĂ« pĂ«rdoret vetĂ«m pĂ«r kĂ«tĂ« mundĂ«si. Nuk kĂ«rkohet asnjĂ« ndryshim nĂ« serverĂ«t ekzistues tĂ« Prometheus!
Ruajtje e pakufizuar!
Megjithatë, herët a vonë do të duam të ruajmë të dhënat që shkojnë përtej kohës së zakonshme të ruajtjes së Prometheus. Për ruajtjen e të dhënave historike, ne zgjodhëm ruajtjen e objekteve. Ajo është e disponueshme gjerësisht në çdo cloud, si dhe në Qendrat e të Dhënave lokale dhe është shumë ekonomike. Për më tepër, pothuajse çdo ruajtje objektesh është e disponueshme përmes API-t të njohur S3.
Prometheus shkruan të dhënat nga memoria në disk çdo dy orë. Blloku i të dhënave të ruajtura përmban të gjitha të dhënat për një interval të caktuar kohor dhe është i pandryshueshëm. Kjo është shumë e përshtatshme, sepse Thanos Sidecar mund të shohë thjesht katalogun e të dhënave të Prometheus dhe, ndërsa shfaqen blloqe të reja, i ngarkon ato në koshat e ruajtjes së objekteve.
Ngarkimi në ruajtjen e objekteve menjëherë pas shkruhet në disk gjithashtu ndihmon për të ruajtur thjeshtësinë e 'skraperit' (Prometheus dhe Thanos Sidecar). Kjo e thjeshton mbështetje, kostot dhe dizajnin e sistemit.
Siç e shihni, mbështetje për të dhënat implementohet shumë lehtë. Por çfarë ndodh me kërkesat për të dhëna në ruajtjen e objekteve?
Komponenti Thanos Store vepron si proxy pĂ«r marrjen e tĂ« dhĂ«nave nga depoja objektesh. Ashtu si Thanos Sidecar, ai Ă«shtĂ« pjesĂ« e njĂ« klasteri gossip dhe zbatojnĂ« API-nĂ« e Store. KĂ«shtu, kĂ«rkuesit ekzistues mund ta shohin atĂ« si njĂ« Sidecar, si njĂ« burim tjetĂ«r tĂ« dhĂ«nash tĂ« serive me kohĂ« â nuk kĂ«rkohet ndonjĂ« konfigurim tĂ« veçantĂ«.
Blloqet e të dhënave me kohë përbëhen nga disa skedarë të mëdhenj. Shkarkimi i tyre sipas kërkesës do të ishte mjaft i pamjaftueshëm, ndërsa ruajtja lokale do të kërkonte një hapësirë të madhe memorjeje dhe disku.
Në vend të kësaj, Store Gateway di si të trajtojë formatin e ruajtjes së Prometheus. Me një planifikues të mençur të kërkesave dhe ruajtjen në cache të vetëm pjesëve të nevojshme të indekseve të blloqeve, është bërë e mundur të reduktohen kërkesat komplekse në numrin minimal të kërkesave HTTP ndaj skedarëve të depoja objektesh. Kështu, numri i kërkesave mund të reduktohet me katër deri në gjashtë rend dhe të arrihet një kohë përgjigje, e cila përgjithësisht është e vështirë të ndryshohet nga kërkesat për të dhëna në SSD lokale.
Siç tregohet në diagramin e mësipërm, Thanos Querier ul ndjeshëm kostot për një kërkesë ndaj të dhënave në depo objekt, duke përdorur formatin e ruajtjes së Prometheus dhe duke vendosur të dhënat përkatëse pranë njëri-tjetrit. Duke përdorur këtë qasje, ne mund të kombinojmë shumë kërkesa individuale në një numër minimal të operacioneve masive.
Kompaktimi dhe NĂ«nkampimi
Pasi blloku i ri i tĂ« dhĂ«nave me kohĂ« tĂ« jetĂ« ngarkuar me sukses nĂ« depo objekt, ne e konsiderojmĂ« atĂ« si tĂ« dhĂ«na âhistorikeâ, tĂ« cilat menjĂ«herĂ« bĂ«hen tĂ« disponueshme pĂ«rmes Store Gateway.
Megjithatë, pas një periudhe kohe, blloqet nga një burim (Prometheus me Sidecar) grumbullohen dhe nuk shfrytëzojnë më potencialin e plotë të indeksimit. Për të zgjidhur këtë problem, ne kemi prezantuar një komponent tjetër të quajtur Compactor. Ai thjesht aplikon mekanizmin lokal të kompresimit të Prometheus mbi të dhënat historike në depo objekt dhe mund të ecë si një detyrë e thjeshtë periodike.
Falë kompresimit efikas, një kërkesë në depo për një periudhë të gjatë kohore nuk paraqet probleme nga pikëpamja e madhësisë së të dhënave. Megjithatë, kostoja potenciale e dekompresimit të një miliardi vlerave dhe kalimi i tyre nëpër procesorin e kërkesave do të çojë menjëherë në një rritje të mprehtë të kohës së ekzekutimit të kërkesës. Nga ana tjetër, pasi për çdo pixel të ekranit ka qindra pikë të dhënash, bëhet e pamundur të vizualizosh të dhënat në rezolucion të plotë. Kështu, nënkampimi jo vetëm që është i mundshëm, por gjithashtu nuk do të çojë në një humbje të dukshme saktësie.
Për të nënkampuar të dhënat, Compactor vazhdimisht agregon të dhënat me një rezolucion prej pesë minutash dhe një ore. Për çdo fragment të papërpunuar, i koduar me kompresim TSDB XOR, ruhen lloje të ndryshme të të dhënave të agreguara, si min, max ose sum për një bllok. Kjo lejon që Querier të zgjedhë automatikisht agregatin që i përshtatet një kërkese të caktuar PromQL.
PĂ«r tĂ« pĂ«rdorur tĂ« dhĂ«nat me saktĂ«si tĂ« ulĂ«t, pĂ«rdoruesi nuk ka nevojĂ« pĂ«r ndonjĂ« konfigurim tĂ« veçantĂ«. Querier kalon automatikisht midis rezolucioneve tĂ« ndryshme dhe tĂ« dhĂ«nave tĂ« papĂ«rpunuara ndĂ«rsa pĂ«rdoruesi zgjeron dhe ngushton shkallĂ«n. NĂ«n dĂ«shirĂ«n e tij, pĂ«rdoruesi mund ta menaxhojĂ« kĂ«tĂ« direkt pĂ«rmes parametrave âhapiâ nĂ« kĂ«rkesĂ«.
Duke qenë se kostoja e ruajtjes së një GB është e vogël, për nga default Thanos ruan të dhënat origjinale, të dhënat me rezolucion prej pesë minutash dhe një ore. Nuk ka nevojë të hiqni të dhënat origjinale.
Rregullat e regjistrimit
Edhe me Thanos, rregullat e regjistrimit janë një pjesë e rëndësishme e stakut të mbikëqyrjes. Ato reduktojnë kompleksitetin, vonesën dhe kostot e kërkesave. Ato janë gjithashtu të përshtatshme për përdoruesit për të marrë të dhëna të agreguara në metrikat. Thanos bazohet në instancat vanilla të Prometheus, prandaj është e pranueshme të ruani rregullat e regjistrimit dhe rregullat e alarmit në serverin ekzistues të Prometheus. Sidoqoftë, në disa raste, kjo mund të jetë e pamjaftueshme:
- Alarmi global dhe rregulli (p.sh., njoftimi kur shërbimi nuk funksionon në më shumë se dy nga tre klasterët).
- Rregulli për të dhënat jashtë depo objekt.
- Dëshira për të ruajtur të gjitha rregullat dhe alarmet në një vend.
Për të gjitha këto raste, Thanos përfshin një komponent të veçantë të quajtur Ruler, i cili llogarit rregullat dhe alarmet përmes Thanos Queries. Duke ofruar një StoreAPI të njohur, nyja Query mund të hyjë në metrika të reja të përllogaritura. Më vonë ato ruhet gjithashtu në depo objekt dhe bëhen të disponueshme përmes Store Gateway.
Fuqia e Thanos
Thanos është mjaft fleksibël për t'u konfiguruar sipas kërkesave tuaja. Kjo është veçanërisht e dobishme gjatë migrimit nga Prometheus i thjeshtë. Le të rikujtojmë shpejt, me një shembull të vogël, çfarë kemi mësuar për komponentët e Thanos. Ja si ta transferoni Prometheus-in tuaj në botën e "ruajtjes së pakufizuar të metrikave":
- Shtoni Thanos Sidecar nĂ« serverat tuaj Prometheus â pĂ«r shembull, njĂ« kontejner fqinj nĂ« pod-in Kubernetes.
- ShpĂ«rndani disa replika Thanos Querier pĂ«r tĂ« pasur mundĂ«sinĂ« e shikimit tĂ« tĂ« dhĂ«nave. NĂ« kĂ«tĂ« fazĂ«, Ă«shtĂ« e lehtĂ« tĂ« konfigurosh gossip ndĂ«rmjet Scraper dhe Querier. PĂ«r tĂ« verifikuar interaksionin e komponentĂ«ve, pĂ«rdorni metrikĂ«n âthanos_cluster_membersâ.
Ato dy hapa mjaftojnë për të siguruar një pamje globale dhe deduplication pa probleme të të dhënave nga replikat e mundshme HA të Prometheus! Thjesht lidheni dashboard-et tuaja me pikën finale HTTP të Querier-it ose përdorni ndërfaqen Thanos UI direkt.
Megjithatë, nëse ju nevojitet mbështetje për metrikat dhe ruajtje afatgjatë, do t'ju nevojitet të kryeni edhe tri hapa të tjerë:
- Krijoni një bucket AWS S3 ose GCS. Konfiguroni Sidecar për të kopjuar të dhënat në këto bucketa. Tani mund të minimizoni ruajtjen lokale të të dhënave.
- Shpërndani Store Gateway dhe lidheni atë me klasterin e gossip-it ekzistues. Tani mund të dërgoni kërkesa për të dhënat në backup!
- Shpërndani Compactor-in për të rritur efikasitetin e kërkesave për periudha të gjata kohore, duke përdorur kompresimin dhe downsampling.
Nëse dëshironi të dini më shumë, mos ngurroni të shihni dhe !
Bëni të mundur transformimin e Prometheus në një sistem të besueshëm monitorimi me pamje globale, kudo që është, ruajtje të pakufizuar dhe potencial të lartë për akses të metrikave.
Pull request: na nevojiten!
Nga fillimi, ka qenë një projekt me burim të hapur. Integrimi i pa probleme me Prometheus dhe mundësia për të përdorur vetëm një pjesë të Thanos e bën atë një zgjedhje të shkëlqyer për të skaluar sistemin e monitorimit pa të meta.
GĂ«zohemi gjithmonĂ« pĂ«r GitHub Pull Request dhe Issues. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, mos ngurroni tĂ« na kontaktoni pĂ«rmes Github Issues ose slack, nĂ«se keni pyetje ose komente, ose dĂ«shiron tĂ« ndash pĂ«rvojĂ«n tĂ«nde tĂ« pĂ«rdorimit! NĂ«se ju pĂ«lqen ajo qĂ« bĂ«jmĂ« nĂ« Improbable, mos hezitoni tĂ« na kontaktoni â !
Burimi: habr.com
