Merk. overs.: Vi presenterer for deg tekniske detaljer om årsakene til den nylige nedetiden i skytjenesten vedlikeholdt av skaperne av Grafana. Dette er et klassisk eksempel på hvordan en ny og tilsynelatende ekstremt nyttig funksjon designet for å forbedre kvaliteten på infrastrukturen... kan forårsake skade hvis du ikke tar hensyn til de mange nyansene av dens bruk i produksjonsrealiteter. Det er flott når materialer som dette dukker opp som lar deg lære ikke bare av dine feil. Detaljer er i oversettelsen av denne teksten fra visepresidenten for produkt fra Grafana Labs.
Fredag 19. juli sluttet Hosted Prometheus-tjenesten i Grafana Cloud å fungere i omtrent 30 minutter. Jeg beklager til alle kunder som er berørt av strømbruddet. Vår jobb er å tilby overvåkingsverktøyene du trenger, og vi forstår at det å ikke ha dem tilgjengelig kan gjøre livet ditt vanskeligere. Vi tar denne hendelsen svært alvorlig. Dette notatet forklarer hva som skjedde, hvordan vi reagerte og hva vi gjør for å sikre at det ikke skjer igjen.
forhistorie
Grafana Cloud Hosted Prometheus-tjenesten er basert på — CNCF-prosjekt for å lage en horisontalt skalerbar, svært tilgjengelig Prometheus-tjeneste med flere leietakere. Cortex-arkitekturen består av et sett med individuelle mikrotjenester, som hver utfører sin egen funksjon: replikering, lagring, spørringer, etc. Cortex er under aktiv utvikling og legger stadig til nye funksjoner og forbedrer ytelsen. Vi distribuerer jevnlig nye Cortex-utgivelser til klynger slik at kunder kan dra nytte av disse funksjonene – heldigvis kan Cortex oppdateres uten nedetid.
For sømløse oppdateringer krever Ingester Cortex-tjenesten en ekstra Ingester-replika under oppdateringsprosessen. (Merk. overs.: - den grunnleggende komponenten i Cortex. Jobben er å samle en konstant strøm av prøver, gruppere dem i Prometheus-biter og lagre dem i en database som DynamoDB, BigTable eller Cassandra.) Dette gjør at gamle Ingesters kan videresende gjeldende data til nye Ingesters. Det er verdt å merke seg at Ingesters er ressurskrevende. For at de skal fungere, må du ha 4 kjerner og 15 GB minne per pod, dvs. 25 % av prosessorkraften og minnet til basismaskinen i tilfellet med våre Kubernetes-klynger. Generelt har vi vanligvis mye mer ubrukte ressurser i klyngen enn 4 kjerner og 15 GB minne, så vi kan enkelt spinne opp disse ekstra inntakerne under oppgraderinger.
Imidlertid skjer det ofte at under normal drift har ingen av maskinene disse 25 % av ubrukte ressurser. Ja, vi strever ikke engang: CPU og minne vil alltid være nyttig for andre prosesser. For å løse dette problemet bestemte vi oss for å bruke . Tanken er å gi Ingesters en høyere prioritet enn andre (statsløse) mikrotjenester. Når vi trenger å kjøre en ekstra (N+1) Ingester, forskyver vi midlertidig andre, mindre pods. Disse podene overføres til gratis ressurser på andre maskiner, og etterlater et stort nok "hull" til å kjøre en ekstra Ingester.
Torsdag 18. juli lanserte vi fire nye prioritetsnivåer til våre klynger: kritisk, høy, gjennomsnitt и lav. De ble testet på en intern klynge uten klienttrafikk på omtrent en uke. Som standard mottas pods uten en spesifisert prioritet gjennomsnitt prioritet ble det satt time for Ingesters med høy prioritet. Kritisk var reservert for overvåking (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). Konfigurasjonen vår er åpen, og du kan se PR .
ulykke
Fredag 19. juli lanserte en av ingeniørene en ny dedikert Cortex-klynge for en stor klient. Konfigurasjonen for denne klyngen inkluderte ikke nye pod-prioriteter, så alle nye pods ble tildelt en standardprioritet - gjennomsnitt.
Kubernetes-klyngen hadde ikke nok ressurser for den nye Cortex-klyngen, og den eksisterende produksjons-Cortex-klyngen ble ikke oppdatert (Innholdere ble stående uten høy prioritet). Siden Ingesters av den nye klyngen som standard hadde gjennomsnitt prioritet, og de eksisterende podene i produksjonen fungerte uten prioritet i det hele tatt, erstattet Ingesters i den nye klyngen Ingesters fra den eksisterende Cortex produksjonsklyngen.
ReplicaSet for den utkastede Ingester i produksjonsklyngen oppdaget den utkastede poden og opprettet en ny for å opprettholde det angitte antallet kopier. Den nye poden ble tildelt som standard gjennomsnitt prioritet, og en annen «gammel» Ingester i produksjon mistet ressursene sine. Resultatet ble skredprosess, noe som førte til forskyvning av alle pods fra Ingester for Cortex produksjonsklynger.
Inntakere er statelige og lagrer data for de siste 12 timene. Dette gjør at vi kan komprimere dem mer effektivt før vi skriver dem til langtidslagring. For å oppnå dette, splitter Cortex data på tvers av serier ved hjelp av en distribuert hashtabell (DHT) og replikerer hver serie på tvers av tre inntakere ved å bruke Dynamo-stil quorum-konsistens. Cortex skriver ikke data til Ingesters som er deaktivert. Derfor, når et stort antall inntakere forlater DHT, kan ikke Cortex gi tilstrekkelig replikering av oppføringene, og de krasjer.
Deteksjon og utbedring
Nye Prometheus-varsler basert på "feilbudsjett" (feilbudsjettbasert — detaljer vil vises i en fremtidig artikkel) begynte å slå alarmen 4 minutter etter starten av avstengningen. I løpet av de neste fem minuttene eller så kjørte vi litt diagnostikk og oppskalerte den underliggende Kubernetes-klyngen for å være vert for både de nye og eksisterende produksjonsklyngene.
Etter ytterligere fem minutter skrev de gamle Ingesters dataene sine, de nye startet opp, og Cortex-klyngene ble tilgjengelige igjen.
Ytterligere 10 minutter ble brukt på å diagnostisere og korrigere minnefeil (OOM) fra reverserte autentiseringsfullmakter plassert foran Cortex. OOM-feil ble forårsaket av en tidoblet økning i QPS (vi tror på grunn av altfor aggressive forespørsler fra klientens Prometheus-servere).
Aftermath
Den totale nedetiden var 26 minutter. Ingen data gikk tapt. Opptakere har lastet inn alle data i minnet til langtidslagring. Under strømbruddet ble klient Prometheus-servere bufret slettet (fjernkontroll) opptak ved hjelp av basert på WAL (forfattet av fra Grafana Labs) og gjentok de mislykkede skrivingene etter krasjet.
Skriveoperasjoner i produksjonsklynge
Funn
Det er viktig å lære av denne hendelsen og ta de nødvendige skritt for å unngå at den gjentar seg.
I ettertid burde vi ikke ha satt standarden gjennomsnitt prioritet inntil alle Ingesters i produksjon har fått høy En prioritet. I tillegg var det nødvendig å ta vare på dem på forhånd høy prioritet. Alt er fikset nå. Vi håper vår erfaring vil hjelpe andre organisasjoner som vurderer å bruke pod-prioriteringer i Kubernetes.
Vi vil legge til et ekstra nivå av kontroll over distribusjonen av eventuelle ekstra objekter hvis konfigurasjoner er globale for klyngen. Fra nå av vil slike endringer bli vurdert bоflere mennesker. I tillegg ble endringen som forårsaket krasjet ansett som for liten for et eget prosjektdokument - den ble bare diskutert i en GitHub-utgave. Fra nå av vil alle slike endringer i konfigurasjonene bli ledsaget av passende prosjektdokumentasjon.
Til slutt vil vi automatisere endring av størrelsen på den omvendte proxyen for autentisering for å forhindre overbelastning OOM vi så, og vi vil gjennomgå Prometheus standardinnstillinger relatert til tilbakefall og skalering for å forhindre lignende problemer i fremtiden.
Feilen hadde også noen positive konsekvenser: Etter å ha mottatt de nødvendige ressursene, kom Cortex seg automatisk uten ekstra intervensjon. Vi har også fått verdifull erfaring med å jobbe med - vårt nye loggaggregeringssystem - som bidro til å sikre at alle Ingesters oppførte seg ordentlig under og etter feilen.
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com