ShĂ«n. pĂ«rkth.: Ju sjellim pĂ«r ju detajet teknike mbi arsyet e fundit tĂ« ndaljes nĂ« funksionimin e shĂ«rbimit cloud, tĂ« mbajtur nga krijuesit e Grafana. Ky Ă«shtĂ« njĂ« shembull klasik se si njĂ« mundĂ«si e re, dukshĂ«m e dobishme, e krijuar pĂ«r tĂ« pĂ«rmirĂ«suar cilĂ«sinĂ« e infrastrukturĂ«s... mund tĂ« dĂ«mtojĂ«, nĂ«se nuk parashikohet numri i madh i nuancave tĂ« aplikimit tĂ« saj nĂ« realitetin e prodhimit. ĂshtĂ« e shkĂ«lqyer kur shfaqen materiale tĂ« tilla, qĂ« lejojnĂ« tĂ« mĂ«sojmĂ« jo vetĂ«m nga gabimet tona. Detajet janĂ« nĂ« pĂ«rkthimin e kĂ«tij teksti nga nĂ«n-presidenti pĂ«r produktet nĂ« Grafana Labs.
Në të premten, 19 korrik, shërbimi Hosted Prometheus në Grafana Cloud ndaloi të funksiononte për rreth 30 minuta. Më vjen keq për të gjithë klientët që u preken nga ky ndërprerje. Detyra jonë është të ofrojmë mjetet e duhura për monitorim, dhe ne e kuptojmë se mosdisponueshmëria e tyre e komplikon jetën tuaj. Ne e marrim shumë seriozisht këtë incident. Në këtë shënim shpjegohet se çfarë ndodhi, si reaguam dhe çfarë po bëjmë që kjo të mos ndodhë më.
Historia e mëparshme
ShĂ«rbimi Grafana Cloud Hosted Prometheus bazohet nĂ« â projektin CNCF pĂ«r krijimin e njĂ« shĂ«rbimi Prometheus me shkallĂ«zim horizontal, me disponueshmĂ«ri tĂ« lartĂ« dhe shumĂ«-qiramarrĂ«s (multi-tenant). Arkitektura Cortex pĂ«rbĂ«het nga njĂ« grup mikroshĂ«rbimesh, secili prej tĂ« cilĂ«ve kryen funksionin e tij: riplikimi, ruajtja, kĂ«rkesat etj. Cortex Ă«shtĂ« nĂ« zhvillim aktiv, vazhdimisht po shfaqen mundĂ«si tĂ« reja dhe rritet performanca. Ne rregullisht nxjerrim versione tĂ« reja tĂ« Cortex nĂ« klasterĂ«, nĂ« mĂ«nyrĂ« qĂ« klientĂ«t tĂ« mund tĂ« pĂ«rfitojnĂ« nga kĂ«to mundĂ«si â fatmirĂ«sisht, Cortex di 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-it gjatĂ« procesit tĂ« pĂ«rditĂ«simit. (ShĂ«n. pĂ«rkth.: â komponenti bazĂ« i Cortex-it. Detyra e tij Ă«shtĂ« tĂ« grumbullojĂ« njĂ« rrjedhĂ« tĂ« vazhdueshme sample-sh, t'i grupojĂ« ato nĂ« chunk-e Prometheus dhe t'i ruajĂ« nĂ« njĂ« bazĂ« tĂ« dhĂ«nash si DynamoDB, BigTable ose Cassandra.) Kjo lejon ingesterĂ«t e vjetĂ«r tĂ« dĂ«rgojnĂ« tĂ« dhĂ«nat aktuale te ingesterĂ«t e rinj. Vlen tĂ« theksohet se ingesterĂ«t janĂ« kĂ«rkues ndaj burimeve. PĂ«r funksionimin e tyre Ă«shtĂ« e nevojshme tĂ« kem 4 bĂ«rthama dhe 15 GB memorie pĂ«r pod, dmth. 25% e kapacitetit tĂ« procesorit dhe memories sĂ« makinĂ«s bazĂ« nĂ« rastin e klasterĂ«ve tanĂ« Kubernetes. NĂ« pĂ«rgjithĂ«si, ne zakonisht kemi shumĂ« mĂ« shumĂ« burime tĂ« pandĂ«rprera nĂ« klaster sesa 4 bĂ«rthama dhe 15 GB memorie, prandaj mund tĂ« nisnim lehtĂ«sisht kĂ«ta ingesterĂ« shtesĂ« gjatĂ« pĂ«rditĂ«simeve.
Megjithatë, shpesh ndodh që gjatë punës normale asnjë nga makinat nuk ka këto 25% burime të papërdorura. Po ashtu, ne nuk përpiqemi: CPU dhe memoria gjithmonë do të jenë të nevojshme për procese të tjera. Për të zgjidhur këtë problem, ne vendosëm të përdorim . Ideja është të caktojmë ingesterëve një prioritet më të lartë sesa mikroshërbimeve të tjera (stateless). Kur na nevojitet të nisim një ingester tjetër (N+1), ne përkohësisht zhvendosim pod-ët e tjerë më të vogla. Këta pod-ë transferohen në burimet e lira në makina të tjera, duke lënë një "hapësirë" mjaft të madhe për të nisur ingesterin shtesë.
Më 18 korrik, ne lançuam katër nivele të reja prioriteti në klasterët tanë: kritik, një, mesatar dhe i ulët. Ato u testuan në klasterin tonë të brendshëm pa trafik klientësh për rreth një javë. Në mënyrë të paracaktuar, pod-ët pa prioritet të caktuar merrnin mesatar prioritet, për ingesterët ishte caktuar një klasë me të lartë Rregulli 4a: Nëse detyra përdor të gjithë dritaren e saj të caktuar kohore, atëherë prioriteti i saj Kritik ishte rezervuar për monitorimin (Prometheus, Alertmanager, node-exporter, kube-state-metrics etj.). Konfigurat tona janë të hapura, dhe mund të shihni PR-në .
Aksidente
Më 19 korrik, një nga inxhinierët nisi një klaster të ri të dedikuar 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 nuk kishte mjaft burime për klasterin e ri Cortex, dhe klasteri ekzistues i prodhimit Cortex nuk ishte përditësuar (ingesterët mbetën pa të lartë prioritet). Duke qenë se ingesterët e klasterit të ri kishin për parazgjedhje mesatar prioritet, dhe pod-ët ekzistues në prodhim punonin krejtësisht pa prioritet, ingesterët e klasterit të ri zhvendosën ingesterin nga klasteri ekzistues i prodhimit Cortex.
ReplicaSet për ingester-in e dëbuar në klasterin production zbuloi podin e dëbuar dhe krijoi një të ri për të mbajtur numrin e caktuar të kopjeve. Pod-i i ri iu caktua mesatar prioriteti, dhe Ingester-i «i vjetër» në production humbi burimet. Rezultati ishte një proces avullues, i cili çoi në dëbimin e të gjithë pod-eve me Ingester për klasteret production të Cortex-it.
Ingester-at mbajnĂ« gjendjen (stateful) dhe ruajnĂ« tĂ« dhĂ«nat pĂ«r 12 orĂ«t e kaluara. Kjo na lejon tĂ« kompresojmĂ« mĂ« efikasht ato para se tĂ« shkruhen nĂ« ruajtjen afatgjatĂ«. PĂ«r kĂ«tĂ«, Cortex realizon ndarjen e tĂ« dhĂ«nave sipas serive, duke pĂ«rdorur njĂ« tabelĂ« tĂ« shpĂ«rndarĂ« hash (Distributed Hash Table, DHT), dhe riprodhon çdo seri nĂ« tre Ingester-a me ndihmĂ«n e konsensusit tĂ« kuorumit nĂ« stilin Dynamo. Cortex nuk shkruan tĂ« dhĂ«na nĂ« Ingester-at qĂ« janĂ« fikur. KĂ«shtu, kur numri i madh i Ingester-ave largohet nga DHT, Cortex nuk mund tĂ« sigurojĂ« mjaftueshĂ«m riprodhim tĂ« regjistrimeve, dhe ato âbienâ.
Zbulimi dhe eliminimi
Njoftimet e reja tĂ« Prometheus qĂ« bazohen nĂ« âbuxhetin e gabimeveâ (error-budget-based â detajet do tĂ« shfaqen nĂ« njĂ« artikull tĂ« ardhshĂ«m) filluan tĂ« japin alarmin pas 4 minutash nga fillimi i fikjes. GjatĂ« pesĂ« minutave tĂ« ardhshme, ne realizuam diagnostikimin dhe rritĂ«m klasterin Kubernetes tĂ« poshtĂ«m pĂ«r tĂ« mbajtur si klasterat production tĂ« rinj ashtu edhe ata ekzistues.
Pas pesë minutash, Ingester-at e vjetër shkruan me sukses të dhënat e tyre, ndërsa të rinjtë u aktivizuan, dhe klasteret Cortex u bënë përsëri të disponueshëm.
Një tjetër 10 minuta u desh për diagnostikimin dhe rregullimin e gabimeve out-of-memory (OOM) nga serverët e përparmë të autentikimit që ndodheshin përpara Cortex. Gabimet OOM ishin shkaktuar nga rritja dhjetëfish e QPS (siç besojmë, 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-at ngarkuan me sukses të gjitha të dhënat në memory në ruajtjen afatgjatë. Gjatë ndërprerjes, serverët Prometheus të klientëve ruajtën në buffer regjistrimet e largëta (remote) përmes të bazuar në WAL (të autorësisë nga Grafana Labs) dhe përsëritën regjistrimet e dështuar pas çrregullimit.
Operacionet e shkruar të klasterit production
PĂ«rfundimet
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« nxirren mĂ«sime nga ky incident dhe tĂ« ndĂ«rmerren veprimet e nevojshme pĂ«r tĂ« parandaluar pĂ«rsĂ«ritjen e tij.
Duke shikuar prapa, duhet të pranojmë se nuk duhej të vendosnim përparësi si parazgjedhje mesatar derisa të gjithë Ingesterët në prodhim nuk morën një prioritet. Për më tepër, duhej të ishim kujdesur 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ë mundësinë e përdorimit të prioriteteve të podëve në Kubernetes.
Ne do tĂ« shtojmĂ« njĂ« nivel tĂ« shtuar kontrolli mbi implementimin e çdo objekti shtesĂ«, konfigurimet e tĂ« cilĂ«ve janĂ« globale pĂ«r klasterin. NĂ« tĂ« ardhmen, ndryshime tĂ« tilla do tĂ« vlerĂ«sohen ngaonjĂ« numĂ«r mĂ« i madh njerĂ«zish. PĂ«r mĂ« tepĂ«r, modifikimi qĂ« çoi nĂ« dĂ«shtim u konsiderua tepĂ«r i parĂ«ndĂ«sishĂ«m pĂ«r njĂ« dokument projektimi tĂ« veçantĂ« â u diskutua vetĂ«m nĂ« GitHub issue. Nga ky moment e tutje, tĂ« gjitha ndryshimet e tilla tĂ« konfigurove do tĂ« shoqĂ«rohen me dokumentacionin pĂ«rkatĂ«s tĂ« projektit.
Në fund, do të automatizojmë rritjen e serverit të përparësisë për të parandaluar OOM gjatë mbingarkesës, të cilët ishim dëshmitarë, dhe do të analizojmë parametrat e Prometheus-it në parazgjedhje, që lidhen me rikthimin dhe dimensionimin, për të parandaluar probleme të ngjashme në të ardhmen.
DĂ«shtimi qĂ« kaluam kishte edhe disa pasoja pozitive: duke pasur burimet e nevojshme, Cortex u rikuperua automatikisht pa ndĂ«rhyrje tĂ« mĂ«tejshme. Ne gjithashtu morĂ«m pĂ«rvojĂ« tĂ« vyer nĂ« punĂ«n me â sistemin tonĂ« tĂ« ri tĂ« agregimit tĂ« log-eve, â qĂ« ndihmoi nĂ« konfirmimin se tĂ« gjithĂ« IngesterĂ«t u sollĂ«n siç duhet gjatĂ« dhe pas dĂ«shtimit.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
