Sistim ngawaskeun sejen

16 modem, 4 operator sélulér = Laju kaluar 933.45 Mbit/s

perkenalan

Halo! Tulisan ieu ngeunaan kumaha urang nyerat sistem ngawaskeun énggal pikeun diri urang sorangan. Beda sareng anu tos aya dina kamampuan pikeun nyandak métrik sinkron frekuensi tinggi sareng konsumsi sumberdaya anu rendah pisan. Laju polling tiasa ngahontal 0.1 milidetik kalayan akurasi sinkronisasi antara métrik 10 nanodetik. Sadaya file binér ngeusian 6 megabytes.

Ngeunaan proyék nu

Simkuring boga produk rada husus. Kami ngahasilkeun solusi komprehensif pikeun nyimpulkeun throughput sareng kasabaran sesar saluran pangiriman data. Ieu nalika aya sababaraha saluran, hayu urang sebutkeun Operator1 (40Mbit / s) + Operator2 (30Mbit / s) + Hal sejenna (5 Mbit / s), hasilna mangrupa salah sahiji saluran stabil sarta gancang, laju nu bakal kawas ieu: (40+ 30+5) x0.92 = 75×0.92 = 69 Mbit / s.

Solusi sapertos kitu diperyogikeun dimana kapasitas hiji saluran henteu cekap. Contona, angkutan, sistem panjagaan video jeung real-time video streaming, siaran televisi langsung jeung siaran radio, sagala fasilitas suburban dimana diantara operator telecom ngan aya wawakil Big Four jeung speed dina hiji modem / channel teu cukup. .
Pikeun unggal daérah ieu, kami ngahasilkeun garis alat anu misah, tapi bagian parangkat lunakna ampir sami sareng sistem ngawaskeun kualitas luhur mangrupikeun salah sahiji modul utami, tanpa palaksanaan anu leres anu produkna moal mungkin.

Ngaliwatan sababaraha taun, urang junun nyieun multi-level, gancang, cross-platform jeung sistem monitoring lightweight. Ieu anu urang hoyong bagikeun sareng komunitas anu dihormat.

Ngarumuskeun masalah

Sistem ngawaskeun nyayogikeun métrik tina dua kelas anu béda-béda: métrik real-time sareng anu sanésna. Sistem ngawaskeun ngan ukur sarat di handap ieu:

1. Akuisisi sinkron frekuensi tinggi tina métrik real-time sareng transferna tina sistem manajemen komunikasi tanpa reureuh.
   Frékuénsi luhur sareng sinkronisasi métrik anu béda henteu ngan ukur penting, éta penting pikeun nganalisa éntropi saluran pangiriman data. Upami dina hiji saluran pangiriman data rata-rata tunda 30 milidetik, maka kasalahan dina sinkronisasi antara métrik sésana ngan ukur hiji milidetik bakal nyababkeun degradasi laju saluran anu hasilna sakitar 5%. Lamun urang mistime timing ku 1 milidetik sakuliah 4 saluran, degradasi speed bisa kalayan gampang turun ka 30%. Salaku tambahan, éntropi dina saluran robih gancang pisan, janten upami urang ngukur éta kirang ti sakali unggal 0.5 milliseconds, dina saluran gancang kalayan reureuh leutik urang bakal nampi degradasi kecepatan tinggi. Tangtosna, akurasi sapertos henteu diperyogikeun pikeun sadaya métrik sareng henteu dina sadaya kaayaan. Nalika reureuh dina saluran 500 milliseconds, sarta kami digawekeun ku misalna, kasalahan 1 milliseconds bakal ampir teu noticeable. Ogé, pikeun métrik sistem pangrojong kahirupan, urang gaduh tingkat polling sareng sinkronisasi anu cukup 2 detik, tapi sistem ngawaskeun sorangan kedah tiasa damel sareng tingkat polling ultra-tinggi sareng sinkronisasi métrik ultra-tepat.
2. Konsumsi sumberdaya minimal sareng tumpukan tunggal.
   Alat tungtung tiasa janten komplek on-board anu kuat anu tiasa nganalisis kaayaan di jalan atanapi ngalaksanakeun rékaman biometrik jalma, atanapi komputer papan tunggal ukuran palem anu dianggo ku prajurit pasukan khusus handapeun baju awakna pikeun ngirimkeun pidéo. waktos nyata dina kaayaan komunikasi goréng. Sanaos rupa-rupa arsitéktur sareng kakuatan komputasi, kami hoyong gaduh tumpukan parangkat lunak anu sami.
3. Arsitéktur payung
   Métrik kedah dikumpulkeun sareng dihijikeun dina alat tungtung, disimpen sacara lokal, sareng ditingali sacara real waktos sareng retrospektif. Lamun aya sambungan, mindahkeun data ka sistem monitoring sentral. Lamun euweuh sambungan, antrian ngirim kudu ngumpulkeun jeung teu meakeun RAM.
4. API pikeun integrasi kana sistem ngawaskeun customer urang, sabab teu saurang ogé perlu loba sistem ngawaskeun. Palanggan kedah ngumpulkeun data tina alat sareng jaringan naon waé kana ngawaskeun tunggal.

Aya naon

Dina raraga teu beungbeurat longread geus impressive, abdi moal masihan conto jeung ukuran sadaya sistem monitoring. Ieu bakal ngakibatkeun artikel séjén. Kuring ngan bakal nyebutkeun yén urang teu bisa manggihan sistem ngawaskeun nu sanggup nyandak dua metrics sakaligus kalawan kasalahan kirang ti 1 millidetik jeung nu gawéna sarua éféktif duanana dina arsitektur ARM kalawan 64 MB RAM na on arsitektur x86_64 kalawan 32 GB RAM. Ku alatan éta, urang mutuskeun pikeun nulis sorangan, nu bisa ngalakukeun sagala ieu. Ieu naon anu urang kéngingkeun:

Nyimpulkeun throughput tina tilu saluran pikeun topologi jaringan anu béda

Visualisasi sababaraha métrik konci

gawena undagi

Kami nganggo Golang salaku basa pamrograman utama, boh dina alat sareng di pusat data. Éta pisan nyederhanakeun kahirupan kalayan palaksanaan seueur tugas sareng kamampuan pikeun kéngingkeun file binér anu tiasa dieksekusi sacara statis pikeun tiap jasa. Hasilna, urang sacara signifikan ngahemat sumberdaya, metode sareng lalu lintas pikeun nyebarkeun jasa pikeun ngeureunkeun alat, waktos pamekaran sareng debugging kode.

Sistem ieu dilaksanakeun dumasar kana prinsip modular klasik sareng ngandung sababaraha subsistem:

1. pendaptaran metrics.
   Unggal métrik dilayanan ku benang sorangan sareng disingkronkeun dina saluran. Kami tiasa ngahontal akurasi sinkronisasi dugi ka 10 nanodetik.
2. Panyimpenan métrik
   Urang milih antara nulis gudang sorangan pikeun runtuyan waktu atawa ngagunakeun hal anu geus sadia. Basis data diperlukeun pikeun data retrospective nu tunduk kana visualisasi salajengna, nyaeta, teu ngandung data dina reureuh dina saluran unggal 0.5 milliseconds atawa maca kasalahan dina jaringan angkutan, tapi aya speed on unggal panganteur unggal 500 milliseconds. Salian sarat anu luhur pikeun cross-platform sareng konsumsi sumberdaya anu rendah, penting pisan pikeun urang tiasa ngolah. data nyaeta dimana eta disimpen. Ieu ngaheéat sumberdaya komputasi gede pisan. Kami parantos nganggo Tarantool DBMS dina proyék ieu ti saprak 2016 sareng sajauh ieu kami henteu ningali panggantian éta dina cakrawala. Fleksibel, kalayan konsumsi sumberdaya optimal, langkung ti pangrojong téknis anu nyukupan. Tarantool ogé ngalaksanakeun modul GIS. Tangtosna, éta henteu kuat sapertos PostGIS, tapi cekap pikeun tugas urang pikeun nyimpen sababaraha métrik anu aya hubunganana sareng lokasi (relevan pikeun transportasi).
3. Visualisasi métrik
   Sagalana kawilang basajan di dieu. Kami nyandak data tina gudang sareng ningalikeunana sacara real waktos atanapi sacara retrospektif.
4. Sinkronisasi data sareng sistem monitoring sentral.
   Sistem ngawaskeun sentral narima data ti sadaya alat, nyimpen eta kalawan sajarah husus sarta ngirimkeunana ka sistem ngawaskeun Palanggan urang via API. Teu kawas sistem ngawaskeun Palasik, nu "sirah" walks sabudeureun tur ngumpulkeun data, urang boga skéma sabalikna. Alat sorangan ngirim data lamun aya sambungan. Ieu mangrupikeun titik anu penting pisan, sabab ngamungkinkeun anjeun nampi data tina alat pikeun période waktos éta henteu sayogi sareng henteu ngamuat saluran sareng sumber nalika alatna henteu sayogi. Kami nganggo server ngawaskeun Influx salaku sistem ngawaskeun sentral. Beda sareng analogna, éta tiasa ngimpor data retrospektif (nyaéta, kalayan cap waktos anu béda ti waktos nampi métrik). tumpukan standar ieu ogé dipilih sabab geus siap-dijieun integrations API kalawan ampir sagala sistem ngawaskeun customer.
5. Sinkronisasi data sareng sistem manajemen alat sentral.
   Sistem manajemen alat implements Zero Toel Provisioning (ngamutahirkeun firmware, konfigurasi, jeung sajabana) jeung, kawas sistem monitoring, ngan narima masalah per alat. Ieu mangrupikeun pemicu pikeun operasi jasa pangawas hardware dina papan sareng sadaya métrik sistem pangrojong kahirupan: suhu CPU sareng SSD, beban CPU, rohangan bébas sareng kaséhatan SMART dina disk. Panyimpenan subsistem ogé diwangun dina Tarantool. Hal ieu masihan kami kagancangan anu signifikan dina ngumpulkeun séri waktos dina rébuan alat, sareng ogé lengkep ngarengsekeun masalah nyingkronkeun data sareng alat ieu. Tarantool boga antrian alus teuing jeung sistem pangiriman dijamin. Kami ngagaduhan fitur penting ieu tina kotak, saé!

Sistim manajemén jaringan

Naon salajengna

Sajauh ieu, link weakest kami nyaéta sistem monitoring sentral. Éta dilaksanakeun 99.9% dina tumpukan standar sareng gaduh sababaraha kalemahan:

1. InfluxDB kaleungitan data nalika kakuatan leungit. Sakumaha aturan, Palanggan promptly ngumpulkeun sagalana nu asalna ti alat jeung database sorangan teu ngandung data heubeul ti 5 menit, tapi di mangsa nu bakal datang ieu bisa jadi nyeri.
2. Grafana gaduh sababaraha masalah sareng aggregation data sareng sinkronisasi tampilan na. Masalah anu paling umum nyaéta nalika pangkalan data ngandung séri waktos kalayan interval 2 detik mimitian ti, sebutkeun, 00:00:00, sareng Grafana mimiti nunjukkeun data dina aggregation tina +1 detik. Hasilna, pamaké ningali grafik menari.
3. Jumlah kaleuleuwihan kode pikeun integrasi API sareng sistem ngawaskeun pihak katilu. Éta tiasa dilakukeun langkung kompak sareng tangtosna ditulis deui dina Go)

Jigana anjeun sadaya geus katempo sampurna kumaha Grafana Sigana mah jeung nyaho masalah na tanpa kuring, jadi kuring moal overload pos kalawan gambar.

kacindekan

Kuring ngahaja henteu ngajelaskeun detil téknis, tapi ngan ukur ngajelaskeun desain dasar tina sistem ieu. Anu mimiti, pikeun ngajelaskeun sistem sacara téknis sacara lengkep, peryogi tulisan anu sanés. Bréh, teu sadaya jelema bakal kabetot dina ieu. Tulis dina koméntar naon rinci téknis anu anjeun hoyong terang.

Upami aya anu gaduh patarosan saluareun ruang lingkup tulisan ieu, anjeun tiasa nyerat ka kuring di a.rodin @ qedr.com

sumber: www.habr.com