Shën. përk.: Po prezantoni detajet teknike mbi shkaqet e fundit të ndërprerjes së shërbimit të cloud, i shërbyer nga krijuesit e Grafana. Ky është një shembull klasik se si një mundësi e re dhe, për sa duket, tejet e dobishme, e krijuar për të përmirësuar cilësinë e infrastrukturës... mund të dëmtojë, nëse nuk merren parasysh nuancat e shumta të përdorimit të saj në realitetin e produksionit. Këto materiale janë të shkëlqyera, duke na lejuar të mësojmë jo vetëm nga gabimet tona. Detajet janë në përkthimin e këtij teksti nga zv.presidenti për produktin nga Grafana Labs.
Në të premten, më 19 korrik, shërbimi Hosted Prometheus në Grafana Cloud ndaloi funksionimin për rreth 30 minuta. Kërkoj ndjesë nga të gjithë klientët e prekur nga kjo ndërprerje. Detyra jonë është të ofrojmë mjetet e nevojshme për monitorim, dhe ne kuptojmë se mungesa e tyre e bën jetën tuaj më të vështirë. Ne i marrim shumë seriozisht këto incidente. Në këtë shënim shpjegohet se çfarë ndodhi, si reaguam dhe çfarë po bëjmë për të siguruar që një gjë e tillë të mos ndodhë më.
Pas historia
ShĂ«rbimi Grafana Cloud Hosted Prometheus Ă«shtĂ« i bazuar nĂ« â projektin CNCF pĂ«r krijimin e njĂ« shĂ«rbimi Prometheus horizontalisht tĂ« shkallĂ«zuar, me disponueshmĂ«ri tĂ« lartĂ« dhe multitenant. Arsyetimi i Cortex-it pĂ«rbĂ«het nga njĂ« grup mikroshĂ«rbesh tĂ« ndara, secili nga tĂ« cilat kryen funksionin e tij: replikimin, ruajtjen, kĂ«rkesat etj. Cortex po zhvillohet aktivisht, me mundĂ«si tĂ« reja dhe rritje tĂ« performancĂ«s qĂ« shfaqen vazhdimisht. Ne rregullisht bĂ«nim zhvillime tĂ« reja tĂ« Cortex nĂ« klastere, nĂ« mĂ«nyrĂ« qĂ« klientĂ«t tĂ« mund tĂ« pĂ«rfitojnĂ« nga kĂ«to mundĂ«si â fatkeqĂ«sisht, Cortex Ă«shtĂ« nĂ« gjendje tĂ« pĂ«rditĂ«sohet pa ndĂ«rprerje.
PĂ«r pĂ«rditĂ«sime pa ndĂ«rprerje, shĂ«rbimi Ingester i Cortex-it kĂ«rkon njĂ« replikĂ« shtesĂ« tĂ« Ingester gjatĂ« procesit tĂ« pĂ«rditĂ«simit. (ShĂ«n. pĂ«rk.: â komponenti bazĂ« i Cortex-it. Detyra e tij Ă«shtĂ« tĂ« mbledhĂ« njĂ« fluks tĂ« vazhdueshĂ«m tĂ« mostra, t'i grupojĂ« ato nĂ« chunk-e tĂ« Prometheus dhe t'i ruajĂ« nĂ« njĂ« bazĂ« tĂ« dhĂ«nash si DynamoDB, BigTable ose Cassandra.) Kjo lejon IngesterĂ«t e vjeter tĂ« çojnĂ« tĂ« dhĂ«nat aktuale te IngesterĂ«t e rinj. Duhet theksuar se IngesterĂ«t janĂ« kĂ«rkesĂ« tĂ« lartĂ« pĂ«r burime. PĂ«r operimin e tyre, nevojitet tĂ« kemi 4 bĂ«rthama dhe 15 GB kujtesĂ« pĂ«r pod, pra 25% tĂ« kapacitetit procesor dhe memorie tĂ« makinĂ«s bazĂ« nĂ« rastin e klastereve tona Kubernetes. NĂ« tĂ«rĂ«si, ne zakonisht kemi shumĂ« mĂ« tepĂ«r burime tĂ« papĂ«rdorura nĂ« klaster se sa 4 bĂ«rthama dhe 15 GB kujtesĂ«, prandaj ne mund tĂ« aktivizojmĂ« kĂ«ta IngesterĂ« shtesĂ« lehtĂ«sisht gjatĂ« pĂ«rditĂ«simeve.
Megjithatë, shpesh ndodh që gjatë punës normale, asnjë nga makinat nuk ka këto 25% burime të padobishme. Ne anche nuk jemi të interesuar për to: CPU dhe memoria do të jenë gjithmonë të nevojshme për procese të tjera. Për të zgjidhur këtë problem, ne vendosëm të shfrytëzojmë . Ideja është të jepen Ingesterëve një prioritet më të lartë se mikroshërbebe të tjera (stateless). Kur na nevojitet të aktivizojmë një Ingester shtesë (N+1), ne përkohësisht zhvendosim të tjerët, podë të vogla. Këto podë zhvendosen në burime të lira në makinat e tjera, duke lënë një 'vrimë' mjaft të madhe për të aktivizuar një Ingester shtesë.
Në të enjten, më 18 korrik, ne vendosëm katër nivele të reja prioritetesh në klasteret tona: kritik, niveli, mesatar dhe i ulët. Ata u testuan në një klaster të brendshëm pa trafik klientësh për rreth një javë. Nga default, podët pa prioritet të vendosur merrnin mesatar prioritet, për Ingesterët u vendos një klasë me të lartë prioritet. Kritik u rezervua për monitorimin (Prometheus, Alertmanager, node-exporter, kube-state-metrics etj.). Konfigurimi ynë është i hapur, dhe mund të shihni PR-në .
DĂ«shtimi
NĂ« tĂ« premten, mĂ« 19 korrik, njĂ« nga inxhinierĂ«t aktivizoi njĂ« klaster tĂ« ri tĂ« dedikuar tĂ« Cortex pĂ«r njĂ« klient tĂ« madh. Konfigurimi pĂ«r kĂ«tĂ« klaster nuk pĂ«rfshinte prioritetet e reja tĂ« podĂ«ve, prandaj tĂ« gjithĂ« podĂ«t e rinj morĂ«n prioritetin e paracaktuar â mesatar.
Në klasterin Kubernetes mungonin burimet për klasterin e ri të Cortex, dhe klasteri aktual i produksionit të Cortex nuk ishte përditësuar (Ingesterët mbetën pa të lartë prioritet). Duke qenë se Ingesterët e klasterit të ri patën si default prioriteti, ndërsa podët ekzistues në produksion punonin pa prioritet fare, Ingesterët e klasterit të ri zhvendosën Ingesterët nga klasteri ekzistues i produksionit të Cortex-it. mesatar prioritet, ndërsa pod'ët ekzistues në production punonin pa ndonjë prioritet, Ingester't e klasterit të ri larguan Ingester nga klasteri ekzistues i production-it Cortex.
ReplicaSet për Ingesterin e zhvendosur në klasterin e produksionit zbuloi pod-in e zhvendosur dhe krijoi një të ri për të ruajtur numrin e caktuar të kopjeve. Pod-it të ri i u dha automatikisht një mesatar prioritet, dhe një 'i vjetër' Ingester në produksion humbi burimet. Rezultati ishte një proces kaskadë, i cili çoi në zhvendosjen e të gjithë podëve me Ingester për klasteret e produksionit të Cortex-it.
Ingester't ruajnë gjendjen (stateful) dhe mbajnë të dhëna për 12 orët e fundit. Kjo na lejon të kompresojmë më efektivisht para se t'i shkruajmë në magazinën afatgjatë. Për këtë Cortex kryen sharding të të dhënave sipas serive, duke përdorur një tabelë hash të shpërndarë (Distributed Hash Table, DHT), dhe replikon çdo seri në tri Ingester'a me konsensus të kuorumit në stilin Dynamo. Cortex nuk shkruan të dhëna në Ingester't që janë të çaktivizuar. Kështu, kur një numër i madh Ingester'ash ndahen nga DHT, Cortex nuk mund të sigurojë replikimin e mjaftueshëm të të dhënave, dhe ato 'bien'.
Zbulimi dhe zgjidhja
Njoftimet e reja tĂ« Prometheus bazuar nĂ« 'buxhetin e gabimeve' (error-budget-based â detajet do tĂ« shfaqen nĂ« njĂ« artikull tĂ« ardhshĂ«m) filluan tĂ« alarmojnĂ« pas 4 minutash nga fillimi i çaktivizimit. GjatĂ« pesĂ« minutave tĂ« ardhshme, ne bĂ«mĂ« diagnostikim dhe rritĂ«m klasterin e Kubernetes pĂ«r tĂ« akomoduar si klasterĂ«t e ri, ashtu edhe ata ekzistues tĂ« production-it.
Edhe pesë minuta më pas, Ingester't e vjetër kanë regjistruar me sukses të dhënat e tyre, ndërsa të rinjtë u aktivizuan, dhe klasterët Cortex u bënë përsëri të disponueshëm.
Përsëri 10 minuta kaluan për diagnostikimin dhe zgjidhjen e gabimeve out-of-memory (OOM) nga serverët e prapavijës së autentifikimit, të vendosur para Cortex. Gabimet OOM u shkaktuan nga rritja dhjetëfish të QPS (siç mendojmë, për shkak të kërkesave tepër agresive nga serverët Prometheus të klientëve).
Pasojat
Kohëzgjatja totale e ndërprerjes ishte 26 minuta. Të dhënat nuk u humbën. Ingester't arritën të ngarkojnë me sukses të gjitha të dhënat in-memory në magazinën afatgjatë. Gjatë ndërprerjes, serverët Prometheus të klientëve ruajtën në buffer regjistrimet e (remote) me anë të të bazuar në WAL (të autorit nga Grafana Labs) dhe ripërsëritën regjistrimet e dështuara pas dështimit.
Operacionet e regjistrimit të klasterit të production-it
PĂ«rfundimet
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« nxjerrim mĂ«sime nga ky incident dhe tĂ« marrim masat e nevojshme pĂ«r tĂ« shmangur pĂ«rsĂ«ritjen e tij.
Duke u kthyer mbrapa, duhet të pranojmë se nuk duhej të vendosnim me default mesatar prioritet, derisa të gjithë Ingester't në production të merrnin niveli prioritet. Për më tepër, duhej kujdesur paraprakisht për prioritetin e tyre të lartë. Tani gjithçka është rregulluar. Shpresojmë që përvoja jonë do të ndihmojë organizatat e tjera që po shqyrtojnë përdorimin e prioriteteve të pod'ëve në Kubernetes.
Ne do tĂ« shtojmĂ« njĂ« nivel tĂ« konsiderueshĂ«m kontrolli mbi shpĂ«rndarjen e çdo objekti shtesĂ«, tĂ« cilat konfigurimet e tyre janĂ« globale pĂ«r klasterin. NĂ« tĂ« ardhmen, ndryshime tĂ« tilla do tĂ« vlerĂ«sohen ngaonjĂ« numĂ«r mĂ« tĂ« madh njerĂ«zish. PĂ«r mĂ« tepĂ«r, modifikimi qĂ« çoi nĂ« dĂ«shtim u konsiderua tepĂ«r i vogĂ«l pĂ«r njĂ« dokument projekti tĂ« veçantĂ« â u diskutua vetĂ«m nĂ« çështjen GitHub. Nga ky moment e tutje, tĂ« gjitha ndryshimet e tilla tĂ« konfigurimeve do tĂ« shoqĂ«rohen me dokumentacionin pĂ«rkatĂ«s tĂ« projektit.
Më në fund, ne do të automatizojmë rritjen e madhësisë së serverit të prapavijës së autentifikimit për të parandaluar OOM gjatë ngarkesës, të cilët ishim dëshmitarë, dhe do të analizojmë parametrat default të Prometheus që lidhen me rënien dhe shumimin, për të parandaluar probleme të ngjashme në të ardhmen.
DĂ«shtimi i pĂ«rjetuar kishte gjithashtu disa pasoja pozitive: duke marrĂ« burimet e nevojshme, Cortex u rikuperua automatikisht pa ndihmĂ« shtesĂ«. Ne gjithashtu morĂ«m pĂ«rvojĂ« tĂ« çmuar nĂ« punĂ«n me â sistemin tonĂ« tĂ« ri tĂ« agregatĂ«s sĂ« logjeve, â i cili ndihmoi tĂ« sigurojmĂ« qĂ« tĂ« gjithĂ« Ingester't u sjellĂ«n siç duhej gjatĂ« dhe pas dĂ«shtimit.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
