Bemærk. overs.: Vi præsenterer for din opmærksomhed tekniske detaljer om årsagerne til den seneste nedetid i cloud-tjenesten, der vedligeholdes af skaberne af Grafana. Dette er et klassisk eksempel på, hvordan en ny og tilsyneladende ekstremt nyttig funktion designet til at forbedre kvaliteten af infrastrukturen... kan forårsage skade, hvis du ikke tager højde for de mange nuancer af dens anvendelse i produktionens realiteter. Det er fantastisk, når der dukker materialer som dette op, som giver dig mulighed for ikke kun at lære af dine fejl. Detaljer er i oversættelsen af denne tekst fra vicepræsidenten for produkt fra Grafana Labs.
Fredag den 19. juli holdt Hosted Prometheus-tjenesten i Grafana Cloud op med at fungere i cirka 30 minutter. Jeg undskylder over for alle kunder, der er berørt af afbrydelsen. Vores opgave er at levere de overvågningsværktøjer, du har brug for, og vi forstår, at ikke at have dem tilgængelige kan gøre dit liv sværere. Vi tager denne hændelse yderst alvorligt. Denne note forklarer, hvad der skete, hvordan vi reagerede, og hvad vi gør for at sikre, at det ikke sker igen.
forhistorie
Grafana Cloud Hosted Prometheus service er baseret på — CNCF-projekt for at skabe en horisontalt skalerbar, meget tilgængelig Prometheus-tjeneste med flere lejere. Cortex-arkitekturen består af et sæt individuelle mikrotjenester, som hver udfører sin egen funktion: replikering, lagring, forespørgsler osv. Cortex er under aktiv udvikling og tilføjer konstant nye funktioner og forbedrer ydeevnen. Vi implementerer jævnligt nye Cortex-udgivelser til klynger, så kunderne kan drage fordel af disse funktioner – heldigvis kan Cortex opdateres uden nedetid.
For problemfri opdateringer kræver Ingester Cortex-tjenesten en ekstra Ingester-replika under opdateringsprocessen. (Bemærk. overs.: - den grundlæggende komponent i Cortex. Dens opgave er at indsamle en konstant strøm af prøver, gruppere dem i Prometheus-bidder og gemme dem i en database som DynamoDB, BigTable eller Cassandra.) Dette giver gamle Ingesters mulighed for at videresende aktuelle data til nye Ingesters. Det er værd at bemærke, at Ingesters er ressourcekrævende. For at de kan fungere, skal du have 4 kerner og 15 GB hukommelse pr. pod, dvs. 25 % af processorkraften og hukommelsen på basismaskinen i tilfælde af vores Kubernetes-klynger. Generelt har vi normalt mange flere ubrugte ressourcer i klyngen end 4 kerner og 15 GB hukommelse, så vi kan nemt spinde disse ekstra indtagere op under opgraderinger.
Det sker dog ofte, at ingen af maskinerne under normal drift har disse 25 % af ubrugte ressourcer. Ja, vi stræber ikke engang: CPU og hukommelse vil altid være nyttige til andre processer. For at løse dette problem besluttede vi at bruge . Tanken er at give Ingesters en højere prioritet end andre (statsløse) mikrotjenester. Når vi skal køre en ekstra (N+1) Ingester, forskyder vi midlertidigt andre, mindre bælg. Disse pods overføres til gratis ressourcer på andre maskiner, hvilket efterlader et stort nok "hul" til at køre en ekstra Ingester.
Torsdag den 18. juli udrullede vi fire nye prioritetsniveauer til vores klynger: kritisk, høj, gennemsnit и lav. De blev testet på en intern klynge uden klienttrafik i omkring en uge. Som standard modtages pods uden en specificeret prioritet gennemsnit prioritet blev der sat klasse for Ingesters med høj prioritet. Kritisk var reserveret til overvågning (Prometheus, Alertmanager, node-exporter, kube-state-metrics osv.). Vores konfiguration er åben, og du kan se PR .
ulykke
Fredag den 19. juli lancerede en af ingeniørerne en ny dedikeret Cortex-klynge til en stor kunde. Konfigurationen for denne klynge inkluderede ikke nye pod-prioriteter, så alle nye pods blev tildelt en standardprioritet - gennemsnit.
Kubernetes-klyngen havde ikke nok ressourcer til den nye Cortex-klynge, og den eksisterende produktions-Cortex-klynge blev ikke opdateret (Indtagere blev efterladt uden høj prioritet). Siden Ingesters af den nye klynge som standard havde gennemsnit prioritet, og de eksisterende pods i produktionen fungerede uden prioritet overhovedet, erstattede Ingesters fra den nye klynge Ingesters fra den eksisterende Cortex produktionsklynge.
ReplicaSet for den evicerede Ingester i produktionsklyngen opdagede den eviced pod og oprettede en ny for at bevare det angivne antal kopier. Den nye pod blev tildelt som standard gennemsnit prioritet, og en anden "gammel" Ingester i produktionen mistede sine ressourcer. Resultatet var lavineproces, hvilket førte til fortrængning af alle bælg fra Ingester til Cortex produktionsklynger.
Indtagere er statelige og gemmer data for de foregående 12 timer. Dette giver os mulighed for at komprimere dem mere effektivt, før du skriver dem til langtidslagring. For at opnå dette skærer Cortex data på tværs af serier ved hjælp af en distribueret hash-tabel (DHT) og replikerer hver serie på tværs af tre indtagere ved hjælp af Dynamo-lignende kvorumkonsistens. Cortex skriver ikke data til Ingesters, der er deaktiveret. Når et stort antal indtagere forlader DHT'en, kan Cortex således ikke levere tilstrækkelig replikering af indtastningerne, og de går ned.
Detektion og afhjælpning
Nye Prometheus-meddelelser baseret på "fejlbudget" (fejlbudgetbaseret — detaljer vil blive vist i en fremtidig artikel) begyndte at slå alarm 4 minutter efter starten af nedlukningen. I løbet af de næste fem minutter eller deromkring kørte vi noget diagnostik og opskalerede den underliggende Kubernetes-klynge til at være vært for både de nye og eksisterende produktionsklynger.
Efter yderligere fem minutter skrev de gamle Ingesters succesfuldt deres data, de nye startede op, og Cortex-klyngerne blev tilgængelige igen.
Yderligere 10 minutter blev brugt på at diagnosticere og korrigere out-of-memory (OOM) fejl fra autentificering omvendte proxyer placeret foran Cortex. OOM-fejl var forårsaget af en tidoblet stigning i QPS (vi tror på grund af alt for aggressive anmodninger fra klientens Prometheus-servere).
virkninger
Den samlede nedetid var 26 minutter. Ingen data gik tabt. Indlæsere har med succes indlæst alle data i hukommelsen til langtidslagring. Under udfaldet blev klient Prometheus-servere, der var bufferet, slettet (fjern) optagelser vha baseret på WAL (forfattet af fra Grafana Labs) og gentog de mislykkede skrivninger efter styrtet.
Skriveoperationer i produktionsklynge
Fund
Det er vigtigt at lære af denne hændelse og tage de nødvendige skridt for at undgå, at den gentager sig.
Set i bakspejlet burde vi ikke have sat standarden gennemsnit prioritet indtil alle Ingesters i produktionen har modtaget høj en prioritet. Derudover var det nødvendigt at tage sig af dem på forhånd høj prioritet. Alt er rettet nu. Vi håber, at vores erfaring vil hjælpe andre organisationer, der overvejer at bruge pod-prioriteter i Kubernetes.
Vi vil tilføje et ekstra niveau af kontrol over udrulningen af eventuelle yderligere objekter, hvis konfigurationer er globale for klyngen. Fra nu af vil sådanne ændringer blive vurderet bоflere folk. Derudover blev ændringen, der forårsagede nedbruddet, anset for at være for lille til et separat projektdokument - den blev kun diskuteret i et GitHub-udgave. Fra nu af vil alle sådanne ændringer af konfigurationer blive ledsaget af passende projektdokumentation.
Endelig vil vi automatisere størrelsesændring af godkendelsens omvendte proxy for at forhindre den overbelastning OOM, vi var vidne til, og vi vil gennemgå Prometheus standardindstillinger relateret til fallback og skalering for at forhindre lignende problemer i fremtiden.
Fejlen havde også nogle positive konsekvenser: Efter at have modtaget de nødvendige ressourcer kom Cortex automatisk tilbage uden yderligere indgriben. Vi fik også værdifuld erfaring med at arbejde med - vores nye log-aggregationssystem - som var med til at sikre, at alle Ingesters opførte sig ordentligt under og efter fejlen.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com