Notă. transl.: Vă prezentăm atenției detalii tehnice despre motivele pentru recenta întrerupere a serviciului cloud întreținut de creatorii Grafana. Acesta este un exemplu clasic al modului în care o caracteristică nouă și aparent extrem de utilă concepută pentru a îmbunătăți calitatea infrastructurii... poate provoca rău dacă nu asigurați numeroasele nuanțe ale aplicării sale în realitățile producției. Este grozav când apar astfel de materiale care îți permit să înveți nu numai din greșelile tale. Detalii sunt în traducerea acestui text de la vicepreședintele de produs de la Grafana Labs.
Vineri, 19 iulie, serviciul Hosted Prometheus din Grafana Cloud a încetat să mai funcționeze pentru aproximativ 30 de minute. Îmi cer scuze tuturor clienților afectați de întrerupere. Sarcina noastră este să vă oferim instrumentele de monitorizare de care aveți nevoie și înțelegem că a nu le avea la dispoziție vă poate îngreuna viața. Luăm acest incident extrem de în serios. Această notă explică ce s-a întâmplat, cum am răspuns și ce facem pentru a ne asigura că nu se va mai întâmpla.
preistorie
Serviciul Grafana Cloud Hosted Prometheus se bazează pe — Proiect CNCF pentru a crea un serviciu Prometheus pentru mai mulți chiriași, scalabil orizontal, foarte disponibil. Arhitectura Cortex constă dintr-un set de microservicii individuale, fiecare dintre ele îndeplinește propria sa funcție: replicare, stocare, interogări etc. Cortex este în curs de dezvoltare activă și adaugă constant noi funcții și îmbunătățește performanța. Implementăm în mod regulat noi versiuni Cortex în clustere, astfel încât clienții să poată profita de aceste funcții - din fericire, Cortex poate fi actualizat fără timpi de nefuncționare.
Pentru actualizări fără întreruperi, serviciul Ingester Cortex necesită o replică Ingester suplimentară în timpul procesului de actualizare. (Notă. transl.: - componenta de baza a Cortexului. Sarcina sa este să colecteze un flux constant de mostre, să le grupeze în bucăți Prometheus și să le stocheze într-o bază de date precum DynamoDB, BigTable sau Cassandra.) Acest lucru permite vechilor Ingesters să trimită datele curente către noi Ingesters. Este demn de remarcat faptul că Ingesters necesită resurse. Pentru ca acestea să funcționeze, trebuie să aveți 4 nuclee și 15 GB de memorie per pod, adică. 25% din puterea de procesare și memoria mașinii de bază în cazul clusterelor noastre Kubernetes. În general, avem, de obicei, mult mai multe resurse neutilizate în cluster decât 4 nuclee și 15 GB de memorie, astfel încât să putem face cu ușurință aceste ingerere suplimentare în timpul upgrade-urilor.
Cu toate acestea, se întâmplă adesea ca, în timpul funcționării normale, niciuna dintre mașini să nu aibă aceste 25% din resursele neutilizate. Da, nici măcar nu ne străduim: CPU și memoria vor fi întotdeauna utile pentru alte procese. Pentru a rezolva această problemă, am decis să folosim . Ideea este de a acorda Ingesters o prioritate mai mare decât alte microservicii (apatride). Când trebuie să rulăm un Ingester suplimentar (N+1), înlocuim temporar alte păstăi mai mici. Aceste poduri sunt transferate în resurse gratuite pe alte mașini, lăsând o „gaură” suficient de mare pentru a rula un Ingester suplimentar.
Joi, 18 iulie, am lansat patru noi niveluri de prioritate pentru clusterele noastre: critic, mare, medie и scăzut. Au fost testate pe un cluster intern fără trafic de clienți timp de aproximativ o săptămână. În mod implicit, au primit poduri fără o prioritate specificată medie prioritate, clasa a fost stabilită pentru Ingestorii cu mare prioritate. Critic a fost rezervat pentru monitorizare (Prometheus, Alertmanager, node-exporter, kube-state-metrics etc.). Configurația noastră este deschisă și puteți vizualiza PR .
accident
Vineri, 19 iulie, unul dintre ingineri a lansat un nou cluster Cortex dedicat pentru un client mare. Configurația pentru acest cluster nu includea noi priorități pentru pod, astfel încât tuturor pod-urilor noi li sa atribuit o prioritate implicită - medie.
Clusterul Kubernetes nu avea suficiente resurse pentru noul cluster Cortex, iar clusterul Cortex de producție existent nu a fost actualizat (Ingestorii au rămas fără înalt prioritate). Din moment ce Ingestorii noului cluster au avut în mod implicit medie prioritate, iar podurile existente în producție au funcționat deloc fără prioritate, Ingestorii noului cluster au înlocuit Ingesters din clusterul de producție Cortex existent.
ReplicaSet pentru Ingester evacuat din clusterul de producție a detectat podul evacuat și a creat unul nou pentru a menține numărul specificat de copii. Noul pod a fost atribuit implicit medie prioritate, iar un alt „vechi” Ingester în producție și-a pierdut resursele. Rezultatul a fost proces de avalanșă, ceea ce a dus la deplasarea tuturor podurilor din Ingester pentru clusterele de producție Cortex.
Ingestorii sunt cu stare și stochează date pentru ultimele 12 ore. Acest lucru ne permite să le comprimăm mai eficient înainte de a le scrie în stocarea pe termen lung. Pentru a realiza acest lucru, Cortex împarte datele în serii utilizând un tabel de hash distribuit (DHT) și replic fiecare serie în trei Ingestere folosind consistența cvorumului în stil Dynamo. Cortex nu scrie date în Ingestere care sunt dezactivate. Astfel, atunci când un număr mare de ingerători părăsesc DHT, Cortex nu poate oferi o replicare suficientă a intrărilor și se blochează.
Detectare și remediere
Noi notificări Prometheus bazate pe „bugetul de eroare” (bazat pe erori — detaliile vor apărea într-un articol viitor) a început să sune alarma la 4 minute după începerea opririi. În următoarele cinci minute aproximativ, am efectuat câteva diagnostice și am extins clusterul Kubernetes de bază pentru a găzdui atât clusterele de producție noi, cât și cele existente.
După alte cinci minute, vechii Ingesters și-au scris cu succes datele, cele noi au pornit și clusterele Cortex au devenit din nou disponibile.
Alte 10 minute au fost petrecute diagnosticând și corectând erorile de memorie lipsită de memorie (OOM) de la proxy-urile inverse de autentificare situate în fața Cortex. Erorile OOM au fost cauzate de o creștere de zece ori a QPS (credem că din cauza solicitărilor excesiv de agresive de la serverele Prometheus ale clientului).
Aftermath
Timpul total de nefuncționare a fost de 26 de minute. Nu s-au pierdut date. Ingestorii au încărcat cu succes toate datele din memorie în stocarea pe termen lung. În timpul închiderii, serverele client Prometheus au fost șterse (de la distanță) înregistrări folosind bazat pe WAL (autorizat de de la Grafana Labs) și a repetat scrierile eșuate după accident.
Operațiuni de scriere a clusterului de producție
Constatări
Este important să învățați din acest incident și să luați măsurile necesare pentru a evita reapariția lui.
În retrospectivă, nu ar fi trebuit să setăm valoarea implicită medie prioritate până când toți Ingestorii în producție au primit mare o prioritate. În plus, era necesar să se îngrijească din timp de ei înalt prioritate. Totul este reparat acum. Sperăm că experiența noastră va ajuta alte organizații care iau în considerare utilizarea priorităților pod în Kubernetes.
Vom adăuga un nivel suplimentar de control asupra implementării oricăror obiecte suplimentare ale căror configurații sunt globale pentru cluster. De acum înainte, astfel de modificări vor fi evaluate bоmai multi oameni. În plus, modificarea care a provocat prăbușirea a fost considerată prea minoră pentru un document de proiect separat - a fost discutată doar într-o problemă GitHub. De acum înainte, toate astfel de modificări ale configurațiilor vor fi însoțite de documentația corespunzătoare a proiectului.
În cele din urmă, vom automatiza redimensionarea proxy-ului invers de autentificare pentru a preveni supraîncărcarea OOM la care am asistat și vom revizui setările implicite Prometheus legate de fallback și scalare pentru a preveni probleme similare în viitor.
Eșecul a avut și câteva consecințe pozitive: după ce a primit resursele necesare, Cortex și-a revenit automat fără intervenții suplimentare. De asemenea, am câștigat o experiență valoroasă de lucru cu - noul nostru sistem de agregare a jurnalelor - care ne-a ajutat să ne asigurăm că toți ingeratorii s-au comportat corect în timpul și după defecțiune.
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com