Noat. transl.: Wy presintearje oan jo oandacht technyske details oer de redenen foar de resinte downtime yn 'e wolktsjinst ûnderhâlden troch de makkers fan Grafana. Dit is in klassyk foarbyld fan hoe't in nije en skynber ekstreem brûkbere funksje ûntworpen om de kwaliteit fan ynfrastruktuer te ferbetterjen ... skea kin feroarsaakje as jo net soargje foar de ferskate nuânses fan har tapassing yn 'e realiteit fan produksje. It is geweldich as materialen lykas dit ferskine wêrmei jo net allinich kinne leare fan jo flaters. Details binne yn 'e oersetting fan dizze tekst fan' e fise-presidint fan produkt fan Grafana Labs.
Op freed 19 july stoppe de Hosted Prometheus-tsjinst yn Grafana Cloud mei funksjonearjen foar sawat 30 minuten. Ik ferûntskuldigje alle klanten dy't beynfloede binne troch de ûnderbrekking. Us taak is om de monitoaringsark te leverjen dy't jo nedich binne, en wy begripe dat it net beskikber is jo libben dreger kin meitsje. Wy nimme dit ynsidint ekstreem serieus. Dizze notysje ferklearret wat der bard is, hoe't wy reagearren en wat wy dogge om te soargjen dat it net wer bart.
prehistoarje
Grafana Cloud Hosted Prometheus tsjinst is basearre op - CNCF-projekt om in horizontaal skalberbere, heech beskikbere Prometheus-tsjinst foar meardere hierders te meitsjen. De Cortex-arsjitektuer bestiet út in set fan yndividuele mikrotsjinsten, dy't elk har eigen funksje útfiert: replikaasje, opslach, queries, ensfh. Cortex is ûnder aktive ûntwikkeling en foegje konstant nije funksjes ta en ferbetterje prestaasjes. Wy sette geregeld nije Cortex-releases yn yn klusters, sadat klanten kinne profitearje fan dizze funksjes - gelokkich kin Cortex wurde bywurke sûnder downtime.
Foar naadleaze updates fereasket de Ingester Cortex-tsjinst in ekstra Ingester-replika tidens it fernijingsproses. (Noat. transl.: - de basiskomponint fan 'e Cortex. Syn taak is om in konstante stream fan samples te sammeljen, se te groepearjen yn Prometheus-brokken en op te slaan yn in database lykas DynamoDB, BigTable of Cassandra.) Hjirmei kinne âlde Ingesters aktuele gegevens trochstjoere nei nije Ingesters. It is de muoite wurdich opskriuwen dat Ingesters binne boarne-easket. Om se te wurkjen moatte jo 4 kearnen en 15 GB ûnthâld hawwe per pod, d.w.s. 25% fan 'e ferwurkingskrêft en ûnthâld fan' e basismasine yn 't gefal fan ús Kubernetes-klusters. Yn 't algemien hawwe wy normaal folle mear net brûkte boarnen yn it kluster dan 4 kearnen en 15 GB ûnthâld, sadat wy dizze ekstra ingesters maklik kinne spinne by upgrades.
It bart lykwols faak dat by normale operaasje gjin fan 'e masines dizze 25% fan net brûkte boarnen hat. Ja, wy stribje net iens: CPU en ûnthâld sille altyd nuttich wêze foar oare prosessen. Om dit probleem op te lossen, hawwe wy besletten om te brûken . It idee is om Ingesters in hegere prioriteit te jaan as oare (steateleaze) mikrotsjinsten. As wy in ekstra (N+1) Ingester moatte útfiere, ferpleatse wy tydlik oare, lytsere pods. Dizze pods wurde oerdroegen oan frije boarnen op oare masines, wêrtroch in grut genôch "gat" is om in ekstra Ingester út te fieren.
Op tongersdei 18 july hawwe wy fjouwer nije prioriteitsnivo's útrol nei ús klusters: kritysk, tall, gemiddelde и leech. Se waarden testen op in ynterne kluster mei gjin klantferkear foar sawat ien wike. Standert wurde pods sûnder in spesifisearre prioriteit ûntfongen gemiddelde prioriteit, klasse waard ynsteld foar Ingesters mei heech prioriteit. Kritysk wie reservearre foar tafersjoch (Prometheus, Alertmanager, node-eksporteur, kube-state-metrics, ensfh.). Us konfiguraasje is iepen, en jo kinne de PR besjen .
Ungelok
Op freed 19 july lansearre ien fan 'e yngenieurs in nij tawijd Cortex-kluster foar in grutte klant. De konfiguraasje foar dit kluster omfette gjin nije podprioriteiten, dus alle nije pods waarden in standertprioriteit tawiisd - gemiddelde.
It Kubernetes-kluster hie net genôch boarnen foar it nije Cortex-kluster, en it besteande produksje-Cortex-kluster waard net bywurke (Ingesters wiene sûnder heech prioriteit). Sûnt de Ingesters fan it nije kluster standert hie gemiddelde prioriteit, en de besteande pods yn produksje wurken sûnder prioriteit hielendal, de Ingesters fan it nije kluster ferfongen de Ingesters út de besteande Cortex produksje kluster.
ReplicaSet foar de útstutsen Ingester yn it produksjekluster ûntdekte de útstutsen pod en makke in nije om it opjûne oantal kopyen te behâlden. De nije pod waard standert tawiisd gemiddelde prioriteit, en in oare "âlde" Ingester yn produksje ferlear syn middels. It resultaat wie lawine proses, dy't late ta de ferpleatsing fan alle pods út Ingester foar Cortex produksje klusters.
Ingesters binne stateful en bewarje gegevens foar de foargeande 12 oeren. Hjirmei kinne wy se effisjinter komprimearje foardat se se op lange termyn opslach skriuwe. Om dit te berikken, snijt Cortex gegevens oer searjes mei in Distributed Hash Table (DHT) en replikearret elke searje oer trije Ingesters mei help fan Dynamo-styl quorum-konsistinsje. Cortex skriuwt gjin gegevens nei Ingesters dy't útskeakele binne. Dus, as in grut oantal Ingesters de DHT ferlitte, kin Cortex net genôch replikaasje fan 'e yngongen leverje, en se crashje.
Deteksje en sanearring
Nije Prometheus-notifikaasjes basearre op "flaterbudzjet" (flater-budzjet-basearre - details sille ferskine yn in takomstich artikel) begon it alarm 4 minuten nei it begjin fan 'e shutdown te klinken. Yn 'e folgjende fiif minuten of sa hawwe wy wat diagnostyk útfierd en it ûnderlizzende Kubernetes-kluster opskaald om sawol de nije as besteande produksjeklusters te hostjen.
Nei noch fiif minuten skreaunen de âlde Ingesters har gegevens mei súkses, de nije begûnen op, en de Cortex-klusters waarden wer beskikber.
In oare 10 minuten waarden bestege oan diagnoaze en korrigearjen fan out-of-memory (OOM) flaters fan autentikaasje omkearde proxy's foar Cortex. OOM-flaters waarden feroarsake troch in tsienfâldich ferheging fan QPS (wy leauwe fanwege te agressive oanfragen fan 'e Prometheus-tsjinners fan' e kliïnt).
Consequences
De totale downtime wie 26 minuten. Gjin gegevens binne ferlern gien. Ingesters hawwe alle gegevens yn it ûnthâld mei súkses laden yn opslach op lange termyn. Tidens de shutdown, client Prometheus tsjinners buffered wiske (ôfstân) opnames mei help basearre op WAL (skreaun troch fan Grafana Labs) en werhelle de mislearre skriuwingen nei de crash.
Produksjekluster skriuwoperaasjes
befinings
It is wichtich om te learen fan dit ynsidint en de nedige stappen te nimmen om it weromkommen te foarkommen.
Efterôf soene wy de standert net moatte ynstelle gemiddelde prioriteit oant alle Ingesters yn produksje hawwe ûntfongen tall in prioriteit. Dêrneist wie it nedich om te soargjen foar harren foarôf heech prioriteit. Alles is no fêst. Wy hoopje dat ús ûnderfining oare organisaasjes sil helpe by it brûken fan podprioriteiten yn Kubernetes.
Wy sille in ekstra nivo fan kontrôle tafoegje oer de ynset fan ekstra objekten wêrfan de konfiguraasjes wrâldwiid binne foar it kluster. Sokke feroarings wurde fan no ôf beoardiele bоmear minsken. Derneist waard de wiziging dy't de crash feroarsake waard beskôge as te lyts foar in apart projektdokumint - it waard allinich besprutsen yn in GitHub-kwestje. Fan no ôf sille al sokke wizigingen oan konfiguraasjes wurde begelaat troch passende projektdokumintaasje.
Uteinlik sille wy it feroarjen fan grutte fan 'e autentikaasje omkearde proxy automatisearje om de oerlêst OOM te foarkommen dy't wy tsjûge hawwe, en sille Prometheus standertynstellingen besjogge relatearre oan fallback en skaalfergrutting om ferlykbere problemen yn' e takomst te foarkommen.
It mislearjen hie ek wat positive gefolgen: nei it ûntfangen fan de nedige middels, herstelde Cortex automatysk sûnder ekstra yntervinsje. Wy hawwe ek weardefolle ûnderfining opdien mei it wurkjen mei - ús nije log-aggregaasjesysteem - dat holp derfoar dat alle Ingesters har goed gedragen tidens en nei it mislearjen.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com