Athugið. þýð.: Við kynnum þér tæknilegar upplýsingar um ástæður nýlegrar niður í miðbæ í skýjaþjónustunni sem höfundar Grafana hafa viðhaldið. Þetta er klassískt dæmi um hvernig nýr og að því er virðist afar gagnlegur eiginleiki hannaður til að bæta gæði innviða... getur valdið skaða ef þú gerir ekki ráð fyrir hinum fjölmörgu blæbrigðum beitingar hans í raunveruleika framleiðslunnar. Það er frábært þegar efni eins og þetta birtast sem gerir þér kleift að læra ekki aðeins af mistökum þínum. Upplýsingar eru í þýðingu þessa texta frá varaforseta vöru frá Grafana Labs.
Föstudaginn 19. júlí hætti Hosted Prometheus þjónustan í Grafana Cloud að virka í um það bil 30 mínútur. Ég bið alla viðskiptavini sem verða fyrir áhrifum af biluninni afsökunar. Okkar starf er að útvega eftirlitstækin sem þú þarft og við skiljum að það getur gert líf þitt erfiðara að hafa þau ekki tiltæk. Við tökum þetta atvik afar alvarlega. Þessi athugasemd útskýrir hvað gerðist, hvernig við brugðumst við og hvað við erum að gera til að tryggja að það gerist ekki aftur.
Forsaga
Grafana Cloud Hosted Prometheus þjónusta er byggð á — CNCF verkefni til að búa til lárétt stigstærða, mjög fáanlega Prometheus þjónustu fyrir marga leigjendur. Cortex arkitektúrinn samanstendur af safni einstakra örþjónustu, sem hver um sig sinnir sínu hlutverki: afritun, geymsla, fyrirspurnir osfrv. Cortex er í virkri þróun og bætir stöðugt við nýjum eiginleikum og bætir afköst. Við sendum reglulega nýjar Cortex útgáfur í klasa svo að viðskiptavinir geti nýtt sér þessa eiginleika - sem betur fer er hægt að uppfæra Cortex án niður í miðbæ.
Fyrir óaðfinnanlegar uppfærslur þarf Ingester Cortex þjónustan viðbótarafrit af Ingester meðan á uppfærsluferlinu stendur. (Athugið. þýð.: - grunnþáttur heilaberkisins. Hlutverk þess er að safna stöðugum straumi af sýnum, flokka þau í Prometheus bita og geyma þau í gagnagrunni eins og DynamoDB, BigTable eða Cassandra.) Þetta gerir gömlum Ingesters kleift að framsenda núverandi gögn til nýrra Ingesters. Vert er að taka fram að Ingesters eru auðlindakröfur. Til að þeir virki þarftu að hafa 4 kjarna og 15 GB af minni á pod, þ.e. 25% af vinnsluafli og minni grunnvélarinnar ef um er að ræða Kubernetes klasana okkar. Almennt séð erum við venjulega með miklu fleiri ónotaðar auðlindir í þyrpingunni en 4 kjarna og 15 GB af minni, svo við getum auðveldlega snúið upp þessum viðbótarinntökutækjum við uppfærslu.
Hins vegar gerist það oft að við venjulega notkun hefur engin vélanna þessi 25% af ónotuðum auðlindum. Já, við kappkostum ekki einu sinni: CPU og minni munu alltaf nýtast öðrum ferlum. Til að leysa þetta vandamál ákváðum við að nota . Hugmyndin er að gefa Ingesters meiri forgang en aðrar (statelausar) örþjónustur. Þegar við þurfum að keyra viðbótar (N+1) inntökutæki, tökum við tímabundið frá öðrum, smærri belgjum. Þessir fræbelgir eru fluttir í ókeypis auðlindir á öðrum vélum og skilja eftir nógu stórt „gat“ til að keyra viðbótar Ingester.
Fimmtudaginn 18. júlí settum við út fjögur ný forgangsstig fyrir klasana okkar: gagnrýninn, Высокий, miðlungs и Low. Þau voru prófuð á innri klasa án viðskiptavinaumferðar í um eina viku. Sjálfgefið, belg án tiltekins forgangs móttekið miðlungs forgang var settur bekkur fyrir Ingesters með hár forgang. Gagnrýnið var frátekið fyrir eftirlit (Prometheus, Alertmanager, hnút-útflytjandi, kube-state-mælingar osfrv.). Stillingin okkar er opin og þú getur skoðað PR .
Slys
Föstudaginn 19. júlí setti einn verkfræðinganna á markað nýjan sérstakan Cortex þyrping fyrir stóran viðskiptavin. Stillingin fyrir þennan klasa innihélt ekki nýjar hólfsforgangsröðun, þannig að öllum nýjum belgjum var úthlutað sjálfgefnum forgangi - miðlungs.
Kubernetes þyrpingin hafði ekki nægt fjármagn fyrir nýja Cortex þyrpinguna og núverandi framleiðslu Cortex þyrpingin var ekki uppfærð (Inntakar voru eftir án hár forgang). Þar sem Ingesters nýja klasans sjálfgefið hafði miðlungs forgangsröðun, og fyrirliggjandi belg í framleiðslu virkuðu án forgangs, komu inntökutæki nýja klasans í stað Ingesters úr núverandi Cortex framleiðsluklasa.
ReplicaSet fyrir evicted Ingester í framleiðsluklasanum fann evicted belg og bjó til nýjan til að viðhalda tilgreindum fjölda eintaka. Nýja hólfinu var sjálfgefið úthlutað miðlungs forgang, og annar „gamall“ Ingester í framleiðslu missti auðlindir sínar. Niðurstaðan var snjóflóðaferli, sem leiddi til tilfærslu allra fræbelgja frá Ingester fyrir Cortex framleiðsluklasa.
Þeir sem taka inn eru staðbundnir og geyma gögn fyrir síðustu 12 klukkustundirnar. Þetta gerir okkur kleift að þjappa þeim á skilvirkari hátt áður en þú skrifar þau í langtímageymslu. Til að ná þessu, sundrar Cortex gögnum yfir seríur með því að nota dreifða kjötkássatöflu (DHT) og endurtekur hverja röð yfir þrjá inntaka með Dynamo-stíl sveitarsamkvæmni. Cortex skrifar ekki gögn til inntaka sem eru óvirk. Svona, þegar mikill fjöldi inntaka yfirgefur DHT, getur heilaberki ekki veitt nægjanlega endurtekningu á færslunum og þær hrynja.
Uppgötvun og úrbætur
Nýjar Prometheus tilkynningar byggðar á "villufjárhagsáætlun" (byggt á villum í fjárhagsáætlun — upplýsingar munu birtast í síðari grein) byrjaði að hringja 4 mínútum eftir að lokunin hófst. Á næstu fimm mínútum eða svo, keyrðum við nokkrar greiningar og stækkuðum undirliggjandi Kubernetes klasa til að hýsa bæði nýja og núverandi framleiðsluklasa.
Eftir fimm mínútur í viðbót, skrifuðu gömlu Ingesters gögnin sín með góðum árangri, þau nýju fóru í gang og heilaberkisþyrpingarnar urðu aftur tiltækar.
Aðrar 10 mínútur fóru í að greina og leiðrétta út-af-minni (OOM) villur frá öfugum auðkenningarumboðum sem staðsettir voru fyrir framan heilaberki. OOM villur voru af völdum tífaldrar aukningar á QPS (við teljum vegna of árásargjarnra beiðna frá Prometheus netþjónum viðskiptavinarins).
Eftirmála
Heildarbilunin var 26 mínútur. Engin gögn týndust. Gestir hafa hlaðið öllum gögnum í minni inn í langtímageymslu. Meðan á lokuninni stóð var biðminni Prometheus þjónum biðminni eytt (fjarlægur) upptökur með því að nota byggt á WAL (höfundur af frá Grafana Labs) og endurtók misheppnuð skrif eftir hrun.
Skrifunaraðgerðir framleiðsluklasa
Niðurstöður
Mikilvægt er að læra af þessu atviki og gera nauðsynlegar ráðstafanir til að forðast að það endurtaki sig.
Eftir á að hyggja hefðum við ekki átt að setja sjálfgefið miðlungs forgang þar til allir Ingesters í framleiðslu hafa fengið Высокий forgangsverkefni. Auk þess var nauðsynlegt að sinna þeim fyrirfram hár forgang. Allt er lagað núna. Við vonum að reynsla okkar muni hjálpa öðrum stofnunum að íhuga að nota forgangsröðun í Kubernetes.
Við munum bæta við auknu eftirlitsstigi yfir dreifingu allra viðbótarhluta sem eru alþjóðlegar fyrir þyrpinguna. Framvegis verða slíkar breytingar metnar bоMeira fólk. Að auki var breytingin sem olli hruninu talin of lítil fyrir sérstakt verkefnisskjal - það var aðeins rætt í GitHub útgáfu. Héðan í frá munu allar slíkar breytingar á stillingum fylgja viðeigandi verkefnisskjöl.
Að lokum munum við gera sjálfvirkan stærðarbreytingu á öfugum umboði auðkenningar til að koma í veg fyrir ofhleðslu OOM sem við urðum vitni að og munum endurskoða Prometheus sjálfgefnar stillingar sem tengjast fallback og skala til að koma í veg fyrir svipuð vandamál í framtíðinni.
Bilunin hafði einnig nokkrar jákvæðar afleiðingar: Eftir að hafa fengið nauðsynleg úrræði batnaði Cortex sjálfkrafa án frekari íhlutunar. Við fengum líka dýrmæta reynslu af því að vinna með - nýja annálakerfið okkar - sem hjálpaði til við að tryggja að allir inntakar hegðuðu sér rétt á meðan og eftir bilunina.
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com