Përkthimi i artikullit u përgatit posaçërisht për studentët e kursit .
është një zhvillues softuerësh, Go fanatik dhe zgjidhës i problemeve. Ai është gjithashtu një mirëmbajtës i Prometheus dhe bashkëthemelues i instrumentimit Kubernetes SIG. Në të kaluarën, ai ishte një inxhinier prodhimi në SoundCloud dhe drejtoi ekipin e monitorimit në CoreOS. Aktualisht punon në Google.
- Inxhinier Infrastrukture në Improbable. Ai është i interesuar për teknologjitë e reja dhe problemet e sistemeve të shpërndara. Ai ka përvojë programimi të nivelit të ulët në Intel, përvojë kontribues në Mesos dhe përvojë të klasit botëror të prodhimit SRE në Improbable. Përkushtuar për të përmirësuar botën e mikroshërbimeve. Tre dashuritë e tij: Golang, burim i hapur dhe volejboll.
Duke parë produktin tonë kryesor SpatialOS, mund të merrni me mend se Improbable kërkon një infrastrukturë cloud shumë dinamike në shkallë globale me dhjetëra grupime Kubernetes. Ne ishim nga të parët që përdorëm një sistem monitorimi . Prometheus është në gjendje të gjurmojë miliona metrikë në kohë reale dhe vjen me një gjuhë të fuqishme pyetjesh që ju lejon të nxirrni informacionin që ju nevojitet.
Thjeshtësia dhe besueshmëria e Prometheus është një nga avantazhet e tij kryesore. Megjithatë, pasi kaluam një shkallë të caktuar, hasëm disa të meta. Për të zgjidhur këto probleme ne kemi zhvilluar është një projekt me burim të hapur i krijuar nga Improbable për të transformuar pa probleme grupimet ekzistuese të Prometheus në një sistem të vetëm monitorimi me ruajtje të pakufizuar të të dhënave historike. Thanos është në dispozicion në Github .
Objektivat tona me Thanos
Në një shkallë të caktuar, lindin probleme që janë përtej aftësive të Prometeut të vaniljes. Si të ruani në mënyrë të besueshme dhe ekonomike petabajt të dhëna historike? A mund të bëhet kjo pa kompromentuar kohën e përgjigjes? A është e mundur të aksesoni të gjitha metrikat e vendosura në serverë të ndryshëm Prometheus me një kërkesë të vetme API? A ka ndonjë mënyrë për të kombinuar të dhënat e përsëritura të mbledhura duke përdorur Prometheus HA?
Për të adresuar këto çështje, ne krijuam Thanos. Seksionet në vijim përshkruajnë se si i kemi trajtuar këto çështje dhe shpjegojmë qëllimet tona.
Kërkimi i të dhënave nga disa raste të Prometheus (kërkesa globale)
Prometheus ofron një qasje funksionale për ndarjen. Edhe një server i vetëm Prometheus ofron shkallëzim të mjaftueshëm për të çliruar përdoruesit nga kompleksiteti i ndarjes horizontale në pothuajse të gjitha rastet e përdorimit.
Ndërsa ky është një model i shkëlqyeshëm vendosjeje, shpesh është e nevojshme të aksesoni të dhënat në serverë të ndryshëm Prometheus përmes një API ose UI të vetme - një pamje globale. Sigurisht, është e mundur të shfaqen pyetje të shumta në një panel Grafana, por çdo pyetje 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 shumë serverë Prometheus pasi të gjithë janë të aksesueshëm nga një pikë e vetme fundore.
Më parë, për të marrë një pamje globale në Improbable, ne organizuam instancat tona të Prometheus në një shumë nivele . Kjo nënkuptonte krijimin e një meta serveri Prometheus që mbledh disa nga metrikat nga çdo server me fletë.
Kjo qasje doli problematike. Kjo ka rezultuar në konfigurime më komplekse, shtimin e një pike tjetër të mundshme dështimi dhe aplikimin e rregullave komplekse për të siguruar që pika përfundimtare e federuar të marrë vetëm të dhënat që i nevojiten. Për më tepër, ky lloj federate nuk ju lejon të merrni një pamje të vërtetë globale, pasi jo të gjitha të dhënat janë të disponueshme nga një kërkesë e vetme API.
E lidhur ngushtë me këtë është një pamje e unifikuar e të dhënave të mbledhura në serverët Prometheus me disponueshmëri të lartë (HA). Modeli HA i Prometheus mbledh në mënyrë të pavarur të dhëna dy herë, gjë që është aq e thjeshtë sa nuk mund të ishte më e thjeshtë. Sidoqoftë, përdorimi i një pamjeje të kombinuar dhe të çdublikuar të të dy rrjedhave do të ishte shumë më i përshtatshëm.
Sigurisht, ka nevojë për serverë Prometheus shumë të disponueshëm. Në Improbable, ne e marrim me të vërtetë seriozisht monitorimin e të dhënave minutë pas minutë, por të kesh një shembull Prometheus për grup është një pikë e vetme dështimi. Çdo gabim konfigurimi ose dështimi i harduerit mund të çojë në humbjen e të dhënave të rëndësishme. Edhe një vendosje e thjeshtë mund të shkaktojë ndërprerje të vogla në mbledhjen e metrikës sepse rinisjet mund të jenë dukshëm më të gjata se intervali i gërvishtjes.
Ruajtja e besueshme e të dhënave historike
Ruajtja e lirë, e shpejtë dhe afatgjatë e metrikës është ëndrra jonë (e ndarë nga shumica e përdoruesve të Prometheus). Në E pamundur, ne u detyruam të konfiguronim periudhën e mbajtjes së metrikës në nëntë ditë (për Prometheus 1.8). Kjo shton kufizime të dukshme se sa larg mund të shikojmë.
Prometheus 2.0 është përmirësuar në këtë drejtim, pasi numri i serive kohore nuk ndikon më në performancën e përgjithshme të serverit (shih. ). Megjithatë, Prometheus ruan të dhënat në diskun lokal. Megjithëse kompresimi i të dhënave me efikasitet të lartë mund të zvogëlojë ndjeshëm përdorimin lokal të SSD-së, në fund të fundit ka ende një kufi për sasinë e të dhënave historike që mund të ruhen.
Për më tepër, në Improbable ne kujdesemi për besueshmërinë, thjeshtësinë dhe koston. Disqet e mëdhenj lokalë janë më të vështirë për t'u përdorur dhe për t'u rezervuar. Ata kushtojnë më shumë dhe kërkojnë më shumë mjete rezervë, duke rezultuar në kompleksitet të panevojshëm.
Zvogëlimi i mostrave
Pasi filluam të punonim me të dhënat historike, kuptuam se ka vështirësi thelbësore me big-O që i bëjnë pyetjet më të ngadalta dhe më të ngadalta ndërsa punojmë me javë, muaj dhe vite të dhënash.
Zgjidhja standarde për këtë problem do të ishte (zvogëlimi i mostrave) - zvogëlimi i frekuencës së marrjes së mostrave të sinjalit. Me zvogëlimin e mostrave, ne mund të "ulemi" në një gamë më të madhe kohore dhe të mbajmë të njëjtin numër mostrash, duke i mbajtur pyetjet të përgjegjshme.
Zvogëlimi i mostrave të të dhënave të vjetra është një kërkesë e pashmangshme e çdo zgjidhjeje të ruajtjes afatgjatë dhe është përtej qëllimit të Prometheus vanilje.
Objektivat shtesë
Një nga qëllimet fillestare të projektit Thanos ishte të integrohej pa probleme me çdo instalim ekzistues të Prometheus. Qëllimi i dytë ishte lehtësia e funksionimit me pengesa minimale për hyrje. Çdo varësi duhet të plotësohet lehtësisht si për përdoruesit e vegjël ashtu edhe për ata të mëdhenj, që nënkupton gjithashtu një kosto bazë të ulët.
Arkitektura e Thanos
Pasi të kemi renditur qëllimet tona në pjesën e mëparshme, le t'i shqyrtojmë ato dhe të shohim se si Thanos i zgjidh këto probleme.
Pamje globale
Për të marrë një pamje globale në krye të instancave ekzistuese të Prometheus, duhet të lidhim një pikë hyrjeje të vetme të kërkesës me të gjithë serverët. Kjo është pikërisht ajo që bën komponenti Thanos. . Ai vendoset pranë çdo serveri Prometheus dhe vepron si një përfaqësues, duke shërbyer të dhënat lokale të Prometheus përmes API-së së gRPC Store, duke lejuar që të dhënat e serive kohore të merren sipas etiketës dhe intervalit kohor.
Nga ana tjetër është komponenti Querier pa shtetësi, i shkallëzuar, i cili bën pak më shumë sesa thjesht t'u përgjigjet pyetjeve të PromQL nëpërmjet API standarde Prometheus HTTP. Querier, Sidecar dhe komponentë të tjerë Thanos komunikojnë nëpërmjet .
- Querier, me marrjen e një kërkese, lidhet me serverin përkatës API të Store, domethënë me Sidecars-in tonë dhe merr të dhëna të serive kohore nga serverët përkatës Prometheus.
- Pas kësaj, ai kombinon përgjigjet dhe ekzekuton një pyetje PromQL mbi to. Querier mund të bashkojë të dhëna të shkëputura dhe të dyfishta nga serverët Prometheus HA.
Kjo zgjidh një pjesë të madhe të enigmës sonë - duke kombinuar të dhënat nga serverët e izoluar të Prometheus në një pamje të vetme. Në fakt, Thanos mund të përdoret vetëm për këtë veçori. Nuk ka nevojë të bëhen ndryshime në serverët ekzistues të Prometheus!
Jetëgjatësi e pakufizuar!
Megjithatë, herët a vonë ne do të dëshirojmë të ruajmë të dhëna përtej kohës normale të ruajtjes së Prometheus. Ne zgjodhëm ruajtjen e objekteve për të ruajtur të dhënat historike. Është gjerësisht i disponueshëm në çdo re, si dhe në qendrat e të dhënave në ambiente dhe është shumë me kosto efektive. Për më tepër, pothuajse çdo ruajtje e objektit është në dispozicion përmes API-së së mirënjohur S3.
Prometheus shkruan të dhëna nga RAM në disk afërsisht çdo dy orë. Blloku i të dhënave të ruajtura përmban të gjitha të dhënat për një periudhë të caktuar kohe dhe është i pandryshueshëm. Kjo është shumë e përshtatshme sepse Thanos Sidecar thjesht mund të shikojë direktoriumin e të dhënave Prometheus dhe, kur blloqet e reja bëhen të disponueshme, t'i ngarkojë ato në kovat e ruajtjes së objekteve.
Ngarkimi në ruajtjen e objekteve menjëherë pas shkrimit në disk ju lejon gjithashtu të ruani thjeshtësinë e krueses (Prometheus dhe Thanos Sidecar). E cila thjeshton mbështetjen, koston dhe dizajnin e sistemit.
Siç mund ta shihni, rezervimi i të dhënave është shumë i thjeshtë. Por çfarë ndodh me kërkimin e të dhënave në ruajtjen e objekteve?
Komponenti Thanos Store vepron si një përfaqësues për të tërhequr të dhënat nga ruajtja e objekteve. Ashtu si Thanos Sidecar, ai merr pjesë në grupin e thashethemeve dhe zbaton API-në e Store. Në këtë mënyrë, Querier ekzistues mund ta trajtojë atë si një Sidecar, si një burim tjetër i të dhënave të serive kohore - nuk kërkohet konfigurim i veçantë.
Blloqet e të dhënave të serive kohore përbëhen nga disa skedarë të mëdhenj. Ngarkimi i tyre sipas kërkesës do të ishte mjaft joefikas, dhe ruajtja e tyre në memorie lokale do të kërkonte një sasi të madhe memorie dhe hapësirë në disk.
Në vend të kësaj, Store Gateway di se si të trajtojë formatin e ruajtjes së Prometheus. Falë një planifikuesi inteligjent të pyetjeve dhe ruajtja në memorie vetëm e pjesëve të nevojshme të indeksit të blloqeve, është e mundur të reduktohen pyetjet komplekse në një numër minimal kërkesash HTTP për të kundërshtuar skedarët e ruajtjes. Në këtë mënyrë, ju mund të zvogëloni numrin e kërkesave me katër deri në gjashtë renditje të madhësisë dhe të arrini kohë përgjigjesh që përgjithësisht janë të vështira për t'u dalluar nga kërkesat tek të dhënat në një SSD lokale.
Siç tregohet në diagramin e mësipërm, Thanos Querier ul ndjeshëm koston për pyetje të të dhënave të ruajtjes së objektit duke shfrytëzuar formatin e ruajtjes Prometheus dhe duke vendosur të dhënat e lidhura krah për krah. Duke përdorur këtë qasje, ne mund të kombinojmë shumë kërkesa të vetme në një numër minimal operacionesh me shumicë.
Ngjeshja dhe zvogëlimi i mostrave
Pasi një bllok i ri i të dhënave të serive kohore ngarkohet me sukses në ruajtjen e objekteve, ne e trajtojmë atë si të dhëna "historike", të cilat disponohen menjëherë përmes "Store Gateway".
Megjithatë, pas ca kohësh, blloqet nga një burim (Prometheus me Sidecar) grumbullohen dhe nuk përdorin më potencialin e plotë të indeksimit. Për të zgjidhur këtë problem, ne prezantuam një komponent tjetër të quajtur Compactor. Ai thjesht aplikon motorin lokal të ngjeshjes së Prometheus-it për të dhënat historike në ruajtjen e objekteve dhe mund të ekzekutohet si një punë e thjeshtë periodike e grumbullit.
Falë kompresimit efikas, kërkimi i ruajtjes për një periudhë të gjatë kohore nuk përbën problem për sa i përket madhësisë së të dhënave. Sidoqoftë, kostoja e mundshme e zbërthimit të një miliard vlerave dhe e përdorimit të tyre përmes një procesori të pyetjeve do të rezultojë në mënyrë të pashmangshme në një rritje dramatike të kohës së ekzekutimit të pyetjeve. Nga ana tjetër, duke qenë se në ekran ka qindra pika të dhënash për piksel, bëhet e pamundur të vizualizohen edhe të dhënat me rezolucion të plotë. Kështu, zvogëlimi i mostrave jo vetëm që është i mundur, por gjithashtu nuk do të çojë në një humbje të dukshme të saktësisë.
Për të pakësuar të dhënat, Compactor grumbullon vazhdimisht të dhëna me një rezolucion prej pesë minutash dhe një ore. Për çdo pjesë të papërpunuar të koduar duke përdorur kompresimin TSDB XOR, ruhen lloje të ndryshme të të dhënave agregate, të tilla si min, max ose shuma për një bllok. Kjo lejon që Querier të zgjedhë automatikisht një agregat që është i përshtatshëm për një pyetje të caktuar PromQL.
Nuk kërkohet konfigurim i veçantë që përdoruesi të përdorë të dhëna me saktësi të reduktuar. Querier kalon automatikisht midis rezolucioneve të ndryshme dhe të dhënave të papërpunuara ndërsa përdoruesi zmadhon dhe zvogëlon. Nëse dëshironi, përdoruesi mund ta kontrollojë këtë drejtpërdrejt përmes parametrit "hap" në kërkesë.
Meqenëse kostoja e ruajtjes së një GB është e ulët, si parazgjedhje Thanos ruan të dhëna të papërpunuara, të dhëna me rezolucion prej pesë minutash dhe një orë. Nuk ka nevojë të fshini të dhënat origjinale.
Rregullat e regjistrimit
Edhe me Thanos, rregullat e regjistrimit janë një pjesë thelbësore e grupit të monitorimit. Ato zvogëlojnë kompleksitetin, vonesën dhe koston e pyetjeve. Ato janë gjithashtu të përshtatshme për përdoruesit që të marrin të dhëna të grumbulluara sipas metrikës. Thanos bazohet në shembujt e Prometheus me vanilje, kështu që është krejtësisht e pranueshme që të ruhen rregullat e regjistrimit dhe rregullat e sinjalizimit në një server ekzistues Prometheus. Sidoqoftë, në disa raste kjo mund të mos jetë e mjaftueshme:
- Sinjalizim dhe rregull global (për shembull, një sinjalizim kur një shërbim nuk funksionon në më shumë se dy nga tre grupimet).
- Rregulli për të dhënat jashtë ruajtjes lokale.
- Dëshira për të ruajtur të gjitha rregullat dhe sinjalizimet në një vend.
Për të gjitha këto raste, Thanos përfshin një komponent të veçantë të quajtur Ruler, i cili llogarit rregullin dhe alarmin nëpërmjet Thanos Queries. Duke ofruar një StoreAPI të mirënjohur, nyja Query mund të aksesojë metrikat e llogaritura rishtazi. Më vonë ato ruhen gjithashtu në ruajtjen e objekteve dhe vihen në dispozicion përmes portës së dyqanit.
Fuqia e Thanos
Thanos është mjaft fleksibël për t'u përshtatur për t'iu përshtatur nevojave tuaja. Kjo është veçanërisht e dobishme kur migroni nga Prometeu i thjeshtë. Le të përmbledhim shpejt atë që kemi mësuar rreth komponentëve të Thanos me një shembull të shpejtë. Ja se si ta çoni Prometheun tuaj të vaniljes në botën e "ruajtjes së pakufizuar të metrikës":
- Shtoni Thanos Sidecar në serverët tuaj Prometheus - për shembull, një kontejnerë me karrige anësore në një pod Kubernetes.
- Vendosni kopje të shumta Thanos Querier për të qenë në gjendje të shikoni të dhënat. Në këtë fazë është e lehtë të vendosësh thashetheme midis Scraper dhe Querier. Për të kontrolluar ndërveprimin e komponentëve, përdorni metrikën 'thanos_cluster_members'.
Vetëm këta dy hapa janë të mjaftueshëm për të ofruar pamje globale dhe heqje të pandërprerë të të dhënave nga kopjet e mundshme të Prometheus HA! Thjesht lidhni pultet tuaja me pikën përfundimtare të Querier HTTP ose përdorni drejtpërdrejt ndërfaqen e Thanos.
Sidoqoftë, nëse keni nevojë për kopje rezervë të metrikës dhe ruajtje afatgjatë, do t'ju duhet të përfundoni tre hapa të tjerë:
- Krijoni një kovë AWS S3 ose GCS. Konfiguro Sidecar për të kopjuar të dhënat në këto kova. Ruajtja lokale e të dhënave tani mund të minimizohet.
- Vendosni Store Gateway dhe lidheni atë me grupin tuaj ekzistues të thashethemeve. Tani mund të kërkoni të dhënat e rezervuara!
- Vendosni Compactor për të përmirësuar efikasitetin e pyetjeve për periudha të gjata kohore duke përdorur ngjeshjen dhe zvogëlimin e mostrave.
Nëse dëshironi të dini më shumë, mos hezitoni të hidhni një sy tek ne и !
Në vetëm pesë hapa, ne e kthyem Prometheus në një sistem monitorimi të besueshëm me pamje globale, kohë të pakufizuar ruajtjeje dhe disponueshmëri të lartë potenciale të metrikës.
Kërkesa e tërheqjes: ne kemi nevojë për ju!
ka qenë një projekt me kod të hapur që në fillim. Integrimi pa probleme me Prometheus dhe aftësia për të përdorur vetëm një pjesë të Thanos e bën atë një zgjedhje të shkëlqyer për shkallëzimin e sistemit tuaj të monitorimit pa mundim.
Ne gjithmonë mirëpresim kërkesat dhe problemet e tërheqjes së GitHub. Ndërkohë, mos ngurroni të na kontaktoni përmes Çështjeve të Github ose Slacknëse keni pyetje ose komente, ose dëshironi të ndani përvojën tuaj duke e përdorur atë! Nëse ju pëlqen ajo që bëjmë në Improbable, mos hezitoni të na kontaktoni - !
Burimi: www.habr.com