Catetan. narjamahkeun.: Urang nampilkeun ka perhatian Anjeun rinci teknis ngeunaan alesan pikeun downtime panganyarna dina layanan awan dijaga ku panyipta Grafana. Ieu mangrupikeun conto klasik ngeunaan kumaha fitur énggal sareng sigana pisan mangpaat anu dirancang pikeun ningkatkeun kualitas infrastruktur ... tiasa nyababkeun cilaka upami anjeun henteu nyayogikeun seueur nuansa aplikasina dina kanyataan produksi. Éta saé nalika bahan sapertos kieu muncul anu ngamungkinkeun anjeun diajar henteu ngan ukur tina kasalahan anjeun. Rincian aya dina tarjamahan téks ieu ti wakil presiden produk ti Grafana Labs.
Dinten Jumaah, 19 Juli, jasa Hosted Prometheus di Grafana Cloud lirén fungsina sakitar 30 menit. Hapunten ka sadaya palanggan anu kapangaruhan ku pareum. Tugas kami nyaéta nyayogikeun alat ngawaskeun anu anjeun peryogikeun, sareng kami ngartos yén henteu gaduh aranjeunna tiasa ngajantenkeun hirup anjeun langkung susah. Kami nganggap kajadian ieu sacara serius. Catetan ieu ngajelaskeun naon anu kajantenan, kumaha urang ngaréspon, sareng naon anu urang laksanakeun pikeun mastikeun éta henteu kajantenan deui.
prasajarah
Jasa Grafana Cloud Hosted Prometheus dumasar kana - Proyék CNCF pikeun nyieun hiji horisontal scalable, kacida sadia, multi tenant jasa Prometheus. Arsitéktur Cortex diwangun ku sakumpulan microservices individu, nu masing-masing ngalaksanakeun fungsi sorangan: réplikasi, neundeun, queries, jsb. Cortex aya dina pamekaran aktip sareng terus-terusan nambihan fitur anyar sareng ningkatkeun kinerja. Kami rutin nyebarkeun sékrési Cortex énggal ka klaster supados para palanggan tiasa ngamangpaatkeun fitur-fitur ieu - untungna, Cortex tiasa diropéa tanpa downtime.
Pikeun apdet mulus, jasa Ingester Cortex merlukeun replika Ingester tambahan salila prosés update. (Catetan. narjamahkeun.: - komponén dasar tina Cortex. Tugasna nyaéta ngumpulkeun aliran sampel anu konstan, ngagolongkeun kana sakumpulan Prometheus sareng nyimpenna dina pangkalan data sapertos DynamoDB, BigTable atanapi Cassandra.) Hal ieu ngamungkinkeun Ingesters heubeul neruskeun data ayeuna ka Ingesters anyar. Eta sia noting yén Ingesters téh sumberdaya-nuntut. Pikeun aranjeunna dianggo, anjeun kudu boga 4 cores na 15 GB memori per pod, i.e. 25% tina kakuatan ngolah sareng mémori tina mesin dasar dina kasus klaster Kubernetes kami. Sacara umum, urang biasana boga leuwih pisan sumberdaya henteu kapake dina klaster ti 4 cores na 15 memori GB, sangkan bisa kalayan gampang spin up ieu ingesters tambahan salila upgrades.
Sanajan kitu, eta mindeng kajadian yén salila operasi normal, mesin teu boga ieu 25% sumberdaya henteu kapake. Leres, kami henteu narékahan: CPU sareng mémori bakal salawasna mangpaat pikeun prosés anu sanés. Pikeun ngajawab masalah ieu, urang mutuskeun pikeun ngagunakeun . Ide nyaéta pikeun masihan Ingesters prioritas anu langkung luhur tibatan jasa mikro (stateless). Nalika urang kedah ngajalankeun hiji tambahan (N + 1) Ingester, urang samentara mindahkeun sejen, pods leutik. pods ieu ditransferkeun ka bebas sumberdaya on mesin séjén, ninggalkeun cukup badag "liang" pikeun ngajalankeun hiji Ingester tambahan.
Dina Kemis, 18 Juli, kami ngagulung opat tingkat prioritas anyar pikeun klaster kami: kritis, luhur, rata-rata и handap. Éta diuji dina klaster internal anu henteu aya lalu lintas klien salami saminggu. Sacara standar, pods tanpa prioritas husus narima rata-rata prioritas, kelas ieu diatur pikeun Ingesters kalawan luhur prioritas. Kritis ieu ditangtayungan pikeun monitoring (Prometheus, Alertmanager, node-éksportir, kube-state-metrics, jsb). Konfigurasi kami dibuka, sareng anjeun tiasa ningali PR .
Kacilakaan
Dinten Jumaah, 19 Juli, salah sahiji insinyur ngaluncurkeun klaster Cortex khusus anyar pikeun klien ageung. Konfigurasi pikeun klaster ieu henteu kalebet prioritas pod énggal, janten sadaya pod énggal ditugaskeun prioritas standar - rata-rata.
Kluster Kubernetes teu gaduh sumber daya anu cukup pikeun kluster Cortex énggal, sareng kluster Cortex produksi anu tos aya teu diropéa (Ingesters ditinggalkeun tanpa luhur prioritas). Kusabab Ingesters tina klaster anyar sacara standar kagungan rata-rata prioritas, sarta pods aya dina produksi digawé tanpa prioritas pisan, Ingesters tina klaster anyar diganti Ingesters ti kluster produksi Cortex aya.
ReplicaSet pikeun Ingester anu digusur dina kluster produksi ngadeteksi pod anu digusur sareng nyiptakeun anu énggal pikeun ngajaga jumlah salinan anu ditangtukeun. Pod anyar ditugaskeun sacara standar rata-rata prioritas, sarta séjén "heubeul" Ingester dina produksi leungit sumberdaya na. hasilna éta prosés longsoran, nu ngarah ka kapindahan sadaya pods ti Ingester pikeun klaster produksi Cortex.
Ingesters anu stateful tur nyimpen data pikeun 12 jam saméméhna. Hal ieu ngamungkinkeun urang pikeun niiskeun aranjeunna langkung éfisién sateuacan nyerat kana panyimpenan jangka panjang. Pikeun ngahontal ieu, Cortex shards data sakuliah séri ngagunakeun Distributed Hash Table (DHT) jeung ulangan unggal runtuyan sakuliah tilu Ingesters ngagunakeun Dynamo-gaya quorum konsistensi. Cortex henteu nyerat data ka Ingesters anu ditumpurkeun. Ku kituna, nalika angka nu gede ngarupakeun Ingesters ninggalkeun DHT, Cortex teu bisa nyadiakeun réplikasi cukup tina éntri, sarta aranjeunna ngadat.
Deteksi jeung Remediation
Bewara Prometheus anyar dumasar kana "anggaran kasalahan" (kasalahan-anggaran basis - rinci bakal muncul dina artikel nu bakal datang) mimiti disada alarem 4 menit sanggeus mimiti shutdown. Salila lima menit ka hareup, urang ngajalankeun sababaraha diagnostik sareng ngagedekeun klaster Kubernetes anu aya dina dasar pikeun janten host kluster produksi énggal sareng anu tos aya.
Sanggeus lima menit deui, Ingesters heubeul hasil nulis data maranéhanana, nu anyar dimimitian up, sarta klaster Cortex sadia deui.
Séjén 10 menit dihabiskeun pikeun ngadiagnosa sareng ngabenerkeun kasalahan kaluar-memori (OOM) tina proksi sabalikna auténtikasi anu aya di payuneun Cortex. Kasalahan OOM disababkeun ku paningkatan QPS sapuluh kali lipat (kami yakin kusabab paménta anu agrésif ti server Prometheus klien).
épék
Total downtime éta 26 menit. Taya data anu leungit. Ingesters parantos suksés ngamuat sadaya data dina mémori kana panyimpenan jangka panjang. Salila shutdown, klien Prometheus server buffered dihapus (jauh) rekaman ngagunakeun dumasar kana WAL (dikarang ku ti Grafana Labs) sareng ngulang tulisan anu gagal saatos kacilakaan.
Operasi nulis klaster produksi
papanggihan
Penting pikeun diajar tina kajadian ieu sareng nyandak léngkah-léngkah anu dipikabutuh pikeun nyegah kambuh deui.
Dina hindsight, urang teu kudu nyetel standar rata-rata prioritas dugi sadayana Ingesters dina produksi geus narima luhur hiji prioritas. Sajaba ti éta, éta diperlukeun pikeun ngurus aranjeunna sateuacanna luhur prioritas. Sagalana geus dibereskeun ayeuna. Kami ngarepkeun pangalaman urang bakal ngabantosan organisasi anu sanés mertimbangkeun ngagunakeun prioritas pod di Kubernetes.
Urang bakal nambahan hiji tingkat tambahan kontrol ngaliwatan deployment tina sagala objék tambahan anu konfigurasi global kana klaster. Ti ayeuna, parobahan sapertos bakal ditaksir bоleuwih jalma. Salaku tambahan, modifikasi anu nyababkeun kacilakaan dianggap sakedik teuing pikeun dokumén proyék anu misah - éta ngan dibahas dina masalah GitHub. Ti ayeuna, sagala parobahan misalna mun configs bakal dibarengan ku dokuméntasi proyék luyu.
Tungtungna, urang bakal ngajadikeun otomatis pangaturan ukuran jadi proxy sabalikna auténtikasi pikeun nyegah overload OOM kami saksi, sarta bakal marios setélan standar Prometheus patali fallback jeung skala pikeun nyegah masalah sarupa di mangsa nu bakal datang.
Gagalna ogé ngagaduhan sababaraha akibat anu positif: nampi sumber daya anu diperyogikeun, Cortex otomatis pulih tanpa campur tangan tambahan. Urang ogé meunang pangalaman berharga gawé bareng - sistem aggregation log anyar kami - nu mantuan mastikeun yén sakabéh Ingesters behaved leres nalika jeung sanggeus gagalna.
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «";
- «".
sumber: www.habr.com