Bilješka. transl.: Predstavljamo Vam tehničke detalje o razlozima nedavnog zastoja u cloud servisu koje su održavali kreatori Grafane. Ovo je klasičan primjer kako nova i naizgled izuzetno korisna funkcija dizajnirana da poboljša kvalitet infrastrukture... može nanijeti štetu ako ne predvidite brojne nijanse njene primjene u stvarnosti proizvodnje. Sjajno je kada se pojave ovakvi materijali koji vam omogućavaju da učite ne samo na svojim greškama. Detalji su u prijevodu ovog teksta od potpredsjednika proizvoda Grafana Labs.
U petak, 19. jula, usluga Hosted Prometheus u Grafana Cloudu prestala je s radom na otprilike 30 minuta. Izvinjavam se svim kupcima pogođenim prekidom rada. Naš posao je da obezbijedimo alate za praćenje koji su vam potrebni, a mi razumijemo da vam nedostatak može otežati život. Ovaj incident shvatamo izuzetno ozbiljno. Ova napomena objašnjava šta se dogodilo, kako smo reagovali i šta činimo da se to više ne dogodi.
prapovijest
Grafana Cloud Hosted Prometheus usluga je zasnovana na — CNCF projekat za stvaranje horizontalno skalabilnog, visoko dostupnog Prometheus usluge sa više zakupaca. Cortex arhitektura se sastoji od skupa pojedinačnih mikroservisa, od kojih svaki obavlja svoju funkciju: replikaciju, skladištenje, upite, itd. Cortex je u aktivnom razvoju i stalno dodaje nove karakteristike i poboljšava performanse. Redovno implementiramo nova izdanja Cortexa u klastere kako bi korisnici mogli iskoristiti prednosti ovih funkcija - na sreću, Cortex se može ažurirati bez zastoja.
Za besprekorna ažuriranja, usluga Ingester Cortex zahteva dodatnu Ingester repliku tokom procesa ažuriranja. (Bilješka. transl.: - osnovna komponenta korteksa. Njegov posao je da prikupi konstantan tok uzoraka, grupiše ih u Prometheus komade i pohrani ih u bazu podataka poput DynamoDB, BigTable ili Cassandra.) Ovo omogućava starim Ingestersima da proslijede trenutne podatke novim Ingestersima. Vrijedi napomenuti da su Ingesteri zahtjevni za resurse. Da bi radili potrebno je da imate 4 jezgra i 15 GB memorije po pod, tj. 25% procesorske snage i memorije osnovne mašine u slučaju naših Kubernetes klastera. Generalno, obično imamo mnogo više neiskorištenih resursa u klasteru od 4 jezgra i 15 GB memorije, tako da možemo lako da pokrenemo ove dodatne ingeste tokom nadogradnje.
Međutim, često se dešava da tokom normalnog rada nijedna mašina nema ovih 25% neiskorišćenih resursa. Da, čak i ne težimo: CPU i memorija će uvijek biti korisni za druge procese. Kako bismo riješili ovaj problem, odlučili smo se za korištenje . Ideja je da se Ingestersu daju veći prioritet od ostalih (bez državnog) mikroservisa. Kada trebamo pokrenuti dodatni (N+1) Ingester, privremeno zamjenjujemo druge, manje mahune. Ovi podovi se prenose na slobodne resurse na drugim mašinama, ostavljajući dovoljno veliku „rupu“ za pokretanje dodatnog Ingestera.
U četvrtak, 18. jula, uveli smo četiri nova nivoa prioriteta za naše klastere: kritički, visoka, srednje и nisko. Testirani su na internom klasteru bez prometa klijenata otprilike jednu sedmicu. Prema zadanim postavkama primaju se podovi bez specificiranog prioriteta srednje prioritet, klasa je postavljena za Ingesters with visok prioritet. Kritično je rezervisan za praćenje (Prometheus, Alertmanager, node-exporter, kube-state-metrics, itd.). Naša konfiguracija je otvorena i možete pogledati PR .
Nesreća
U petak, 19. jula, jedan od inženjera je pokrenuo novi namenski Cortex klaster za velikog klijenta. Konfiguracija za ovaj klaster nije uključivala nove prioritete podova, tako da je svim novim podovima dodijeljen zadani prioritet - srednje.
Kubernetes klaster nije imao dovoljno resursa za novi Cortex klaster, a postojeći proizvodni Cortex klaster nije ažuriran (Ingesteri su ostali bez visoko prioritet). Budući da su Ingesteri novog klastera po defaultu imali srednje prioritet, a postojeći podovi u proizvodnji uopće su radili bez prioriteta, Ingesteri novog klastera zamijenili su Ingesters iz postojećeg Cortex proizvodnog klastera.
ReplicaSet za izbačeni Ingester u proizvodnom klasteru otkrio je izbačeni modul i kreirao novi za održavanje specificiranog broja kopija. Nova pod je dodijeljena po defaultu srednje prioritet, a još jedan “stari” Ingester u proizvodnji izgubio je svoje resurse. Rezultat je bio lavinski proces, što je dovelo do izmještanja svih mahuna iz Ingester za Cortex proizvodne klastere.
Ingestori imaju status i pohranjuju podatke za prethodnih 12 sati. To nam omogućava da ih efikasnije kompresujemo prije nego što ih zapišemo u dugotrajno skladištenje. Da bi se to postiglo, Cortex dijeli podatke kroz nizove koristeći Distributed Hash Table (DHT) i replicira svaku seriju na tri Ingestera koristeći konzistentnost kvoruma u Dynamo stilu. Cortex ne upisuje podatke u Ingesters koji su onemogućeni. Stoga, kada veliki broj Ingestera napusti DHT, Cortex ne može da obezbedi dovoljnu replikaciju unosa i oni se padaju.
Detekcija i sanacija
Nova obavještenja Prometheusa zasnovana na "budžetu greške" (zasnovano na budžetu — detalji će se pojaviti u budućem članku) je počeo da se oglasi alarmom 4 minuta nakon početka gašenja. U narednih pet minuta izvršili smo dijagnostiku i povećali osnovni Kubernetes klaster da ugosti i nove i postojeće proizvodne klastere.
Nakon još pet minuta, stari Ingesteri su uspješno upisali svoje podatke, novi su se pokrenuli, a Cortex klasteri su ponovo postali dostupni.
Još 10 minuta je potrošeno na dijagnosticiranje i ispravljanje grešaka bez memorije (OOM) iz reverznih proksija za autentifikaciju koji se nalaze ispred Cortexa. OOM greške su uzrokovane desetostrukim povećanjem QPS-a (vjerujemo zbog pretjerano agresivnih zahtjeva sa Prometheus servera klijenta).
Posledice
Ukupno vrijeme zastoja je bilo 26 minuta. Podaci nisu izgubljeni. Ingesteri su uspješno učitali sve podatke u memoriji u dugotrajnu pohranu. Tokom gašenja, klijent Prometheus serveri u baferu su izbrisani (na daljinu) snimci koristeći baziran na WAL-u (autor iz Grafana Labs) i ponovio neuspješno pisanje nakon pada.
Operacije pisanja proizvodnog klastera
nalazi
Važno je izvući pouke iz ovog incidenta i poduzeti potrebne korake kako bi se izbjeglo njegovo ponavljanje.
Gledajući unazad, nismo trebali postaviti zadanu vrijednost srednje prioritet dok svi Ingesteri u proizvodnji ne dobiju visoka prioritet. Osim toga, o njima je bilo potrebno unaprijed se pobrinuti visoko prioritet. Sada je sve popravljeno. Nadamo se da će naše iskustvo pomoći drugim organizacijama koje razmatraju korištenje pod prioriteta u Kubernetesu.
Dodaćemo dodatni nivo kontrole nad postavljanjem svih dodatnih objekata čije su konfiguracije globalne u klaster. Od sada će se takve promjene ocjenjivati bоviše ljudi. Dodatno, modifikacija koja je izazvala pad smatrala se suviše malom za poseban projektni dokument – o njoj se raspravljalo samo u izdanju GitHub-a. Sve takve promjene konfiguracija od sada će biti praćene odgovarajućom projektnom dokumentacijom.
Konačno, automatizirat ćemo promjenu veličine obrnutog proxyja za autentifikaciju kako bismo spriječili preopterećenje OOM-a kojem smo svjedočili i pregledat ćemo Prometheus zadane postavke vezane za zamjenu i skaliranje kako bismo spriječili slične probleme u budućnosti.
Neuspjeh je imao i neke pozitivne posljedice: nakon što je dobio potrebne resurse, Cortex se automatski oporavio bez dodatne intervencije. Takođe smo stekli dragocjeno iskustvo u radu sa - naš novi sistem agregacije dnevnika - koji je pomogao da se osigura da su se svi Ingesteri pravilno ponašali tokom i nakon kvara.
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
izvor: www.habr.com