Nota. transl.: Avemu prisentatu à a vostra attenzione ditaglii tecnichi nantu à i mutivi di l'ultimi tempi di inattività in u serviziu di nuvola mantinutu da i creatori di Grafana. Questu hè un esempiu classicu di cumu una funzione nova è apparentemente estremamente utile pensata per migliurà a qualità di l'infrastruttura ... pò causà danni si ùn furnisce micca i numerosi sfumaturi di a so applicazione in a realità di a produzzione. Hè bellu quandu i materiali cum'è questu appariscenu chì permettenu di amparà micca solu da i vostri sbagli. I dettagli sò in a traduzzione di stu testu da u vicepresidentu di produttu da Grafana Labs.
U venneri 19 di lugliu, u serviziu Hosted Prometheus in Grafana Cloud hà cessatu di funziunà per circa 30 minuti. Mi scusa à tutti i clienti affettati da l'interruzione. U nostru travagliu hè di furnisce i strumenti di surviglianza chì avete bisognu, è capimu chì ùn avè micca dispunibuli pò rende a vostra vita più difficiule. Pigliemu stu incidente estremamente seriu. Questa nota spiega ciò chì hè accadutu, cumu avemu rispostu, è ciò chì facemu per assicurà chì ùn succede micca.
Pristoria
U serviziu di Grafana Cloud Hosted Prometheus hè basatu annantu — Prughjettu CNCF per creà un serviziu Prometheus multi-tenant scalabile orizontale, altamente dispunibile. L'architettura di Cortex hè custituita da un inseme di microservizi individuali, ognuna di quale svolge a so propria funzione: replicazione, almacenamiento, dumande, etc. Cortex hè in sviluppu attivu è aghjunghjenu constantemente novi funzioni è migliurà u rendiment. Implementemu regularmente novi versioni di Cortex in clusters in modu chì i clienti ponu prufittà di queste funzioni - per furtuna, Cortex pò esse aghjurnatu senza tempi di inattività.
Per aghjurnamenti senza saldatura, u serviziu Ingester Cortex richiede una replica Ingester addiziale durante u prucessu di aghjurnamentu. (Nota. transl.: - u cumpunenti basi di u Cortex. U so travagliu hè di cullà un flussu constante di campioni, raggruppalli in pezzi di Prometheus è almacenà in una basa di dati cum'è DynamoDB, BigTable o Cassandra.) Questu permette à i vechji Ingesters di trasmette i dati attuali à i novi Ingesters. Hè da nutà chì Ingesters sò esigenti risorse. Per elli à travaglià, avete bisognu à avè 4 core è 15 GB di memoria per pod, i.e. 25% di a putenza di trasfurmazioni è a memoria di a macchina di basa in u casu di i nostri clusters Kubernetes. In generale, avemu di solitu assai più risorse inutilizate in u cluster cà 4 core è 15 GB di memoria, cusì pudemu facilmente spin up sti ingesters supplementari durante l'aghjurnamenti.
In ogni casu, spessu succede chì durante u funziunamentu normale nimu di e macchine ùn anu stu 25% di risorse inutilizate. Iè, ùn avemu mancu sforzu: CPU è memoria seranu sempre utili per altri prucessi. Per risolve stu prublema, avemu decisu di utilizà . L'idea hè di dà à Ingesters una priorità più altu ch'è l'altri microservizi (stateless). Quandu avemu bisognu di eseguisce un Ingester supplementu (N + 1), spostemu temporaneamente altri pods più chjuchi. Questi pods sò trasferiti à risorse gratuiti in altre macchine, lascendu un "bucu" abbastanza grande per eseguisce un Ingester supplementu.
Ghjovi 18 di lugliu, avemu lanciatu quattru novi livelli di priorità à i nostri clusters: criticu, alta, media и bassa. Sò stati pruvati nantu à un cluster internu senza trafficu di clientella per circa una settimana. Per difettu, i pods senza una priorità specificata ricevuti media priurità, classa hè stata stabilita per Ingesters cù altu priurità. Criticu era riservatu per u monitoraghju (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). A nostra cunfigurazione hè aperta, è pudete vede u PR .
Crash
U venneri 19 di lugliu, unu di l'ingegneri hà lanciatu un novu cluster Cortex dedicatu per un grande cliente. A cunfigurazione per questu cluster ùn includeva micca e nuove priorità di pod, cusì tutti i novi pods sò stati attribuiti una priorità predeterminata - media.
U cluster Kubernetes ùn hà micca abbastanza risorse per u novu cluster Cortex, è u cluster Cortex di produzzione esistente ùn hè micca aghjurnatu (Ingesters sò stati lasciati senza altu priorità). Dapoi u Ingesters di u novu cluster per difettu avia media priurità, è i baccelli esistenti in a pruduzzione hà travagliatu senza priorità à tutti, l'Ingesters di u novu cluster rimpiazzatu l'Ingesters da u cluster di produzzione Cortex esistenti.
ReplicaSet per l'Ingester scacciatu in u cluster di pruduzzione hà rilevatu u pod spulatu è hà creatu un novu per mantene u numeru specificatu di copie. U novu pod hè statu assignatu per difettu media priurità, è un altru "vechju" Ingester in pruduzzione persu i so risorsi. U risultatu era prucessu di avalanche, chì hà purtatu à u spustamentu di tutti i pods da Ingester per i clusters di produzzione di Cortex.
Ingesters sò stateful è almacenanu dati per l'ora di 12 precedenti. Questu ci permette di cumpressà in modu più efficau prima di scrivite in u almacenamiento à longu andà. Per ottene questu, Cortex shards data in a serie utilizendu una Distributed Hash Table (DHT) è replica ogni serie in trè Ingesters utilizendu a coerenza di quorum in stile Dynamo. Cortex ùn scrive micca dati à Ingesters chì sò disattivati. Cusì, quandu un gran numaru di Ingesters abbanduneghja u DHT, Cortex ùn pò micca furnisce una replicazione sufficiente di e entrate, è crash.
Rilevazione è Remediazione
Nove notificazioni Prometheus basate nantu à "budget d'errore" (basata nantu à l'errore - i dettagli appariscenu in un articulu futuru) hà cuminciatu à sonà l'alarma 4 minuti dopu l'iniziu di a chjusa. In i prossimi cinque minuti o più, avemu eseguitu alcuni diagnostichi è scalatu u cluster Kubernetes sottostante per accoglie i clusters di produzzione novi è esistenti.
Dopu à altri cinque minuti, i vechji Ingesters hà scrittu bè i so dati, i novi cuminciaru, è i clusters di Cortex tornanu dispunibuli.
Altri 10 minuti sò stati passati à diagnosticà è corregge l'errori fora di memoria (OOM) da i proxy inversi di autentificazione situati davanti à Cortex. L'errori OOM sò stati causati da un aumentu di deci volte in QPS (credemu per via di richieste troppu aggressive da i servitori Prometheus di u cliente).
Cunsiquenzi
U tempu d'inattività tutale era di 26 minuti. Nisuna dati hè statu persu. Ingesters anu caricatu cù successu tutti i dati in memoria in u almacenamiento à longu andà. Durante l'arrestu, i servitori client Prometheus buffered eliminati (à distanza) registrazioni usendu basatu annantu à WAL (autoru da da Grafana Labs) è hà ripetutu a scrittura falluta dopu à u crash.
Operazioni di scrittura di cluster di produzzione
scuperti
Hè impurtante d'amparà da stu incidente è piglià i passi necessarii per evità a so recurrente.
In retrospettiva, ùn duvemu micca stabilitu u predeterminatu media priurità finu à chì tutti Ingesters in a pruduzzione anu ricevutu alta una priorità. Inoltre, era necessariu di piglià cura di elli in anticipu altu priurità. Tuttu hè riparatu avà. Speremu chì a nostra sperienza aiuterà altre urganisazioni chì pensanu à utilizà e priorità di pod in Kubernetes.
Aghjunghjeremu un livellu supplementu di cuntrollu nantu à a implementazione di qualsiasi oggetti supplementari chì e cunfigurazioni sò glubale à u cluster. Da avà, tali cambiamenti seranu valutati bоpiù persone. Inoltre, a mudificazione chì hà causatu u crash hè stata cunsiderata troppu minore per un documentu di prughjettu separatu - hè statu discutitu solu in un prublema di GitHub. Da avà, tutti questi cambiamenti à a cunfigurazione seranu accumpagnati da a documentazione adatta di u prugettu.
Infine, automatizeremu u ridimensionamentu di u proxy inversu di l'autentificazione per prevene l'OOM sovraccarico chì avemu vistu, è rivederemu i paràmetri predeterminati di Prometheus in relazione à fallback è scala per prevene prublemi simili in u futuru.
U fallimentu hà avutu ancu cunsiquenzi pusitivi: avè ricevutu i risorse necessarii, Cortex hà recuperatu automaticamente senza intervenzione supplementaria. Avemu ancu acquistatu una sperienza preziosa di travaglià cun - u nostru novu sistema di aggregazione di log - chì hà aiutatu à assicurà chì tutti l'Ingesters si cumportanu bè durante è dopu à u fallimentu.
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com