Dadi sampeyan ngumpulake metrik. Minangka kita. Kita uga ngumpulake metrik. Mesthi, perlu kanggo bisnis. Dina iki kita bakal ngomong babagan link pisanan saka sistem pemantauan kita - server agregasi sing kompatibel karo statsd , kok kita nulis lan ngapa kita nilar brubeck.
Saka artikel sadurunge (, ) sampeyan bisa mangerteni sing nganti sawetara wektu kita diklumpukake tandha nggunakake . Iki ditulis ing C. Saka sudut pandang kode, iku gampang kaya plug (iki penting yen sampeyan pengin nyumbang) lan, sing paling penting, bisa ngatasi volume 2 yuta metrik per detik (MPS) ing puncak. tanpa masalah. Dokumentasi kasebut nyatakake dhukungan kanggo 4 yuta MPS kanthi tanda bintang. Iki tegese sampeyan bakal entuk angka kasebut yen sampeyan ngatur jaringan kanthi bener ing Linux. (Kita ora ngerti carane akeh MPS sampeyan bisa entuk yen sampeyan ninggalake jaringan minangka). Senadyan kaluwihan kasebut, kita duwe sawetara keluhan serius babagan brubeck.
Pratelan 1. Github, pangembang proyek kasebut, mandheg ndhukung: nerbitake patch lan ndandani, nampa PR kita lan (ora mung kita). Ing sawetara sasi pungkasan (ing endi wae saka Februari-Maret 2018), aktivitas wis diterusake, nanging sadurunge ana meh 2 taun kalem lengkap. Kajaba iku, proyek kasebut lagi dikembangake , sing bisa dadi alangan serius kanggo introduksi fitur-fitur anyar.
Pratelan 2. Akurasi petungan. Brubeck nglumpukake total 65536 nilai kanggo agregasi. Ing kasus kita, kanggo sawetara metrik, sajrone periode agregasi (30 detik), luwih akeh nilai bisa teka (1 ing puncak). Minangka asil sampling iki, nilai maksimum lan minimal katon ora ana gunane. Contone, kaya iki:
Kaya sing ana
Carane kudu wis
Kanggo alasan sing padha, jumlah umume ora diwilang kanthi bener. Tambah kene bug karo 32-dicokot float overflow, kang umume ngirim server kanggo segfault nalika nampa metrik ketoke resik, lan kabeh dadi gedhe. Bug, kanthi cara, durung didandani.
Lan, pungkasanipun, Pratelan X. Ing wektu nulis, kita siyap kanggo saiki kabeh 14 liyane utawa kurang digunakake statsd implementasine sing kita bisa nemokake. Coba bayangake yen sawetara prasarana tunggal wis berkembang banget nganti nampa 4 yuta MPS ora cukup maneh. Utawa sanajan durung tuwuh, nanging metrik kasebut wis penting banget kanggo sampeyan, sanajan sithik, 2-3 menit ing grafik bisa dadi kritis lan nyebabake depresi sing ora bisa diatasi ing antarane manajer. Amarga ngobati depresi minangka tugas tanpa pamrih, solusi teknis dibutuhake.
Kaping pisanan, toleransi fault, supaya masalah dadakan ing server ora nimbulaké apocalypse Zombi kejiwaan ing kantor. Kapindho, skala supaya bisa nampa luwih saka 4 yuta MPS, tanpa ngeduk jero tumpukan jaringan Linux lan kanthi tenang tuwuh "ing jembar" nganti ukuran sing dibutuhake.
Amarga kita duwe ruang kanggo skala, kita mutusake kanggo miwiti kanthi toleransi kesalahan. "BABUR! Toleransi kesalahan! Iku prasaja, kita bisa nindakake iku," kita mikir lan dibukak 2 server, mundhakaken salinan brubeck ing saben. Kanggo nindakake iki, kita kudu nyalin lalu lintas kanthi metrik menyang server loro lan malah nulis kanggo iki . We ditanggulangi masalah toleransi fault karo iki, nanging ... ora banget uga. Ing wiwitan, kabeh katon apik: saben brubeck nglumpukake versi agregasi dhewe, nulis data menyang Graphite saben 30 detik, nimpa interval lawas (iki wis rampung ing sisih Graphite). Yen salah siji server tiba-tiba gagal, kita mesthi duwe server liyane kanthi salinan data sing dikumpulake. Nanging iki masalah: yen server gagal, "saw" katon ing grafik. Iki amarga kasunyatan manawa interval 30 detik brubeck ora disinkronake, lan nalika kacilakan salah sijine ora ditimpa. Nalika server kapindho diwiwiti, kedadeyan sing padha. Cukup lumayan, nanging aku pengin luwih apik! Masalah skalabilitas uga durung ilang. Kabeh metrik isih "mabur" menyang server siji, lan mulane kita diwatesi 2-4 yuta MPS sing padha, gumantung saka tingkat jaringan.
Yen sampeyan mikir sethithik babagan masalah kasebut lan ing wektu sing padha dig munggah salju karo shovel, banjur idea ketok ing ngisor iki bisa teka ing atine: sampeyan kudu statsd sing bisa digunakake ing mode mbagekke. Yaiku, sing ngetrapake sinkronisasi antarane simpul ing wektu lan metrik. "Mesthi, solusi kasebut mbokmenawa wis ana," ujare lan menyang Google…. Lan ora nemu apa-apa. Sawise ngliwati dokumentasi kanggo macem-macem statsd ( wiwit 11.12.2017 Desember XNUMX), kita ora nemokake apa-apa. Ketoke, para pangembang utawa pangguna solusi kasebut durung nemoni akeh metrik, yen ora, mesthine bakal nemokake apa-apa.
Banjur kita eling babagan statsd "dolanan" - bioyino, sing ditulis ing hackathon Just for Fun (jeneng proyek kasebut digawe dening skrip sadurunge wiwitan hackathon) lan nyadari yen kita mbutuhake statsd dhewe. Kanggo apa?
- amarga ana sawetara banget klon statistik ing donya,
- amarga bisa nyedhiyakake sing dikarepake utawa cedhak karo toleransi lan skalabilitas kesalahan sing dikarepake (kalebu nyinkronake metrik gabungan antarane server lan ngrampungake masalah ngirim konflik),
- amarga bisa ngetung metrik kanthi luwih akurat tinimbang brubeck,
- amarga sampeyan bisa ngumpulake statistik sing luwih rinci dhewe, sing praktis ora diwenehake dening brubeck,
- amarga aku duwe kesempatan kanggo program hyperperformance aplikasi lab skala mbagekke dhewe, kang ora bakal rampung mbaleni arsitektur hyperfor liyane padha ... uga, iku.
Apa kanggo nulis? Mesthi, ing Rust. Kenging punapa?
- amarga wis ana solusi prototipe,
- amarga penulis artikel kasebut wis ngerti Rust ing wektu kasebut lan kepengin nulis apa wae kanggo produksi kanthi kesempatan kanggo nyelehake ing open-source,
- amarga basa nganggo GC ora cocok kanggo kita amarga sifat lalu lintas sing ditampa (meh wektu nyata) lan jeda GC meh ora bisa ditampa,
- amarga sampeyan butuh kinerja maksimal sing bisa dibandhingake karo C
- amarga Rust nyedhiyani kita karo concurrency wedi, lan yen kita miwiti nulis ing C / C ++, kita bakal raked malah liyane vulnerabilities, buffer overflows, kahanan lomba lan tembung medeni liyane saka brubeck.
Ana uga bantahan marang Rust. Perusahaan ora duwe pengalaman nggawe proyek ing Rust, lan saiki kita uga ora ngrancang nggunakake ing proyek utama. Mulane, ana wedi serius sing ora bakal bisa, nanging kita mutusaké kanggo njupuk kasempatan lan nyoba.
Wektu liwati...
Pungkasan, sawise sawetara upaya gagal, versi kerja pisanan wis siyap. Ana apa? Iki kedadeyan.
Saben simpul nampa set metrik dhewe lan nglumpukake, lan ora nglumpukake metrik kanggo jinis-jinis kasebut ing ngendi set lengkap dibutuhake kanggo panggabungan pungkasan. Kelenjar kasebut disambungake karo sawetara protokol kunci sing disebarake, sing ngidini sampeyan milih siji-sijine (ing kene kita nangis) sing pantes ngirim metrik menyang Sing Agung. Masalah iki saiki lagi ditanggulangi dening , nanging ing mangsa ambisi penulis ngluwihi kanggo Rakit, ing ngendi sing paling pantes, mesthi bakal dadi simpul pimpinan konsensus. Saliyane konsensus, simpul cukup asring (sapisan saben detik minangka standar) ngirim menyang tanggane bagean metrik sing wis dikumpulake sing bisa diklumpukake ing detik kasebut. Pranyata manawa skala lan toleransi fault dilestarekake - saben simpul isih duwe set lengkap metrik, nanging metrik dikirim wis dikumpulake, liwat TCP lan dienkode dadi protokol binar, mula biaya duplikasi dikurangi sacara signifikan dibandhingake karo UDP. Senadyan jumlah metrik mlebu sing cukup akeh, akumulasi mbutuhake memori sing sithik lan malah kurang CPU. Kanggo mertics sing bisa dikompres banget, iki mung sawetara puluhan megabyte data. Minangka bonus tambahan, ora ana data sing ora perlu ditulis ulang ing Graphite, kaya sing kedadeyan karo burbeck.
Paket UDP karo metrik ora imbang antarane simpul ing peralatan jaringan liwat Round Robin prasaja. Mesthi, hardware jaringan ora ngurai isi paket lan mulane bisa narik luwih saka 4M paket per detik, ora kanggo sebutno metrik sing ora ngerti apa-apa. Yen kita nganggep manawa metrik ora teka siji-sijine ing saben paket, mula kita ora bakal ngerteni masalah kinerja ing papan iki. Yen server crash, piranti jaringan kanthi cepet (ing 1-2 detik) ndeteksi kasunyatan iki lan mbusak server tabrakan saka rotasi. Akibaté, simpul pasif (yaiku, non-pemimpin) bisa diuripake lan dipateni kanthi praktis tanpa ngelingi drawdowns ing grafik. Maksimum sing ilang yaiku bagean saka metrik sing ana ing detik pungkasan. A mundhut dadakan / mati / ngalih saka pimpinan isih bakal nggawe anomali cilik (interval 30 detik isih ora sinkron), nanging yen ana komunikasi antarane simpul, masalah iki bisa nyilikake, contone, ngirim paket sinkronisasi. .
A sethitik babagan struktur internal. Aplikasi kasebut, mesthi, multithreaded, nanging arsitektur threading beda karo sing digunakake ing brubeck. Utas ing brubeck padha - saben wong tanggung jawab kanggo ngumpulake informasi lan agregasi. Ing bioyino, buruh dipérang dadi rong klompok: sing tanggung jawab kanggo jaringan lan sing tanggung jawab kanggo agregasi. Divisi iki ngidini sampeyan ngatur aplikasi kanthi luwih fleksibel gumantung saka jinis metrik: ing ngendi agregasi intensif dibutuhake, sampeyan bisa nambah agregator, ing ngendi ana akeh lalu lintas jaringan, sampeyan bisa nambah jumlah aliran jaringan. Saiki, ing server kita kerja ing 8 jaringan lan 4 aliran agregasi.
Bagian pancacahan (tanggung jawab kanggo agregasi) cukup mboseni. Buffer kapenuhan dening jaringan mili mbagekke antarane pancacahan mili, ngendi padha salajengipun parsed lan aggregated. Yen dijaluk, metrik diwenehake kanggo dikirim menyang simpul liyane. Kabeh iki, kalebu ngirim data ing antarane simpul lan nggarap Konsul, ditindakake kanthi ora sinkron, mlaku ing kerangka .
Luwih akeh masalah sajrone pangembangan disebabake dening bagean jaringan sing tanggung jawab kanggo nampa metrik. Tujuan utama misahake aliran jaringan menyang entitas sing kapisah yaiku kepinginan kanggo nyuda wektu aliran ora kanggo maca data saka soket. Pilihan nggunakake UDP bedo lan recvmsg biasa cepet ilang: pisanan nganggo kakehan CPU papan pangguna kanggo proses acara, kaloro mbutuhake akeh banget ngalih konteks. Mulane saiki digunakake karo buffer gedhe (lan buffer, perwira purun, apa-apa kanggo sampeyan!). Dhukungan kanggo UDP biasa dilindhungi undhang-undhang kanggo kasus cahya sing ora dibutuhake recvmmsg. Ing mode multipesen, iku bisa kanggo entuk bab utama: akèh-akèhé saka wektu, thread jaringan rakes antrian OS - maca data saka soket lan nransfer menyang buffer userspace, mung sok-sok ngoper kanggo menehi kapenuhan buffer kanggo aggregators. Antrian ing soket sacoro prakteke ora nglumpukake, jumlah paket dropped praktis ora tuwuh.
komentar
Ing setelan gawan, ukuran buffer disetel dadi cukup gedhe. Yen dumadakan arep nyoba server dhewe, sampeyan bisa nemoni kasunyatan sing sawise ngirim nomer cilik metrik, padha ora bakal teka ing Graphite, tetep ing buffer stream jaringan. Kanggo nggarap metrik sing sithik, sampeyan kudu nyetel ukuran bufsize lan ukuran antrian tugas menyang nilai sing luwih cilik ing konfigurasi.
Pungkasan, sawetara grafik kanggo para penyayang grafik.
Statistik babagan jumlah metrik sing mlebu kanggo saben server: luwih saka 2 yuta MPS.
Mateni salah sawijining simpul lan nyebarake maneh metrik sing mlebu.
Statistik babagan metrik sing metu: mung siji simpul sing tansah dikirim - bos raid.
Statistik operasi saben simpul, njupuk kesalahan akun ing macem-macem modul sistem.
Rincian metrik sing mlebu (jeneng metrik didhelikake).
Apa sing bakal kita lakoni karo kabeh iki sabanjure? Mesthi, nulis kode, sial ...! Proyek kasebut wiwitane direncanakake dadi sumber terbuka lan bakal tetep kaya ngono sajrone urip. Rencana langsung kita kalebu ngalih menyang versi Raft dhewe, ngganti protokol peer dadi luwih portabel, ngenalake statistik internal tambahan, jinis metrik anyar, koreksi bug lan dandan liyane.
Mesthi wae, kabeh wong seneng mbantu pangembangan proyek: nggawe PR, Masalah, yen bisa, kita bakal nanggapi, nambah, lsp.
Kanthi ngandika, iku kabeh wong, tuku gajah kita!
Source: www.habr.com