Shënim. përkth.: Ne paraqesim në vëmendjen tuaj detaje teknike në lidhje me arsyet e ndërprerjes së fundit në shërbimin cloud të mbajtur nga krijuesit e Grafana. Ky është një shembull klasik se si një veçori e re dhe në dukje jashtëzakonisht e dobishme e krijuar për të përmirësuar cilësinë e infrastrukturës... mund të shkaktojë dëm nëse nuk parashikoni nuancat e shumta të zbatimit të tij në realitetet e prodhimit. Është mirë kur shfaqen materiale të tilla që ju lejojnë të mësoni jo vetëm nga gabimet tuaja. Detajet janë në përkthimin e këtij teksti nga nënkryetari i produktit nga Grafana Labs.
Të premten, më 19 korrik, shërbimi i Hosted Prometheus në Grafana Cloud pushoi së funksionuari për afërsisht 30 minuta. Kërkoj falje për të gjithë klientët e prekur nga ndërprerja. Detyra jonë është të ofrojmë mjetet e monitorimit që ju nevojiten dhe ne e kuptojmë se mos disponueshmëria e tyre mund ta bëjë jetën tuaj më të vështirë. Ne e marrim këtë incident jashtëzakonisht seriozisht. Ky shënim shpjegon se çfarë ndodhi, si u përgjigjëm dhe çfarë po bëjmë për të siguruar që të mos ndodhë më.
parahistorinë
Grafana Cloud Hosted Shërbimi Prometheus bazohet në — Projekti CNCF për të krijuar një shërbim Prometheus të shkallëzuar horizontalisht, shumë të disponueshëm, me shumë qiramarrës. Arkitektura Cortex përbëhet nga një grup mikroshërbimesh individuale, secila prej të cilave kryen funksionin e vet: replikimin, ruajtjen, pyetjet, etj. Cortex është në zhvillim aktiv dhe po shton vazhdimisht veçori të reja dhe po përmirëson performancën. Ne vendosim rregullisht lëshimet e reja të Cortex në grupe, në mënyrë që klientët të mund të përfitojnë nga këto veçori - për fat të mirë, Cortex mund të përditësohet pa ndërprerje.
Për përditësime pa probleme, shërbimi Ingester Cortex kërkon një kopje shtesë të Ingester gjatë procesit të përditësimit. (Shënim. përkth.: - komponenti bazë i korteksit. Detyra e tij është të mbledhë një rrjedhë të vazhdueshme mostrash, t'i grupojë ato në copa Prometheus dhe t'i ruajë në një bazë të dhënash si DynamoDB, BigTable ose Cassandra.) Kjo i lejon gëlltitësit e vjetër të përcjellin të dhënat aktuale te gëlltitësit e rinj. Vlen të përmendet se gëlltitësit kërkojnë burime. Që ato të funksionojnë, duhet të keni 4 bërthama dhe 15 GB memorie për pod, d.m.th. 25% e fuqisë përpunuese dhe kujtesës së makinës bazë në rastin e grupimeve tona Kubernetes. Në përgjithësi, ne zakonisht kemi shumë më tepër burime të papërdorura në grup sesa 4 bërthama dhe 15 GB memorie, kështu që ne mund t'i rrotullojmë lehtësisht këto injeksione shtesë gjatë përmirësimeve.
Megjithatë, shpesh ndodh që gjatë funksionimit normal asnjë nga makineritë nuk e ka këtë 25% të burimeve të papërdorura. Po, ne as nuk përpiqemi: CPU dhe memoria do të jenë gjithmonë të dobishme për procese të tjera. Për të zgjidhur këtë problem, ne vendosëm të përdorim . Ideja është t'i jepet ingesters një prioritet më i lartë se mikroshërbimet e tjera (pa shtetësi). Kur na duhet të ekzekutojmë një gëlltitës shtesë (N+1), ne zhvendosim përkohësisht grupe të tjera më të vogla. Këto pods transferohen në burime të lira në makina të tjera, duke lënë një "vrimë" mjaft të madhe për të ekzekutuar një Ingester shtesë.
Të enjten, më 18 korrik, ne përcaktuam katër nivele të reja prioritare për grupimet tona: kritike, i lartë, средний и ulët. Ata u testuan në një grup të brendshëm pa trafik klientësh për rreth një javë. Si parazgjedhje, morën pods pa një prioritet të caktuar средний prioritet, klasa u caktua për gëlltitësit me i lartë prioritet. Kritike ishte e rezervuar për monitorim (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etj.). Konfigurimi ynë është i hapur dhe ju mund të shikoni PR .
aksident
Të premten, më 19 korrik, një nga inxhinierët lançoi një grup të ri të dedikuar Cortex për një klient të madh. Konfigurimi për këtë grup nuk përfshin prioritetet e reja të pod, kështu që të gjitha grupeve të reja iu caktua një prioritet i paracaktuar - средний.
Grupi Kubernetes nuk kishte burime të mjaftueshme për grupin e ri Cortex, dhe grupi ekzistues i prodhimit Cortex nuk u përditësua (Ingesters mbetën pa lartë prioritet). Meqenëse ingesters e grupit të ri si parazgjedhje kishin средний prioritet, dhe pods ekzistues në prodhim funksionuan pa prioritet fare, Gëlltitësit e grupit të ri zëvendësuan gëlltitësit nga grupi ekzistues i prodhimit Cortex.
ReplicaSet për Ingester-in e dëbuar në grupin e prodhimit zbuloi podin e dëbuar dhe krijoi një të ri për të ruajtur numrin e specifikuar të kopjeve. Pozicioni i ri u caktua si parazgjedhje средний prioritet, dhe një tjetër Ingester "i vjetër" në prodhim humbi burimet e tij. Rezultati ishte procesi i ortekut, e cila çoi në zhvendosjen e të gjitha pods nga Ingester për grupimet e prodhimit Cortex.
Gëlltitësit janë të gjendjes dhe ruajnë të dhënat për 12 orët e mëparshme. Kjo na lejon t'i ngjeshim ato në mënyrë më efikase përpara se t'i shkruajmë në ruajtje afatgjatë. Për ta arritur këtë, Cortex copëton të dhënat nëpër seri duke përdorur një Tabelë Hash të Shpërndar (DHT) dhe përsërit secilën seri në tre gëlltitës duke përdorur konsistencën e kuorumit të stilit Dynamo. Cortex nuk u shkruan të dhëna ingesters që janë të çaktivizuar. Kështu, kur një numër i madh ingesters largohen nga DHT, Cortex nuk mund të sigurojë përsëritje të mjaftueshme të hyrjeve dhe ato rrëzohen.
Zbulimi dhe riparimi
Njoftimet e reja të Prometheus bazuar në "buxhetin e gabimit" (bazuar në buxhetin e gabimeve — detajet do të shfaqen në një artikull të ardhshëm) filloi të bjerë alarmi 4 minuta pas fillimit të mbylljes. Gjatë pesë minutave të ardhshme ose më shumë, ne kryem disa diagnostifikime dhe rritëm grupin themelor të Kubernetes për të pritur grupet e reja dhe ekzistuese të prodhimit.
Pas pesë minutash të tjera, gëlltitësit e vjetër shkruan me sukses të dhënat e tyre, të rejat filluan dhe grupet Cortex u bënë sërish të disponueshme.
10 minuta të tjera u shpenzuan për diagnostikimin dhe korrigjimin e gabimeve jashtë kujtesës (OOM) nga përfaqësuesit e kundërt të vërtetimit të vendosura përpara Cortex. Gabimet OOM u shkaktuan nga një rritje dhjetëfish e QPS (besojmë për shkak të kërkesave tepër agresive nga serverët Prometheus të klientit).
Последствия
Koha totale e pushimit ishte 26 minuta. Asnjë e dhënë nuk humbi. Gëlltitësit kanë ngarkuar me sukses të gjitha të dhënat në memorie në ruajtje afatgjatë. Gjatë mbylljes, serverët e klientit Prometheus u fshinë në tampon (nga distanca) regjistrimet duke përdorur bazuar në WAL (autor nga nga Grafana Labs) dhe përsëriti shkrimet e dështuara pas rrëzimit.
Operacionet e shkrimit të grupit të prodhimit
Gjetjet
Është e rëndësishme të mësoni nga ky incident dhe të merrni hapat e nevojshëm për të shmangur përsëritjen e tij.
Në pamje të pasme, ne nuk duhet të kishim vendosur parazgjedhjen средний prioritet derisa të kenë marrë të gjithë gëlltitësit në prodhim i lartë një prioritet. Përveç kësaj, ishte e nevojshme të kujdeseshim paraprakisht për ta lartë prioritet. Gjithçka është rregulluar tani. Shpresojmë që përvoja jonë do të ndihmojë organizatat e tjera që konsiderojnë përdorimin e prioriteteve të pod në Kubernetes.
Ne do të shtojmë një nivel shtesë kontrolli mbi vendosjen e çdo objekti shtesë, konfigurimet e të cilëve janë globale në grup. Tash e tutje këto ndryshime do të vlerësohen bоme shume njerez. Për më tepër, modifikimi që shkaktoi rrëzimin u konsiderua shumë i vogël për një dokument të veçantë projekti - ai u diskutua vetëm në një çështje të GitHub. Tani e tutje, të gjitha ndryshimet e tilla në konfigurime do të shoqërohen me dokumentacionin e duhur të projektit.
Së fundi, ne do të automatizojmë ndryshimin e madhësisë së përfaqësuesit të kundërt të vërtetimit për të parandaluar mbingarkimin e OOM-it që dëshmuam dhe do të shqyrtojmë cilësimet e paracaktuara të Prometheus në lidhje me kthimin dhe shkallëzimin për të parandaluar probleme të ngjashme në të ardhmen.
Dështimi pati gjithashtu disa pasoja pozitive: pasi kishte marrë burimet e nevojshme, Cortex u rikuperua automatikisht pa ndërhyrje shtesë. Ne gjithashtu fituam përvojë të vlefshme duke punuar me të - Sistemi ynë i ri i grumbullimit të regjistrave - i cili ndihmoi të sigurohej që të gjithë gëlltitësit të silleshin siç duhet gjatë dhe pas dështimit.
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com