Nota. transl.: Presentem a la vostra atenció detalls tècnics sobre els motius del recent temps d'inactivitat del servei al núvol mantingut pels creadors de Grafana. Aquest és un exemple clàssic de com una característica nova i aparentment extremadament útil dissenyada per millorar la qualitat de la infraestructura... pot causar danys si no es preveuen els nombrosos matisos de la seva aplicació en les realitats de producció. És fantàstic quan apareixen materials com aquest que et permeten aprendre no només dels teus errors. Els detalls es troben a la traducció d'aquest text del vicepresident de producte de Grafana Labs.
El divendres 19 de juliol, el servei Hosted Prometheus a Grafana Cloud va deixar de funcionar durant uns 30 minuts aproximadament. Demano disculpes a tots els clients afectats per l'interrupció. La nostra feina és proporcionar les eines de seguiment que necessiteu, i entenem que no tenir-les disponibles pot dificultar la vostra vida. Ens prenem aquest incident molt seriosament. Aquesta nota explica què va passar, com vam respondre i què estem fent per garantir que no torni a passar.
prehistòria
Es basa en el servei Grafana Cloud Hosted Prometheus — Projecte CNCF per crear un servei Prometheus multi-inquilí, escalable horitzontalment, d'alta disponibilitat. L'arquitectura Cortex consta d'un conjunt de microserveis individuals, cadascun dels quals realitza la seva pròpia funció: replicació, emmagatzematge, consultes, etc. Cortex està en desenvolupament actiu i està constantment afegint noves funcions i millorant el rendiment. Implementem regularment noves versions de Cortex als clústers perquè els clients puguin aprofitar aquestes funcions; afortunadament, Cortex es pot actualitzar sense temps d'inactivitat.
Per a actualitzacions sense problemes, el servei Ingester Cortex requereix una rèplica addicional d'Ingester durant el procés d'actualització. (Nota. transl.: - el component bàsic de l'escorça. La seva feina és recollir un flux constant de mostres, agrupar-les en trossos de Prometheus i emmagatzemar-les en una base de dades com DynamoDB, BigTable o Cassandra.) Això permet als antics Ingesters reenviar les dades actuals als nous Ingesters. Val la pena assenyalar que els Ingesters requereixen recursos. Perquè funcionin, cal tenir 4 nuclis i 15 GB de memòria per pod, és a dir. 25% de la potència de processament i memòria de la màquina base en el cas dels nostres clústers Kubernetes. En general, normalment tenim molts més recursos no utilitzats al clúster que 4 nuclis i 15 GB de memòria, de manera que podem activar fàcilment aquests ingeridors addicionals durant les actualitzacions.
No obstant això, sovint passa que durant el funcionament normal cap de les màquines té aquest 25% de recursos no utilitzats. Sí, ni tan sols ens esforcem: la CPU i la memòria sempre seran útils per a altres processos. Per resoldre aquest problema, vam decidir utilitzar . La idea és donar a Ingesters una prioritat més alta que altres microserveis (sense estat). Quan necessitem executar un injector addicional (N+1), desplaçarem temporalment altres beines més petites. Aquestes beines es transfereixen a recursos gratuïts en altres màquines, deixant un "forat" prou gran per executar un Ingester addicional.
El dijous 18 de juliol vam implementar quatre nous nivells de prioritat als nostres clústers: crític, alt, mitjana и sota. Es van provar en un clúster intern sense trànsit de clients durant aproximadament una setmana. Per defecte, es reben pods sense una prioritat especificada mitjana prioritat, la classe es va establir per a Ingesters amb alt prioritat. Crític estava reservat per al seguiment (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). La nostra configuració està oberta i podeu veure el PR .
Crash
El divendres 19 de juliol, un dels enginyers va llançar un nou clúster Cortex dedicat per a un gran client. La configuració d'aquest clúster no incloïa noves prioritats de pods, de manera que tots els pods nous tenien una prioritat predeterminada: mitjana.
El clúster de Kubernetes no tenia prou recursos per al nou clúster Cortex, i el clúster Cortex de producció existent no es va actualitzar (els Ingesters es van quedar sense alt prioritat). Atès que els Ingesters del nou clúster per defecte tenien mitjana prioritat i els pods existents en producció funcionaven sense prioritat, els Ingesters del nou clúster van substituir els Ingesters del clúster de producció de Cortex existent.
ReplicaSet per a l'Ingester desallotjat al clúster de producció va detectar el pod desallotjat i en va crear un de nou per mantenir el nombre especificat de còpies. El pod nou s'ha assignat per defecte mitjana prioritat, i un altre "vell" Ingester en producció va perdre els seus recursos. El resultat va ser procés d'allau, que va provocar el desplaçament de totes les beines d'Ingester per als clústers de producció de Cortex.
Els ingeridors són amb estat i emmagatzemen dades de les 12 hores anteriors. Això ens permet comprimir-los de manera més eficient abans d'escriure'ls a l'emmagatzematge a llarg termini. Per aconseguir-ho, Cortex divideix les dades entre sèries mitjançant una taula de hash distribuïda (DHT) i replica cada sèrie en tres ingestors mitjançant la coherència de quòrum d'estil Dynamo. Cortex no escriu dades a Ingesters que estiguin desactivats. Així, quan un gran nombre d'ingestors surten del DHT, Cortex no pot proporcionar una rèplica suficient de les entrades i s'estavella.
Detecció i reparació
Noves notificacions de Prometheus basades en "pressupost d'error" (basat en errors pressupostaris (els detalls apareixeran en un article futur) van començar a sonar l'alarma 4 minuts després de l'inici de l'aturada. Durant els cinc minuts següents aproximadament, vam executar alguns diagnòstics i vam ampliar el clúster de Kubernetes subjacent per allotjar tant els clústers de producció nous com els existents.
Després de cinc minuts més, els antics Ingesters van escriure amb èxit les seves dades, els nous van començar i els clústers de Cortex van tornar a estar disponibles.
Es van dedicar 10 minuts més a diagnosticar i corregir errors sense memòria (OOM) dels servidors intermediaris inversos d'autenticació situats davant de Cortex. Els errors OOM van ser causats per un augment de deu vegades en QPS (creiem que a causa de sol·licituds massa agressives dels servidors Prometheus del client).
Conseqüències
El temps total d'inactivitat va ser de 26 minuts. No s'ha perdut cap dada. Els ingesters han carregat amb èxit totes les dades de la memòria a l'emmagatzematge a llarg termini. Durant l'aturada, els servidors client Prometheus s'han eliminat (remotament) enregistraments utilitzant basat en WAL (autoritzat per de Grafana Labs) i va repetir les escriptures fallides després de l'accident.
Operacions d'escriptura de clúster de producció
Troballes
És important aprendre d'aquest incident i prendre les mesures necessàries per evitar que es repeteixi.
En retrospectiva, no hauríem d'haver establert el valor predeterminat mitjana prioritat fins que tots els Ingesters en producció hagin rebut alt una prioritat. A més, calia cuidar-los amb antelació alt prioritat. Ara està tot arreglat. Esperem que la nostra experiència ajudi a altres organitzacions que es plantegin utilitzar les prioritats dels pods a Kubernetes.
Afegirem un nivell addicional de control sobre el desplegament de qualsevol objecte addicional les configuracions dels quals siguin globals al clúster. A partir d'ara, aquests canvis seran avaluats bоmés gent. A més, la modificació que va provocar l'accident es va considerar massa menor per a un document de projecte separat; només es va discutir en un problema de GitHub. A partir d'ara, tots aquests canvis a les configuracions aniran acompanyats de la documentació adequada del projecte.
Finalment, automatitzarem el redimensionament del servidor intermediari invers d'autenticació per evitar la sobrecàrrega OOM que vam presenciar, i revisarem la configuració predeterminada de Prometheus relacionada amb la reserva i l'escalat per evitar problemes similars en el futur.
El fracàs també va tenir algunes conseqüències positives: havent rebut els recursos necessaris, Cortex es va recuperar automàticament sense intervenció addicional. També hem adquirit una valuosa experiència treballant - el nostre nou sistema d'agregació de registres, que va ajudar a garantir que tots els Ingesters es comportaven correctament durant i després de la fallada.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com