Pastaba. vert.: Jūsų dėmesiui pateikiame technines detales apie priežastis, dėl kurių pastaruoju metu dingo Grafana kūrėjų palaikoma debesijos paslauga. Tai klasikinis pavyzdys, kaip nauja ir, atrodytų, itin naudinga infrastruktūros kokybei gerinti skirta funkcija... gali pakenkti, jei nenumatysite daugybės jos taikymo niuansų gamybos realybėje. Puiku, kai atsiranda tokių medžiagų, kurios leidžia mokytis ne tik iš savo klaidų. Išsamią informaciją rasite šio teksto vertime iš Grafana Labs produkto viceprezidento.
Penktadienį, liepos 19 d., „Hosted Prometheus“ paslauga Grafana Cloud nustojo veikti maždaug 30 minučių. Atsiprašau visų klientų, kuriuos paveikė gedimas. Mūsų darbas – suteikti jums reikalingas stebėjimo priemones ir suprantame, kad jų neturėjimas gali apsunkinti jūsų gyvenimą. Į šį įvykį žiūrime labai rimtai. Šioje pastaboje paaiškinama, kas atsitiko, kaip reagavome ir ką darome, kad tai nepasikartotų.
priešistorė
„Grafana Cloud Hosted Prometheus“ paslauga yra pagrįsta — CNCF projektas, skirtas sukurti horizontaliai keičiamą, labai prieinamą, kelių nuomininkų „Prometheus“ paslaugą. „Cortex“ architektūra susideda iš atskirų mikro paslaugų rinkinio, kurių kiekviena atlieka savo funkcijas: replikacija, saugykla, užklausos ir kt. „Cortex“ yra aktyviai kuriama ir nuolat prideda naujų funkcijų bei gerina našumą. Reguliariai diegiame naujus „Cortex“ leidimus grupėse, kad klientai galėtų pasinaudoti šiomis funkcijomis – laimei, „Cortex“ galima atnaujinti be prastovų.
Kad naujinimai būtų sklandūs, „Ingester Cortex“ paslaugai atnaujinimo proceso metu reikalinga papildoma „Ingester“ kopija. (Pastaba. vert.: - pagrindinis žievės komponentas. Jo užduotis yra rinkti nuolatinį mėginių srautą, sugrupuoti juos į Prometheus dalis ir saugoti duomenų bazėje, pvz., DynamoDB, BigTable ar Cassandra.) Tai leidžia seniems „Ingester“ persiųsti esamus duomenis naujiems „Ingester“ naudotojams. Verta paminėti, kad ingesteriai reikalauja daug išteklių. Kad jie veiktų, reikia turėti 4 branduolius ir po 15 GB atminties, t.y. 25% bazinės mašinos apdorojimo galios ir atminties mūsų Kubernetes klasterių atveju. Apskritai klasteryje paprastai turime daug daugiau nepanaudotų resursų nei 4 branduoliai ir 15 GB atminties, todėl naujindami galime nesunkiai susukti šiuos papildomus įrankius.
Tačiau dažnai nutinka taip, kad normaliai eksploatuojant nė viena mašina neturi šių 25% nepanaudotų resursų. Taip, mes net nesiekiame: CPU ir atmintis visada bus naudingi kitiems procesams. Norėdami išspręsti šią problemą, nusprendėme naudoti . Idėja yra suteikti Ingesters didesnį prioritetą nei kitoms (be pilietybės) mikropaslaugoms. Kai reikia paleisti papildomą (N+1) Ingester, laikinai išstumiame kitas, mažesnes ankštis. Šios ankštys perkeliamos į laisvus išteklius kitose mašinose, paliekant pakankamai didelę „skylę“, kad būtų galima paleisti papildomą „Ingester“.
Ketvirtadienį, liepos 18 d., savo grupėms pristatėme keturis naujus prioritetų lygius: kritinis, aukštas, vidutinė и žemas. Jie buvo išbandyti vidiniame klasteryje, kuriame nebuvo klientų srauto maždaug vieną savaitę. Pagal numatytuosius nustatymus gaunami ankštys be nurodyto prioriteto vidutinė prioritetas, klasė buvo nustatyta Ingesters su aukštas prioritetas. Kritinis buvo rezervuotas stebėjimui (Prometheus, Alertmanager, mazgo eksportuotojas, kube-state-metrics ir kt.). Mūsų konfigūracija atidaryta ir galite peržiūrėti PR .
Nelaimingas atsitikimas
Penktadienį, liepos 19 d., vienas iš inžinierių pristatė naują specialų Cortex klasterį dideliam klientui. Šios grupės konfigūracija neapėmė naujų grupių prioritetų, todėl visoms naujoms grupėms buvo priskirtas numatytasis prioritetas - vidutinė.
Kubernetes klasteris neturėjo pakankamai išteklių naujam Cortex klasteriui, o esamas gamybos Cortex klasteris nebuvo atnaujintas (Ingesters liko be aukštas prioritetas). Kadangi naujojo klasterio Ingesteriai pagal nutylėjimą turėjo vidutinė prioritetą, o esami ankštys gamyboje veikė visiškai be prioriteto, naujojo klasterio ingesteriai pakeitė Ingesterius iš esamo Cortex gamybos klasterio.
„ReplicaSet“, skirta iškeldintai „Ingester“ gamybos klasteryje, aptiko iškeldintą grupę ir sukūrė naują, kad išlaikytų nurodytą kopijų skaičių. Naujas blokas buvo priskirtas pagal numatytuosius nustatymus vidutinė prioritetas, o kitas „senas“ gamyboje dirbantis Ingester prarado savo išteklius. Rezultatas buvo lavinos procesas, dėl kurio buvo išstumtos visos ankštys iš Ingester for Cortex gamybos klasterių.
Įvedėjai nurodo būseną ir saugo ankstesnių 12 valandų duomenis. Tai leidžia efektyviau juos suspausti prieš įrašant juos į ilgalaikį saugojimą. Kad tai pasiektų, „Cortex“ suskirsto duomenis iš serijų, naudodama paskirstytos maišos lentelę (DHT) ir pakartoja kiekvieną seriją trijuose „Ingester“, naudodama „Dinamo“ stiliaus kvorumo nuoseklumą. „Cortex“ nerašo duomenų į išjungtus „Ingester“ įrenginius. Taigi, kai daug ingesterių palieka DHT, „Cortex“ negali užtikrinti pakankamo įrašų atkartojimo ir jie sugenda.
Aptikimas ir ištaisymas
Nauji „Prometheus“ pranešimai, pagrįsti „klaidos biudžetu“ (klaidų biudžeto pagrindu — informacija bus pateikta būsimame straipsnyje) pradėjo skambėti žadintuvu praėjus 4 minutėms nuo išjungimo pradžios. Maždaug per kitas penkias minutes atlikome diagnostiką ir padidinome pagrindinį „Kubernetes“ klasterį, kad būtų galima priimti ir naujus, ir esamus gamybos grupes.
Dar po penkių minučių senieji ingesteriai sėkmingai užrašė savo duomenis, naujieji pradėjo veikti, o Cortex klasteriai vėl tapo prieinami.
Dar 10 minučių buvo praleista diagnozuojant ir taisant atminties (OOM) klaidas iš autentifikavimo atvirkštinių tarpinių serverių, esančių priešais „Cortex“. OOM klaidas sukėlė dešimt kartų padidėjęs QPS (manome, kad dėl pernelyg agresyvių kliento „Prometheus“ serverių užklausų).
daiktai
Iš viso prastovos truko 26 minutes. Jokie duomenys nebuvo prarasti. „Ingesters“ sėkmingai įkėlė visus atmintyje esančius duomenis į ilgalaikę saugyklą. Išjungimo metu kliento „Prometheus“ serveriai buvo ištrinti (Nuotolinis) naudojant įrašus remiantis WAL (autorius iš Grafana Labs) ir pakartojo nepavykusius rašinius po avarijos.
Gamybos klasterio rašymo operacijos
išvados
Svarbu pasimokyti iš šio incidento ir imtis būtinų veiksmų, kad jis nepasikartotų.
Žvelgiant atgal, mes neturėjome nustatyti numatytojo vidutinė pirmenybė, kol negaus visi gamyboje esantys Ingesteriai aukštas prioritetas. Be to, jais reikėjo pasirūpinti iš anksto aukštas prioritetas. Dabar viskas sutvarkyta. Tikimės, kad mūsų patirtis padės kitoms organizacijoms, svarstančioms naudoti „Kubernetes“ prioritetus.
Pridėsime papildomą valdymo lygį, skirtą bet kokių papildomų objektų, kurių konfigūracijos yra visuotinės, diegimo klasteryje. Nuo šiol tokie pokyčiai bus vertinami bоdaugiau žmonių. Be to, modifikacija, sukėlusi avariją, buvo laikoma per maža atskiram projekto dokumentui – ji buvo aptarta tik „GitHub“ numeryje. Nuo šiol visi tokie konfigūracijų pakeitimai bus pateikiami kartu su atitinkama projekto dokumentacija.
Galiausiai automatizuosime autentifikavimo atvirkštinio tarpinio serverio dydžio keitimą, kad išvengtume OOM perkrovos, kurią matėme, ir peržiūrėsime „Prometheus“ numatytuosius nustatymus, susijusius su atsarginiu ir mastelio keitimu, kad išvengtume panašių problemų ateityje.
Gedimas turėjo ir teigiamų pasekmių: gavęs reikiamus resursus, „Cortex“ automatiškai atsigavo be papildomo įsikišimo. Taip pat įgijome vertingos patirties dirbdami su - mūsų nauja rąstų sujungimo sistema, kuri padėjo užtikrinti, kad visi Ingesteriai tinkamai elgtųsi gedimo metu ir po jo.
PS iš vertėjo
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «»;
- «".
Šaltinis: www.habr.com