Janten anjeun ngumpulkeun métrik. Salaku urang. Urang ogé ngumpulkeun metrics. Tangtu, diperlukeun pikeun bisnis. Dinten ieu kami bakal ngobrol ngeunaan tumbu pangheulana sistem ngawaskeun kami - a statsd-compatible aggregation server , naha urang nulis eta jeung naha urang ditinggalkeun brubeck.
Ti artikel kami saméméhna (, ) anjeun bisa manggihan yén nepi ka sababaraha waktu urang dikumpulkeun tanda ngagunakeun . Ditulis dina C. Ti sudut pandang kode, éta sagampil colokan a (ieu penting lamun rék nyumbangkeun) jeung, paling importantly, éta handles jilid kami 2 juta metrics per detik (MPS) di puncak. tanpa masalah. Dokuméntasi nyatakeun dukungan pikeun 4 juta MPS kalayan tanda bintang. Ieu ngandung harti yén anjeun bakal kéngingkeun angka anu dinyatakeun upami anjeun ngonpigurasikeun jaringan anu leres dina Linux. (Kami henteu terang sabaraha MPS anjeun tiasa kéngingkeun upami anjeun ngantunkeun jaringan sapertos kitu). Sanajan kaunggulan ieu, urang kungsi sababaraha keluhan serius ngeunaan brubeck.
Klaim 1. Github, pamekar proyék, lirén ngadukung éta: nyebarkeun patches sareng perbaikan, nampi milik kami sareng (henteu ngan ukur milik kami) PR. Dina sababaraha bulan panungtungan (tempat ti Pébruari-Maret 2018), aktivitas geus dilanjutkeun, tapi saméméh éta aya ampir 2 taun tenang lengkep. Sajaba ti éta, proyék nu keur dimekarkeun , nu bisa jadi halangan serius pikeun bubuka fitur anyar.
Klaim 2. Akurasi itungan. Brubeck ngumpulkeun jumlahna 65536 nilai pikeun agrégasi. Dina kasus urang, pikeun sababaraha métrik, salami periode agrégasi (30 detik), langkung seueur nilai anu tiasa sumping (1 dina puncak). Salaku hasil tina sampling ieu, nilai maksimum sareng minimum sigana henteu aya gunana. Contona, saperti kieu:
Sakumaha éta
Kudu kumaha
Pikeun alesan anu sami, jumlahna umumna teu leres diitung. Tambahkeun dieu bug ku 32-bit ngambang ngabahekeun, nu umumna ngirimkeun server ka segfault nalika narima métrik sahingga bisa hirup kalawan polos, jeung sagalana janten hébat. Ku jalan kitu, bug teu acan dibereskeun.
Sarta pamustunganana Klaim X. Dina waktos nyerat, kami siap nampilkeun ka sadaya 14 langkung atanapi kirang palaksanaan statsd anu tiasa kami mendakan. Hayu urang bayangkeun yén sababaraha infrastruktur tunggal parantos ningkat pisan sahingga nampi 4 juta MPS henteu cekap deui. Atawa sanajan eta teu acan tumuwuh, tapi metrics geus jadi penting pikeun anjeun sanajan pondok, 2-3 menit dips dina grafik geus bisa jadi kritis sarta ngabalukarkeun bouts depresi insurmountable diantara manajer. Kusabab ngubaran déprési mangrupikeun tugas anu henteu ngahatur nuhun, solusi téknis diperyogikeun.
Firstly, kasabaran sesar, ku kituna masalah dadakan dina server teu ngabalukarkeun apocalypse zombie jiwa di kantor. Bréh, skala pikeun bisa nampa leuwih ti 4 juta MPS, tanpa digging jero kana tumpukan jaringan Linux Ubuntu jeung kalem tumuwuh "dina breadth" kana ukuran diperlukeun.
Kusabab kami ngagaduhan rohangan pikeun skala, kami mutuskeun pikeun ngamimitian ku kasabaran kasalahan. "KIRA! Kasalahan toleransi! Éta saderhana, urang tiasa ngalakukeun éta, ”pikir kami sareng ngaluncurkeun 2 server, naékkeun salinan brubeck dina masing-masing. Jang ngalampahkeun ieu, urang kudu nyalin lalulintas kalawan metrics ka duanana server na malah nulis pikeun ieu . Urang direngsekeun masalah kasabaran sesar jeung ieu, tapi ... teu pisan ogé. Awalna sagalana seemed hébat: unggal brubeck ngumpulkeun versi sorangan tina aggregation, nyerat data ka grafit sakali unggal 30 detik, overwriting interval heubeul (ieu dipigawé dina samping grafit). Upami hiji server ujug-ujug gagal, urang sok gaduh anu kadua sareng salinan data agrégatna nyalira. Tapi ieu masalahna: lamun server gagal, a "saw" nembongan dina grafik. Ieu alatan kanyataan yén interval 30 detik brubeck teu nyingkronkeun, sarta dina momen kacilakaan salah sahijina teu overwritten. Nalika server kadua dimimitian, hal anu sarua kajadian. Cukup lumayan, tapi kuring hoyong anu langkung saé! Masalah scalability ogé henteu musna. Sadaya métrik masih "ngapung" ka server tunggal, sareng ku kituna kami dugi ka 2-4 juta MPS sami, gumantung kana tingkat jaringan.
Upami anjeun mikir sakedik ngeunaan masalah sareng dina waktos anu sami ngali salju nganggo sekop, maka ideu anu jelas di handap ieu tiasa émut: anjeun peryogi statsd anu tiasa dianggo dina modeu disebarkeun. Nyaéta, hiji anu ngalaksanakeun sinkronisasi antara titik dina waktos sareng métrik. "Tangtosna, solusi sapertos kitu sigana parantos aya," saur kami sareng angkat ka Google…. Jeung maranéhna manggihan nanaon. Sanggeus ngaliwatan dokuméntasi pikeun statsd béda ( ti 11.12.2017 Désémber XNUMX), kami henteu mendakan nanaon. Tétéla, boh pamekar atawa pamaké tina solusi ieu teu acan sapatemon SO loba metrics, disebutkeun aranjeunna pasti bakal datang nepi ka hiji hal.
Lajeng urang inget ngeunaan "kaulinan" statsd - bioyino, nu ieu ditulis dina Just for Fun hackathon (nami proyék ieu dihasilkeun ku naskah saméméh mimiti hackathon nu) jeung sadar yen urang urgently diperlukeun statsd urang sorangan. Kanggo naon?
- sabab aya saeutik teuing klon statsd di dunya,
- sabab mungkin pikeun nyayogikeun anu dipikahoyong atanapi caket kana kasabaran sareng skalabilitas anu dipikahoyong (kalebet nyingkronkeun métrik agrégat antara server sareng ngarengsekeun masalah ngirim konflik),
- sabab mungkin pikeun ngitung métrik langkung akurat tibatan brubeck,
- sabab anjeun tiasa ngumpulkeun statistik anu langkung rinci sorangan, anu sacara praktis henteu disayogikeun ku brubeck ka kami,
- sabab kuring kungsi kasempetan ka program sorangan hyperperformance disebarkeun aplikasi lab skala, nu moal lengkep ngulang arsitektur hyperfor sejen sarupa ... sumur, éta.
Naon nulis dina? Tangtu, dina Rust. Naha?
- sabab geus aya solusi prototipe,
- sabab panulis artikel geus terang Rust dina waktu éta sarta hayang pisan nulis hal di dinya pikeun produksi jeung kasempetan pikeun nempatkeun eta dina open-source,
- sabab basa nganggo GC henteu cocog pikeun urang kusabab sifat lalu lintas anu ditampi (ampir waktos nyata) sareng jeda GC sacara praktis henteu tiasa ditampi,
- sabab anjeun peryogi kinerja maksimal anu dibandingkeun sareng C
- sabab Rust nyadiakeun kami kalawan concurrency henteu sieun, sarta lamun urang mimiti nulis dina C / C ++, urang bakal raked di malah leuwih vulnerabilities, overflows panyangga, kaayaan lomba jeung kecap pikasieuneun séjén ti brubeck.
Aya ogé argumen ngalawan Rust. Pausahaan teu boga pangalaman nyieun proyék di Rust, sarta ayeuna urang ogé teu rencanana ngagunakeun eta dina proyék utama. Ku alatan éta, aya kasieun serius yén nanaon bakal hasil, tapi urang mutuskeun pikeun nyokot kasempetan jeung diusahakeun.
Waktu geus kaliwat...
Tungtungna, saatos sababaraha usaha gagal, versi kerja anu munggaran parantos siap. Aya naon? Ieu kajadian.
Unggal titik narima set sorangan tina metrics sarta accumulates aranjeunna, sarta henteu agrégat metrics pikeun maranéhanana jenis dimana set lengkep maranéhanana diperlukeun pikeun aggregation final. Titik disambungkeun ka silih ku sababaraha jenis protokol konci disebarkeun, nu ngidinan Anjeun pikeun milih diantara aranjeunna ngan hiji (di dieu urang ceurik) nu pantes ngirim metrics ka Nu Maha Agung. Masalah ieu ayeuna keur direngsekeun ku , Tapi dina mangsa nu bakal datang ambisi pangarang ngalegaan ka Rakit, dimana anu paling pantes, tangtosna, janten titik pamimpin konsensus. Salian konsensus, titik cukup sering (sakali per detik sacara standar) ngirim ka tatanggana bagian-bagian tina métrik pre-aggregated yén maranéhna junun ngumpulkeun dina detik éta. Tétéla yén skala sareng kasabaran lepat dilestarikan - unggal titik masih nyepeng set métrik anu lengkep, tapi métrik anu dikirimkeun parantos agrégat, ngalangkungan TCP sareng disandikeun kana protokol binér, janten biaya duplikasi dikirangan sacara signifikan dibandingkeun sareng UDP. Sanajan jumlah métrik asup anu cukup badag, akumulasi merlukeun saeutik pisan memori komo kirang CPU. Pikeun mertics kacida compressible kami, ieu ngan sababaraha puluhan megabytes data. Salaku hiji bonus tambahan, urang meunang euweuh rewrites data perlu di Graphite, sakumaha ieu kasus kalawan burbeck.
pakét UDP kalawan metrics henteu saimbang antara titik dina alat jaringan ngaliwatan Round Robin basajan. Tangtosna, parangkat lunak jaringan henteu ngémutan eusi pakét sareng ku kituna tiasa narik langkung ti 4M pakét per detik, teu aya deui métrik anu teu terang nanaon. Upami urang tumut kana akun yén métrik henteu sumping hiji-hiji dina unggal pakét, maka urang henteu ngaduga masalah kinerja di tempat ieu. Upami server nabrak, alat jaringan gancang (dina 1-2 detik) ngadeteksi kanyataan ieu sareng ngahapus server nabrak tina rotasi. Hasilna, titik pasip (nyaéta, non-pamimpin) tiasa diaktipkeun sareng mareuman sacara praktis tanpa perhatikeun drawdown dina grafik. Maksimum anu urang leungit mangrupikeun bagian tina métrik anu sumping dina detik terakhir. Leungitna ngadadak / shutdown / switch pamimpin tetep bakal nyieun anomali minor (interval 30 detik masih kaluar sinkron), tapi lamun aya komunikasi antara titik, masalah ieu bisa diminimalkeun, contona, ku ngirim kaluar pakét sinkronisasi. .
A saeutik ngeunaan struktur internal. Aplikasina, tangtosna, multithreaded, tapi arsitéktur threading béda sareng anu dianggo dina brubeck. Utas dina brubeck sami - masing-masing tanggung jawab pikeun ngumpulkeun inpormasi sareng agrégasi. Dina bioyino, pagawé dibagi jadi dua kelompok: anu tanggung jawab kana jaringan sareng anu tanggung jawab pikeun agrégasi. Divisi ieu ngamungkinkeun anjeun pikeun ngatur aplikasi anu langkung fleksibel gumantung kana jinis métrik: dimana aggregation intensif diperyogikeun, anjeun tiasa nambihan agrégator, dimana aya seueur lalu lintas jaringan, anjeun tiasa nambihan jumlah aliran jaringan. Ayeuna, dina server kami, kami damel di 8 jaringan sareng 4 aliran agrégasi.
Bagian cacah (tanggung jawab aggregation) cukup boring. Buffers dieusian ku aliran jaringan disebarkeun diantara aliran cacah, dimana aranjeunna salajengna parsed na aggregated. Upami dipénta, métrik dipasihkeun pikeun ngirim ka titik anu sanés. Sadaya ieu, kalebet ngirim data antara titik sareng damel sareng Konsul, dilaksanakeun sacara teu sinkron, dijalankeun dina kerangka. .
Langkung seueur masalah nalika pangwangunan disababkeun ku bagian jaringan anu tanggung jawab pikeun nampi métrik. Tujuan utama pikeun misahkeun jaringan ngalir kana éntitas misah éta kahayang pikeun ngurangan waktu aliran a spends teu pikeun maca data tina stop kontak. Pilihan anu ngagunakeun UDP asinkron sareng recvmsg biasa gancang ngaleungit: anu kahiji nganggo seueur teuing CPU ruang-pamaké pikeun ngolah acara, anu kadua ngabutuhkeun seueur teuing saklar konteks. Ku sabab eta ayeuna dipaké kalawan buffers badag (sarta buffers, perwira gentlemen, euweuh ka anjeun!). Rojongan pikeun UDP biasa ditangtayungan pikeun kasus lampu dimana recvmmsg teu diperlukeun. Dina modeu multimessage, kasebut nyaéta dimungkinkeun pikeun ngahontal hal utama: Lolobana waktu, thread jaringan rakes antrian OS - maca data tina stop kontak jeung mindahkeun ka panyangga userspace, ngan aya kalana pindah ka méré panyangga dieusian ka agrégator. Antrian dina stop kontak praktis henteu ngumpulkeun, jumlah pakét turun praktis henteu tumuwuh.
nyarios
Dina setélan standar, ukuran panyangga disetel ka rada badag. Lamun ujug-ujug mutuskeun pikeun nyobaan server sorangan, anjeun bisa sapatemon kanyataan yén sanggeus ngirim sajumlah leutik métrik, maranéhna moal anjog di Graphite, sésana dina panyangga stream jaringan. Pikeun damel sareng sajumlah métrik anu alit, anjeun kedah nyetél ukuran bufsize sareng ukuran antrian tugas ka nilai anu langkung alit dina konfigurasi.
Tungtungna, sababaraha grafik pikeun pencinta bagan.
Statistik ngeunaan jumlah métrik anu asup pikeun unggal server: langkung ti 2 juta MPS.
Pareuman salah sahiji titik sareng nyebarkeun deui métrik anu asup.
Statistik ngeunaan métrik kaluar: ngan hiji titik anu sok dikirim - bos razia.
Statistik operasi unggal titik, nyokot kana akun kasalahan dina sagala rupa modul sistem.
Detailing of metrics asup (ngaran métrik disumputkeun).
Naon anu urang rencanakeun pikeun ngalakukeun ieu salajengna? Tangtu, nulis kode, damn ...! Proyék éta asalna direncanakeun janten open-source sareng bakal tetep kitu sapanjang hirupna. Rencana langsung kami kalebet ngalih kana versi Raft urang sorangan, ngarobih protokol peer ka anu langkung portabel, ngenalkeun statistik internal tambahan, jinis métrik énggal, perbaikan bug sareng perbaikan sanés.
Tangtosna, sadayana wilujeng sumping ngabantosan dina pangwangunan proyék: nyiptakeun PR, Isu, upami mungkin kami bakal ngabales, ningkatkeun, jsb.
Kalayan éta, éta sadayana, mésér gajah kami!
sumber: www.habr.com