Bilješka. prev.: Predstavljamo vam tehničke detalje o razlozima nedavnih zastoja u usluzi u oblaku koju održavaju kreatori Grafana. Ovo je klasičan primjer kako nova i naizgled iznimno korisna značajka dizajnirana za poboljšanje kvalitete infrastrukture... može uzrokovati štetu ako ne osigurate brojne nijanse njezine primjene u stvarnosti proizvodnje. Sjajno je kada se pojave ovakvi materijali koji vam omogućuju da učite ne samo na svojim pogreškama. Detalji su u prijevodu ovog teksta od Vice President of Product iz Grafana Labsa.
U petak, 19. srpnja, usluga Hosted Prometheus u Grafana Cloudu prestala je s radom na otprilike 30 minuta. Ispričavam se svim kupcima pogođenim prekidom. Naš je posao pružiti alate za praćenje koji su vam potrebni i razumijemo da vam nedostatak tih alata može otežati život. Ovaj incident shvaćamo krajnje ozbiljno. Ova bilješka objašnjava što se dogodilo, kako smo reagirali i što činimo da se to više ne dogodi.
prapovijest
Usluga Grafana Cloud Hosted Prometheus temelji se na — CNCF projekt za stvaranje horizontalno skalabilne, visoko dostupne usluge Prometheus s više korisnika. Arhitektura Cortex sastoji se od skupa pojedinačnih mikroservisa, od kojih svaki obavlja svoju funkciju: replikacija, pohrana, upiti, itd. Cortex je u aktivnom razvoju i neprestano dodaje nove značajke i poboljšava performanse. Redovito implementiramo nova izdanja Cortexa u klastere kako bi korisnici mogli iskoristiti prednosti ovih značajki - srećom, Cortex se može ažurirati bez prekida rada.
Za besprijekorna ažuriranja, usluga Ingester Cortex zahtijeva dodatnu repliku Ingestera tijekom procesa ažuriranja. (Bilješka. prev.: - osnovna komponenta korteksa. Njegov je posao prikupljanje stalnog toka uzoraka, njihovo grupiranje u Prometheus dijelove i pohranjivanje u bazu podataka kao što je DynamoDB, BigTable ili Cassandra.) To omogućuje starim Ingesterima da prosljeđuju trenutne podatke novim Ingesterima. Vrijedno je napomenuti da Ingesteri zahtijevaju resurse. Da bi radili, morate imati 4 jezgre i 15 GB memorije po podu, tj. 25% procesorske snage i memorije osnovnog stroja u slučaju naših Kubernetes klastera. Općenito, obično imamo puno više neiskorištenih resursa u klasteru od 4 jezgre i 15 GB memorije, tako da možemo lako pokrenuti te dodatne ingestere tijekom nadogradnje.
Međutim, često se događa da tijekom normalnog rada nijedan od strojeva nema ovih 25% neiskorištenih resursa. Da, čak se i ne trudimo: CPU i memorija uvijek će biti korisni za druge procese. Kako bismo riješili ovaj problem, odlučili smo koristiti . Ideja je dati Ingesterima veći prioritet u odnosu na druge mikroservise (bez statusa). Kada trebamo pokrenuti dodatni (N+1) Ingester, privremeno premještamo druge, manje mahune. Ti se moduli prenose u besplatne resurse na drugim strojevima, ostavljajući dovoljno veliku "rupu" za pokretanje dodatnog Ingestera.
U četvrtak, 18. srpnja, uveli smo četiri nove razine prioriteta u naše klastere: kritično, visok, prosječan и nisko. Testirani su na internom klasteru bez klijentskog prometa oko tjedan dana. Prema zadanim postavkama primljene su grupe bez navedenog prioriteta prosječan prioritet, klasa je postavljena za Ingesters with visok prioritet. Kritično bio rezerviran 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. srpnja, jedan od inženjera lansirao je novi namjenski Cortex klaster za velikog klijenta. Konfiguracija za ovaj klaster nije uključivala nove prioritete mahuna, pa je svim novim mahunama dodijeljen zadani prioritet - prosječan.
Kubernetes klaster nije imao dovoljno resursa za novi Cortex klaster, a postojeći proizvodni Cortex klaster nije ažuriran (Ingesteri su ostali bez visoka prioritet). Budući da su Ingesteri novog klastera prema zadanim postavkama imali prosječan prioritet, a postojeće mahune u proizvodnji radile su uopće bez prioriteta, Ingesteri novog klastera zamijenili su Ingestere iz postojećeg proizvodnog klastera Cortex.
ReplicaSet za izbačeni Ingester u produkcijskom klasteru otkrio je izbačeni modul i stvorio novi za održavanje navedenog broja kopija. Nova grupa je dodijeljena prema zadanim postavkama prosječan prioritet, a još jedan “stari” Ingester u proizvodnji izgubio je svoje resurse. Rezultat je bio lavinski proces, što je dovelo do premještanja svih mahuna iz Ingestera za Cortex proizvodne klastere.
Ingestori imaju status i pohranjuju podatke za prethodnih 12 sati. To nam omogućuje da ih učinkovitije komprimiramo prije nego što ih zapišemo u dugoročnu pohranu. Da bi se to postiglo, Cortex dijeli podatke na nizove pomoću Distribuirane hash tablice (DHT) i replicira svaku seriju na tri Ingestera koristeći dosljednost kvoruma u stilu Dynamo-a. Cortex ne piše podatke Ingesterima koji su onemogućeni. Stoga, kada veliki broj Ingestera napusti DHT, Cortex ne može osigurati dovoljnu replikaciju unosa i oni se ruše.
Otkrivanje i sanacija
Nove obavijesti Prometheusa temeljene na "proračunu pogreške" (na temelju proračuna pogreške — detalji će se pojaviti u sljedećem članku) oglasio se alarmom 4 minute nakon početka gašenja. Tijekom sljedećih pet minuta ili tako nešto, pokrenuli smo dijagnostiku i povećali osnovni Kubernetes klaster da ugostimo 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 ponovno su postali dostupni.
Dodatnih 10 minuta potrošeno je na dijagnosticiranje i ispravljanje pogrešaka nedostatka memorije (OOM) iz obrnutih proxyja za provjeru autentičnosti smještenih ispred Cortexa. OOM pogreške uzrokovane su deseterostrukim povećanjem QPS-a (vjerujemo da zbog preagresivnih zahtjeva klijentovih poslužitelja Prometheus).
Posljedice
Ukupno vrijeme mirovanja bilo je 26 minuta. Nema izgubljenih podataka. Ingesteri su uspješno učitali sve podatke u memoriji u dugoročnu pohranu. Tijekom gašenja, poslužitelji klijenta Prometheus u međuspremniku su izbrisani (na daljinu) snimke pomoću temeljen na WAL-u (autor iz Grafana Labs) i ponovio neuspjela pisanja nakon pada.
Operacije pisanja proizvodnog klastera
Zaključci
Važno je naučiti iz ovog incidenta i poduzeti potrebne korake kako bi se izbjeglo njegovo ponavljanje.
Gledajući unatrag, nismo trebali postaviti zadanu vrijednost prosječan prioritet dok svi Ingesteri u proizvodnji ne prime visok prioritet. Osim toga, bilo je potrebno unaprijed brinuti o njima visoko prioritet. Sada je sve sređeno. Nadamo se da će naše iskustvo pomoći drugim organizacijama koje razmatraju korištenje prioriteta podova u Kubernetesu.
Dodat ćemo dodatnu razinu kontrole nad implementacijom svih dodatnih objekata čije su konfiguracije globalne za klaster. Od sada će se takve promjene ocjenjivati bоviše ljudi. Osim toga, modifikacija koja je uzrokovala rušenje smatrala se suviše malom za zasebni projektni dokument - o njoj se raspravljalo samo u izdanju GitHuba. Od sada će sve takve izmjene konfiguracija biti popraćene odgovarajućom projektnom dokumentacijom.
Konačno, automatizirat ćemo promjenu veličine obrnutog proxyja za provjeru autentičnosti kako bismo spriječili preopterećenje OOM-a kojem smo svjedočili, te ćemo pregledati zadane postavke Prometheusa koje se odnose na zamjenu i skaliranje kako bismo spriječili slične probleme u budućnosti.
Neuspjeh je imao i neke pozitivne posljedice: primivši potrebne resurse, Cortex se automatski oporavio bez dodatne intervencije. Također smo stekli dragocjeno iskustvo radeći sa - naš novi sustav prikupljanja dnevnika - koji je pomogao osigurati da se svi Ingesteri ponašaju ispravno tijekom i nakon kvara.
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
Izvor: www.habr.com