Notu. transl.: Ni prezentas al via atento teknikajn detalojn pri la kialoj de la lastatempa malfunkcio en la nuba servo konservita de la kreintoj de Grafana. Ĉi tio estas klasika ekzemplo de kiel nova kaj ŝajne ekstreme utila trajto desegnita por plibonigi la kvaliton de infrastrukturo... povas kaŭzi damaĝon se vi ne zorgas pri la multaj nuancoj de ĝia apliko en la realaĵoj de produktado. Estas bonege, kiam aperas tiaj materialoj, kiuj permesas vin lerni ne nur de viaj eraroj. Detaloj estas en la traduko de ĉi tiu teksto de la vicprezidanto de produkto de Grafana Labs.
Vendrede, la 19-an de julio, la Hosted Prometheus-servo en Grafana Cloud ĉesis funkcii dum proksimume 30 minutoj. Mi pardonpetas al ĉiuj klientoj trafitaj de la malfunkcio. Nia tasko estas provizi la monitorajn ilojn, kiujn vi bezonas, kaj ni komprenas, ke ne havi ilin disponeblaj povas malfaciligi vian vivon. Ni prenas ĉi tiun okazaĵon ege serioze. Ĉi tiu noto klarigas kio okazis, kiel ni respondis kaj kion ni faras por certigi, ke ĝi ne okazos denove.
antaŭhistorio
Grafana Cloud Hosted Prometheus-servo baziĝas sur — CNCF-projekto por krei horizontale skaleblan, tre disponeblan, plur-luancan Prometheus-servon. La Cortex-arkitekturo konsistas el aro de individuaj mikroservoj, ĉiu el kiuj plenumas sian propran funkcion: reproduktado, stokado, demandoj, ktp. Cortex estas aktiva disvolviĝo kaj konstante aldonas novajn funkciojn kaj plibonigas rendimenton. Ni regule deplojas novajn eldonojn de Cortex al aretoj por ke klientoj povu utiligi ĉi tiujn funkciojn - feliĉe, Cortex povas esti ĝisdatigita sen malfunkcio.
Por senjuntaj ĝisdatigoj, la servo Ingester Cortex postulas plian kopion de Ingester dum la ĝisdatiga procezo. (Notu. transl.: - la baza komponanto de la Kortekso. Ĝia tasko estas kolekti konstantan fluon de specimenoj, grupigi ilin en Prometheus-pecojn kaj konservi ilin en datumbazo kiel DynamoDB, BigTable aŭ Cassandra.) Ĉi tio permesas al malnovaj Ingesters plusendi aktualajn datumojn al novaj Ingesters. Indas noti, ke Ingesters postulas rimedojn. Por ke ili funkciu, vi devas havi 4 kernojn kaj 15 GB da memoro po pod, t.e. 25% de la pretiga potenco kaj memoro de la baza maŝino en la kazo de niaj Kubernetes-grupoj. Ĝenerale, ni kutime havas multe pli da neuzataj rimedoj en la areto ol 4 kernoj kaj 15 GB da memoro, do ni povas facile ŝprucigi ĉi tiujn kromajn konsumantojn dum ĝisdatigoj.
Tamen, ofte okazas, ke dum normala funkciado neniu el la maŝinoj havas ĉi tiun 25% de neuzataj rimedoj. Jes, ni eĉ ne strebas: CPU kaj memoro ĉiam estos utilaj por aliaj procezoj. Por solvi ĉi tiun problemon, ni decidis uzi . La ideo estas doni al Ingesters pli altan prioritaton ol aliaj (senŝtataj) mikroservoj. Kiam ni bezonas ruli plian (N+1) Ingester, ni provizore delokigas aliajn, pli malgrandajn podojn. Ĉi tiuj balgoj estas translokigitaj al senpagaj rimedoj sur aliaj maŝinoj, lasante sufiĉe grandan "truon" por funkcii plian Ingester.
Ĵaŭdon, la 18-an de julio, ni lanĉis kvar novajn prioritatnivelojn al niaj aretoj: kritika, alta, mezumo и malalta. Ili estis provitaj sur interna areto sen klienta trafiko dum ĉirkaŭ unu semajno. Defaŭlte, balgoj sen difinita prioritato ricevis mezumo prioritato, klaso estis fiksita por Ingesters kun alta prioritato. Kritikaj estis rezervita por monitorado (Prometheus, Alertmanager, nodo-eksportisto, kube-state-metrics, ktp.). Nia agordo estas malfermita, kaj vi povas vidi la PR .
Akcidento
Vendredon, la 19-an de julio, unu el la inĝenieroj lanĉis novan dediĉitan Cortex-grupon por granda kliento. La agordo por ĉi tiu aro ne inkludis novajn podprioritatojn, do ĉiuj novaj podoj ricevis defaŭltan prioritaton - mezumo.
La Kubernetes-areto ne havis sufiĉe da resursoj por la nova Cortex-areto, kaj la ekzistanta produktada Cortex-areto ne estis ĝisdatigita (konsumantoj estis lasitaj sen alta prioritato). Ekde la Ingesters de la nova cluster defaŭlte havis mezumo prioritato, kaj la ekzistantaj balgoj en produktado funkciis sen prioritato entute, la Ingesters de la nova areto anstataŭigis la Ingesters de la ekzistanta Cortex-produktadgrupo.
ReplicaSet por la elmetita Ingester en la produktadgrupo detektis la forpelitan pod kaj kreis novan por konservi la specifitan nombron da kopioj. La nova pod estis asignita defaŭlte mezumo prioritato, kaj alia "malnova" Ingester en produktado perdis siajn rimedojn. La rezulto estis lavango procezo, kiu kaŭzis la delokiĝon de ĉiuj balgoj de Ingester por Cortex-produktadgrupoj.
Ingesters estas ŝtataj kaj konservas datumojn por la antaŭaj 12 horoj. Ĉi tio permesas al ni kunpremi ilin pli efike antaŭ ol skribi ilin al longdaŭra stokado. Por atingi tion, Cortex dividas datumojn tra serioj uzante Distributed Hash Table (DHT) kaj reproduktas ĉiun serion tra tri Ingesters uzante Dynamo-stilan kvoruman konsistencon. Cortex ne skribas datumojn al Ingesters kiuj estas malfunkciigitaj. Tiel, kiam granda nombro da Ingesters forlasas la DHT, Cortex ne povas disponigi sufiĉan reproduktadon de la enskriboj, kaj ili kraŝas.
Detekto kaj Solvado
Novaj sciigoj de Prometheus bazitaj sur "erara buĝeto" (erar-buĝet-bazita — detaloj aperos en estonta artikolo) komencis sonigi la alarmon 4 minutojn post la komenco de la haltigo. Dum la sekvaj kvin minutoj aŭ pli, ni prizorgis iujn diagnozojn kaj pligrandigis la suban Kubernetes-areton por gastigi kaj la novajn kaj ekzistantajn produktadgrupojn.
Post aliaj kvin minutoj, la malnovaj Ingesters sukcese skribis siajn datumojn, la novaj ekfunkciis, kaj la Cortex-aretoj denove haveblas.
Pliaj 10 minutoj estis pasigitaj por diagnozi kaj korekti ekstermemorajn (OOM) erarojn de aŭtentigaj inversaj prokuriloj situantaj antaŭ Cortex. OOM-eraroj estis kaŭzitaj de dekobla pliiĝo en QPS (ni kredas pro tro agresemaj petoj de la Prometheus-serviloj de la kliento).
Konsekvencoj
La totala malfunkcio estis 26 minutoj. Neniuj datumoj estis perditaj. Ingesters sukcese ŝargis ĉiujn en-memorajn datumojn en longdaŭran stokadon. Dum la haltigo, kliento Prometheus serviloj buffer forigita (fora) registradoj uzante surbaze de WAL (verkita de de Grafana Labs) kaj ripetis la malsukcesajn skribojn post la kraŝo.
Produktadgrupo skriba operacioj
trovoj
Gravas lerni de ĉi tiu okazaĵo kaj preni la necesajn paŝojn por eviti ĝian ripetiĝon.
Postvide, ni ne devus esti agordi la defaŭltan mezumo prioritato ĝis ĉiuj Ingesters en produktado ricevis alta prioritato. Krome, estis necese prizorgi ilin anticipe alta prioritato. Ĉio estas fiksita nun. Ni esperas, ke nia sperto helpos aliajn organizojn konsiderante uzi podprioritatojn en Kubernetes.
Ni aldonos plian nivelon de kontrolo super la deplojo de iuj aldonaj objektoj, kies agordoj estas tutmondaj al la areto. Ekde nun tiaj ŝanĝoj estos taksataj bоpli da homoj. Aldone, la modifo, kiu kaŭzis la kraŝon, estis konsiderata tro negrava por aparta projektdokumento - ĝi estis nur diskutita en GitHub-problemo. Ekde nun, ĉiuj tiaj ŝanĝoj al agordoj estos akompanitaj de taŭga projektdokumentado.
Fine, ni aŭtomatigos regrandigon de la aŭtentikiga inversa prokurilo por malhelpi la troŝarĝon de OOM, kiun ni atestis, kaj revizios Prometheus-defaŭltajn agordojn ligitajn al falo kaj skalo por malhelpi similajn problemojn en la estonteco.
La fiasko ankaŭ havis kelkajn pozitivajn sekvojn: ricevinte la necesajn rimedojn, Cortex aŭtomate resaniĝis sen plia interveno. Ni ankaŭ akiris valoran sperton laborante kun - nia nova log-agrega sistemo - kiu helpis certigi, ke ĉiuj Ingesters kondutis ĝuste dum kaj post la fiasko.
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com