Opomba. prevod: Predstavljamo vam tehnične podrobnosti o razlogih za nedavni izpad storitve v oblaku, ki jo vzdržujejo ustvarjalci Grafana. To je klasičen primer, kako lahko nova in na videz izredno uporabna funkcija, zasnovana za izboljšanje kakovosti infrastrukture... povzroči škodo, če ne poskrbite za številne nianse njene uporabe v realnosti proizvodnje. Super je, ko se pojavijo takšni materiali, ki vam omogočajo, da se ne učite samo na svojih napakah. Podrobnosti so v prevodu tega besedila od podpredsednika produkta Grafana Labs.
V petek, 19. julija, je storitev Hosted Prometheus v Grafana Cloudu za približno 30 minut prenehala delovati. Opravičujem se vsem strankam, ki jih je izpad prizadel. Naša naloga je zagotoviti orodja za spremljanje, ki jih potrebujete, in razumemo, da če jih nimate, vam lahko otežijo življenje. Ta incident jemljemo zelo resno. Ta opomba pojasnjuje, kaj se je zgodilo, kako smo se odzvali in kaj delamo, da se to ne bo ponovilo.
prazgodovina
Storitev Grafana Cloud Hosted Prometheus temelji na — Projekt CNCF za ustvarjanje horizontalno razširljive, visoko razpoložljive storitve Prometheus z več najemniki. Arhitektura Cortex je sestavljena iz niza posameznih mikrostoritev, od katerih vsaka opravlja svojo funkcijo: replikacija, shranjevanje, poizvedbe itd. Cortex je v aktivnem razvoju in nenehno dodaja nove funkcije ter izboljšuje zmogljivost. Redno uvajamo nove izdaje Cortexa v gruče, tako da lahko stranke izkoristijo te funkcije – na srečo je Cortex mogoče posodobiti brez izpadov.
Za brezhibne posodobitve zahteva storitev Ingester Cortex med postopkom posodabljanja dodatno repliko Ingester. (Opomba. prevod: - osnovna sestavina korteksa. Njegova naloga je zbiranje stalnega toka vzorcev, njihovo združevanje v dele Prometheus in shranjevanje v bazo podatkov, kot je DynamoDB, BigTable ali Cassandra.) To omogoča starim Ingesterjem, da posredujejo trenutne podatke novim Ingesterjem. Omeniti velja, da Ingesters zahtevajo vire. Za njihovo delovanje morate imeti 4 jedra in 15 GB pomnilnika na pod, tj. 25 % procesorske moči in pomnilnika osnovnega stroja v primeru naših gruč Kubernetes. Na splošno imamo v gruči običajno veliko več neuporabljenih virov kot 4 jedra in 15 GB pomnilnika, tako da lahko med nadgradnjami zlahka zavrtimo te dodatne ingesterje.
Pogosto pa se zgodi, da med normalnim delovanjem noben stroj nima teh 25% neporabljenih virov. Da, niti ne prizadevamo si: CPU in pomnilnik bosta vedno uporabna za druge procese. Da bi rešili to težavo, smo se odločili uporabiti . Ideja je dati Ingestersu višjo prednost kot drugim mikrostoritvam (brez stanja). Ko moramo zagnati dodaten (N+1) Ingester, začasno izpodrinemo druge, manjše stroke. Ti sklopi se prenesejo v proste vire na drugih napravah, pri čemer ostane dovolj velika »luknja« za zagon dodatnega Ingesterja.
V četrtek, 18. julija, smo v naše gruče uvedli štiri nove prioritetne ravni: kritičen, Visoko, srednje и nizka. Približno en teden so bili testirani na notranji gruči brez prometa strank. Privzeto so prejeti podi brez določene prioritete srednje prioriteta, razred je bil določen za Ingesters z visoko prioriteta. Kritično je bil rezerviran za spremljanje (Prometheus, Alertmanager, node-exporter, kube-state-metrics itd.). Naša konfiguracija je odprta in lahko si ogledate PR .
Crash
V petek, 19. julija, je eden od inženirjev lansiral novo namensko gručo Cortex za veliko stranko. Konfiguracija za to gručo ni vključevala novih prioritet podov, zato je bila vsem novim podom dodeljena privzeta prioriteta – srednje.
Gruča Kubernetes ni imela dovolj virov za novo gručo Cortex, obstoječa produkcijska gruča Cortex pa ni bila posodobljena (Ingesters so ostali brez visoko prednost). Ker so imeli Ingesters nove gruče privzeto srednje prioriteta in so obstoječi podi v proizvodnji delovali brez prednosti, so Ingesterji nove gruče zamenjali Ingesterje iz obstoječega proizvodnega grozda Cortex.
ReplicaSet za izgnani Ingester v produkcijski gruči je zaznal izgnani pod in ustvaril novega, da ohrani podano število kopij. Nov pod je bil privzeto dodeljen srednje prioriteta, drugi »stari« Ingester v proizvodnji pa je izgubil vire. Rezultat je bil lavinski proces, kar je vodilo do izpodrivanja vseh strokov iz proizvodnih grozdov Ingester za Cortex.
Prejemniki so s stanjem in shranjujejo podatke za preteklih 12 ur. To nam omogoča, da jih učinkoviteje stisnemo, preden jih zapišemo v dolgoročno shrambo. Da bi to dosegel, Cortex razdeli podatke v serije z uporabo porazdeljene zgoščevalne tabele (DHT) in ponovi vsako serijo v treh Ingesterjih z doslednostjo kvoruma v slogu Dynamo. Cortex ne zapisuje podatkov v Ingesters, ki so onemogočeni. Tako, ko veliko število Ingesterjev zapusti DHT, Cortex ne more zagotoviti zadostne replikacije vnosov in ti se zrušijo.
Odkrivanje in sanacija
Nova obvestila Prometheus, ki temeljijo na "proračunu napak" (na podlagi proračuna napak — podrobnosti bodo prikazane v prihodnjem članku) je začel oglašati alarm 4 minute po začetku izklopa. V naslednjih petih minutah smo izvedli nekaj diagnostike in povečali osnovno gručo Kubernetes, da bi gostila nove in obstoječe produkcijske gruče.
Po nadaljnjih petih minutah so stari Ingesterji uspešno zapisali svoje podatke, novi so se zagnali in gruče Cortex so spet postale na voljo.
Nadaljnjih 10 minut je bilo porabljenih za diagnosticiranje in popravljanje napak zaradi pomanjkanja pomnilnika (OOM) iz povratnih posrednikov za preverjanje pristnosti, ki se nahajajo pred Cortexom. Napake OOM je povzročilo desetkratno povečanje QPS (verjamemo, da zaradi preveč agresivnih zahtev odjemalčevih strežnikov Prometheus).
Aftermath
Skupni čas izpada je bil 26 minut. Podatki niso bili izgubljeni. Porabniki so uspešno naložili vse podatke v pomnilniku v dolgoročno shrambo. Med zaustavitvijo so bili odjemalski strežniki Prometheus v medpomnilniku izbrisani (na daljavo) posnetkov z uporabo temelji na WAL (avtor iz Grafana Labs) in ponovil neuspešna pisanja po zrušitvi.
Operacije pisanja v proizvodni grozd
Ugotovitve
Pomembno je, da se iz tega incidenta nekaj naučimo in sprejmemo potrebne ukrepe, da se prepreči ponovitev.
Če pogledamo nazaj, ne bi smeli nastaviti privzete vrednosti srednje prednost, dokler ne prejmejo vsi Ingesters v proizvodnji Visoko prednostna naloga. Poleg tega je bilo treba zanje poskrbeti vnaprej visoko prioriteta. Zdaj je vse popravljeno. Upamo, da bodo naše izkušnje pomagale drugim organizacijam, ki razmišljajo o uporabi prioritet podov v Kubernetesu.
Dodali bomo dodatno raven nadzora nad razmestitvijo vseh dodatnih objektov, katerih konfiguracije so globalne za gručo. Odslej bodo takšne spremembe ocenjene bоveč ljudi. Poleg tega se je sprememba, ki je povzročila zrušitev, štela za premajhno za ločen projektni dokument – o njej so razpravljali samo v izdaji GitHub. Odslej bo vse tovrstne spremembe konfiguracij spremljala ustrezna projektna dokumentacija.
Nazadnje bomo avtomatizirali spreminjanje velikosti obratnega proxyja za preverjanje pristnosti, da preprečimo preobremenitev OOM, ki smo mu bili priča, in pregledali privzete nastavitve Prometheusa, povezane z nadomestnim delovanjem in skaliranjem, da preprečimo podobne težave v prihodnosti.
Neuspeh je imel tudi nekaj pozitivnih posledic: ko je prejel potrebna sredstva, se je Cortex samodejno obnovil brez dodatnega posredovanja. Dragocene izkušnje smo pridobili tudi pri delu z - naš novi sistem združevanja dnevnikov - ki je pomagal zagotoviti, da so se vsi uporabniki Ingesters pravilno obnašali med napako in po njej.
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com