Poznámka. preklad.: Predstavujeme vám technické podrobnosti o dôvodoch nedávneho výpadku v cloudovej službe spravovanej tvorcami Grafany. Toto je klasický príklad toho, ako nová a zdanlivo mimoriadne užitočná funkcia určená na zlepšenie kvality infraštruktúry... môže spôsobiť škodu, ak nezohľadníte početné nuansy jej aplikácie v realite výroby. Je skvelé, keď sa objavia materiály ako tento, ktoré vám umožnia poučiť sa nielen zo svojich chýb. Podrobnosti sú v preklade tohto textu od viceprezidenta pre produkt z Grafana Labs.
V piatok 19. júla prestala na približne 30 minút fungovať služba Hosted Prometheus v Grafana Cloud. Ospravedlňujem sa všetkým zákazníkom, ktorých sa výpadok týka. Našou úlohou je poskytovať nástroje na monitorovanie, ktoré potrebujete, a chápeme, že ak ich nemáte k dispozícii, môže vám to skomplikovať život. Tento incident berieme mimoriadne vážne. Táto poznámka vysvetľuje, čo sa stalo, ako sme reagovali a čo robíme, aby sa to už neopakovalo.
pravek
Služba Grafana Cloud Hosted Prometheus je založená na — Projekt CNCF na vytvorenie horizontálne škálovateľnej, vysoko dostupnej služby Prometheus pre viacerých nájomníkov. Architektúra Cortex pozostáva zo sady jednotlivých mikroslužieb, z ktorých každá vykonáva svoju vlastnú funkciu: replikácia, ukladanie, dotazy atď. Cortex sa aktívne vyvíja a neustále pridáva nové funkcie a zlepšuje výkon. Pravidelne nasadzujeme nové vydania Cortexu do klastrov, aby zákazníci mohli využívať tieto funkcie – našťastie je možné Cortex aktualizovať bez prestojov.
Pre bezproblémové aktualizácie vyžaduje služba Ingester Cortex počas procesu aktualizácie ďalšiu repliku Ingester. (Poznámka. preklad.: - základná zložka Cortexu. Jeho úlohou je zbierať neustály prúd vzoriek, zoskupovať ich do častí Prometheus a ukladať ich do databázy ako DynamoDB, BigTable alebo Cassandra.) To umožňuje starým Ingesterom posielať aktuálne údaje novým Ingesterom. Stojí za zmienku, že Ingesters sú náročné na zdroje. Na ich fungovanie potrebujete mať 4 jadrá a 15 GB pamäte na pod, t.j. 25 % výpočtového výkonu a pamäte základného stroja v prípade našich klastrov Kubernetes. Vo všeobecnosti máme v klastri zvyčajne oveľa viac nevyužitých zdrojov ako 4 jadrá a 15 GB pamäte, takže tieto ďalšie ingestery môžeme počas upgradov ľahko roztočiť.
Často sa však stáva, že pri bežnej prevádzke ani jeden zo strojov nemá týchto 25 % nevyužitých zdrojov. Áno, ani sa nesnažíme: CPU a pamäť budú vždy užitočné pre iné procesy. Na vyriešenie tohto problému sme sa rozhodli použiť . Cieľom je dať Ingesters vyššiu prioritu ako iné (bezstavové) mikroslužby. Keď potrebujeme spustiť ďalší (N+1) Ingester, dočasne vytlačíme iné, menšie struky. Tieto moduly sa prenesú do voľných zdrojov na iných počítačoch, pričom zostane dostatočne veľká „diera“ na spustenie ďalšieho Ingesteru.
Vo štvrtok 18. júla sme pre naše klastre zaviedli štyri nové úrovne priority: kritický, vysoký, priemerný и nízky. Boli testované na internom klastri bez návštevnosti klienta počas približne jedného týždňa. V predvolenom nastavení sa prijímajú moduly bez určenej priority priemerný priorita bola stanovená trieda pre Ingesterov s vysoký prioritou. Kritické bol vyhradený na monitorovanie (Prometheus, Alertmanager, node-exporter, kube-state-metrics atď.). Naša konfigurácia je otvorená a môžete si pozrieť PR .
nehoda
V piatok 19. júla jeden z inžinierov spustil nový vyhradený klaster Cortex pre veľkého klienta. Konfigurácia pre tento klaster nezahŕňala nové priority pod, takže všetkým novým modulom bola priradená predvolená priorita - priemerný.
Klaster Kubernetes nemal dostatok zdrojov pre nový klaster Cortex a existujúci produkčný klaster Cortex nebol aktualizovaný (Ingesters zostali bez vysoká priorita). Keďže Ingesters nového klastra v predvolenom nastavení mali priemerný a existujúce moduly vo výrobe fungovali úplne bez priority, Ingesters nového klastra nahradili Ingestery z existujúceho produkčného klastra Cortex.
ReplicaSet pre vysťahovaný Ingester v produkčnom klastri rozpoznal vysťahovaný modul a vytvoril nový, aby sa zachoval stanovený počet kópií. Nový modul bol priradený predvolene priemerný a ďalší „starý“ Ingester vo výrobe stratil svoje zdroje. Výsledok bol lavínový proces, čo viedlo k premiestneniu všetkých modulov z Ingesteru pre produkčné klastre Cortex.
Ingesters sú stavové a uchovávajú údaje za predchádzajúcich 12 hodín. To nám umožňuje ich efektívnejšiu kompresiu pred ich zápisom do dlhodobého úložiska. Aby sa to dosiahlo, Cortex rozdelí údaje naprieč sériami pomocou distribuovanej tabuľky hash (DHT) a replikuje každú sériu medzi tromi Ingestermi pomocou konzistencie kvóra v štýle Dynamo. Cortex nezapisuje údaje do Ingesterov, ktoré sú zakázané. Keď teda veľké množstvo Ingesterov opustí DHT, Cortex nedokáže zabezpečiť dostatočnú replikáciu záznamov a zlyhávajú.
Detekcia a náprava
Nové upozornenia Prometheus založené na „chybovom rozpočte“ (založené na chybovom rozpočte — podrobnosti sa objavia v budúcom článku) začal znieť alarm 4 minúty po začiatku vypnutia. Počas nasledujúcich približne piatich minút sme spustili nejakú diagnostiku a zväčšili základný klaster Kubernetes tak, aby hostil nové aj existujúce produkčné klastre.
Po ďalších piatich minútach staré Ingestery úspešne zapísali svoje údaje, spustili sa nové a klastre Cortex boli opäť dostupné.
Ďalších 10 minút sa venovalo diagnostike a oprave chýb s nedostatkom pamäte (OOM) z overovacích reverzných proxy umiestnených pred Cortexom. Chyby OOM boli spôsobené desaťnásobným zvýšením QPS (domnievame sa, že kvôli príliš agresívnym požiadavkám zo serverov Prometheus klienta).
účinky
Celková odstávka bola 26 minút. Žiadne údaje sa nestratili. Ingesters úspešne nahrali všetky údaje v pamäti do dlhodobého úložiska. Počas vypnutia boli klientske servery Prometheus uložené vo vyrovnávacej pamäti odstránené (na diaľku) pomocou nahrávok založené na WAL (autorom z Grafana Labs) a zopakoval neúspešné zápisy po havárii.
Operácie zápisu produkčného klastra
Závery
Je dôležité poučiť sa z tohto incidentu a podniknúť potrebné kroky, aby sa zabránilo jeho opakovaniu.
Pri spätnom pohľade by sme nemali nastaviť predvolené nastavenie priemerný prioritu, kým nebudú obdržané všetky Ingestery vo výrobe vysoký prioritou. Navyše bolo potrebné sa o ne vopred postarať vysoká prioritou. Teraz je všetko opravené. Dúfame, že naše skúsenosti pomôžu ďalším organizáciám, ktoré zvažujú použitie priorít pod v Kubernetes.
Pridáme ďalšiu úroveň kontroly nad nasadením akýchkoľvek ďalších objektov, ktorých konfigurácie sú globálne pre klaster. Odteraz sa budú takéto zmeny posudzovať bоviac ľudí. Okrem toho sa úprava, ktorá spôsobila pád, považovala za príliš malú na samostatný projektový dokument – diskutovalo sa o nej iba v čísle GitHub. Odteraz budú všetky takéto zmeny konfigurácií sprevádzané príslušnou projektovou dokumentáciou.
Nakoniec zautomatizujeme zmenu veľkosti reverzného servera proxy na overenie, aby sme zabránili preťaženiu OOM, ktorého sme boli svedkami, a skontrolujeme predvolené nastavenia spoločnosti Prometheus súvisiace s núdzovým nastavením a škálovaním, aby sa v budúcnosti zabránilo podobným problémom.
Zlyhanie malo aj niektoré pozitívne dôsledky: po získaní potrebných zdrojov sa Cortex automaticky zotavil bez ďalšieho zásahu. Získali sme tiež cenné skúsenosti s prácou s - náš nový systém agregácie protokolov - ktorý pomohol zabezpečiť, aby sa všetci Ingesters správali správne počas zlyhania a po ňom.
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com