Sistem pemantauan liyane

16 modem, 4 operator seluler = Kacepetan metu 933.45 Mbit/s

Pambuka

Hello! Artikel iki babagan carane nulis sistem pemantauan anyar kanggo awake dhewe. Beda karo sing ana ing kemampuan kanggo entuk metrik sinkron frekuensi dhuwur lan konsumsi sumber daya sing sithik. Tingkat polling bisa tekan 0.1 milidetik kanthi akurasi sinkronisasi antarane metrik 10 nanodetik. Kabeh file binar manggoni 6 megabyte.

Prakawis proyek

Kita duwe produk sing rada spesifik. Kita ngasilake solusi lengkap kanggo ngringkes throughput lan toleransi kesalahan saluran transmisi data. Iki nalika ana sawetara saluran, ayo ngomong Operator1 (40Mbit / s) + Operator2 (30Mbit / s) + Liyane (5 Mbit / s), asil kasebut minangka saluran sing stabil lan cepet, kacepetan sing bakal kaya. iki: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Solusi kasebut dikarepake yen kapasitas saluran siji ora cukup. Contone, transportasi, sistem pengawasan video lan streaming video wektu nyata, siaran langsung siaran televisi lan radio, fasilitas suburban sing ana ing antarane operator telekomunikasi mung ana wakil saka Big Four lan kacepetan ing modem / saluran ora cukup. .
Kanggo saben wilayah kasebut, kita ngasilake baris piranti sing kapisah, nanging bagean piranti lunak meh padha lan sistem pemantauan kualitas minangka salah sawijining modul utama, tanpa implementasine sing bener, produk kasebut ora bakal bisa ditindakake.

Sajrone pirang-pirang taun, kita bisa nggawe sistem pemantauan multi-level, cepet, lintas-platform lan entheng. Iki sing arep kita bareng-bareng karo masyarakat sing dihormati.

Formulasi masalah

Sistem ngawasi nyedhiyakake metrik saka rong kelas dhasar sing beda: metrik wektu nyata lan kabeh liyane. Sistem pemantauan mung nduweni syarat ing ngisor iki:

1. Akuisisi sinkron frekuensi dhuwur saka metrik wektu nyata lan transfer menyang sistem manajemen komunikasi tanpa wektu tundha.
   Frekuensi dhuwur lan sinkronisasi metrik sing beda-beda ora mung penting, nanging penting kanggo nganalisa entropi saluran transmisi data. Yen ing siji saluran transmisi data, wektu tundha rata-rata yaiku 30 milidetik, banjur kesalahan sinkronisasi antarane metrik sing isih ana mung siji milidetik bakal nyebabake degradasi kacepetan saluran sing diasilake kira-kira 5%. Yen kita salah nemtokake wektu kanthi 1 milidetik ing 4 saluran, degradasi kacepetan bisa gampang mudhun nganti 30%. Kajaba iku, entropi ing saluran diganti kanthi cepet, dadi yen kita ngukur kurang saka sapisan saben 0.5 milidetik, ing saluran cepet kanthi wektu tundha cilik, kita bakal entuk degradasi kacepetan dhuwur. Mesthine, akurasi kasebut ora dibutuhake kanggo kabeh metrik lan ora ing kabeh kahanan. Nalika wektu tundha ing saluran punika 500 milliseconds, lan kita bisa karo kuwi, banjur kesalahan 1 milliseconds bakal meh ora katon. Uga, kanggo metrik sistem dhukungan urip, kita duwe tingkat polling lan sinkronisasi sing cukup 2 detik, nanging sistem ngawasi dhewe kudu bisa nggarap tingkat polling ultra-dhuwur lan sinkronisasi metrik ultra-tepat.
2. Konsumsi sumber daya minimal lan tumpukan siji.
   Piranti pungkasan bisa dadi salah siji komplek on-board sing kuat sing bisa nganalisa kahanan ing dalan utawa nindakake rekaman biometrik wong, utawa komputer papan siji ukuran palem sing nganggo prajurit pasukan khusus ing sangisore waja awak kanggo ngirim video ing wektu nyata ing kahanan komunikasi miskin. Senadyan macem-macem arsitektur lan daya komputasi, kita pengin duwe tumpukan piranti lunak sing padha.
3. Arsitektur payung
   Metrik kudu diklumpukake lan dikumpulake ing piranti pungkasan, disimpen sacara lokal, lan digambarake ing wektu nyata lan retrospektif. Yen ana sambungan, transfer data menyang sistem ngawasi tengah. Nalika ora ana sambungan, antrian ngirim kudu nglumpukake lan ora nganggo RAM.
4. API kanggo integrasi menyang sistem ngawasi customer, amarga ora ana sing perlu akeh sistem ngawasi. Pelanggan kudu ngumpulake data saka piranti lan jaringan apa wae dadi pemantauan siji.

Ana apa

Supaya ora mbebani longread sing wis nyengsemake, aku ora bakal menehi conto lan pangukuran kabeh sistem pemantauan. Iki bakal mimpin menyang artikel liyane. Aku mung bakal ujar manawa kita ora bisa nemokake sistem pemantauan sing bisa njupuk rong metrik bebarengan kanthi kesalahan kurang saka 1 milidetik lan bisa digunakake kanthi efektif ing arsitektur ARM kanthi 64 MB RAM lan ing arsitektur x86_64 kanthi 32 GB RAM. Mulane, kita mutusake kanggo nulis dhewe, sing bisa nindakake kabeh iki. Punika ingkang kita pikantuk:

Ringkesan throughput saka telung saluran kanggo topologi jaringan sing beda

Visualisasi sawetara metrik kunci

arsitektur

Kita nggunakake Golang minangka basa pamrograman utama, ing piranti lan ing pusat data. Nyederhanakake urip kanthi implementasine multitasking lan kemampuan kanggo entuk file binar sing bisa dieksekusi kanthi statis kanggo saben layanan. Akibaté, kita nyimpen akeh sumber daya, cara lan lalu lintas kanggo nyebarke layanan kanggo mungkasi piranti, wektu pangembangan lan kode debugging.

Sistem kasebut ditindakake miturut prinsip modular klasik lan ngemot sawetara subsistem:

1. Registrasi metrik.
   Saben metrik dilayani dening benang dhewe lan disinkronake ing saluran. Kita bisa nggayuh akurasi sinkronisasi nganti 10 nanodetik.
2. Panyimpenan metrik
   Kita padha milih antarane nulis panyimpenan kita dhewe kanggo seri wektu utawa nggunakake soko sing wis kasedhiya. Basis data dibutuhake kanggo data retrospektif sing tundhuk visualisasi sabanjure, yaiku, ora ngemot data babagan wektu tundha ing saluran saben 0.5 milidetik utawa kesalahan maca ing jaringan transportasi, nanging ana kacepetan ing saben antarmuka saben 500 milidetik. Saliyane syarat dhuwur kanggo cross-platform lan konsumsi sumber daya kurang, iku arang banget penting kanggo kita bisa proses. data ing ngendi iku disimpen. Iki ngirit sumber daya komputasi sing gedhe banget. Kita wis nggunakake Tarantool DBMS ing proyek iki wiwit 2016 lan nganti saiki kita ora weruh panggantos ing cakrawala. Fleksibel, kanthi konsumsi sumber daya sing optimal, dhukungan teknis sing luwih saka nyukupi. Tarantool uga ngleksanakake modul GIS. Mesthine, ora sekuat PostGIS, nanging cukup kanggo tugas kita nyimpen sawetara metrik sing gegandhengan karo lokasi (relevan kanggo transportasi).
3. Visualisasi metrik
   Kabeh iku relatif prasaja ing kene. Kita njupuk data saka gudang lan nampilake ing wektu nyata utawa sacara retrospektif.
4. Sinkronisasi data karo sistem pemantauan pusat.
   Sistem ngawasi tengah nampa data saka kabeh piranti, nyimpen karo sajarah tartamtu lan dikirim menyang sistem ngawasi Pelanggan liwat API. Ora kaya sistem pemantauan klasik, ing ngendi "kepala" mlaku-mlaku lan ngumpulake data, kita duwe skema sing ngelawan. Piranti kasebut dhewe ngirim data nalika ana sambungan. Iki minangka titik sing penting banget, amarga ngidini sampeyan nampa data saka piranti sajrone wektu kasebut ora kasedhiya lan ora mbukak saluran lan sumber daya nalika piranti ora kasedhiya. Kita nggunakake server pemantauan Influx minangka sistem pemantauan pusat. Ora kaya analoge, bisa ngimpor data retrospektif (yaiku, kanthi cap wektu sing beda karo nalika metrik ditampa). Tumpukan standar iki uga dipilih amarga nduweni integrasi API sing wis siap karo meh kabeh sistem pemantauan pelanggan.
5. Sinkronisasi data karo sistem manajemen piranti pusat.
   Sistem manajemen piranti ngleksanakake Zero Touch Provisioning (nganyari perangkat kukuh, konfigurasi, etc.) lan, ora kaya sistem ngawasi, mung nampa masalah saben piranti. Iki minangka pemicu kanggo operasi layanan pengawas hardware ing papan lan kabeh metrik sistem dhukungan urip: suhu CPU lan SSD, beban CPU, ruang kosong lan kesehatan SMART ing disk. Panyimpenan subsistem uga dibangun ing Tarantool. Iki menehi kacepetan sing signifikan kanggo nglumpukake seri wektu ing ewonan piranti, lan uga ngrampungake masalah sinkronisasi data karo piranti kasebut. Tarantool duwe antrian sing apik lan sistem pangiriman sing dijamin. We entuk fitur penting iki metu saka kothak, apik!

Sistem manajemen jaringan

Apa mbesuk

Nganti saiki, link sing paling lemah yaiku sistem pemantauan pusat. Iki diimplementasikake 99.9% ing tumpukan standar lan duwe sawetara kekurangan:

1. InfluxDB kelangan data nalika daya ilang. Minangka aturan, Pelanggan langsung ngumpulake kabeh sing teka saka piranti lan database dhewe ora ngemot data lawas saka 5 menit, nanging ing mangsa iki bisa dadi pain.
2. Grafana duwe sawetara masalah karo agregasi data lan sinkronisasi tampilan. Masalah sing paling umum yaiku nalika database ngemot seri wektu kanthi interval 2 detik wiwit saka, ngomong, 00:00:00, lan Grafana wiwit nuduhake data kanthi gabungan saka +1 detik. Akibaté, pangguna ndeleng grafik tarian.
3. Jumlah kode sing akeh banget kanggo integrasi API karo sistem pemantauan pihak katelu. Bisa digawe luwih kompak lan mesthi ditulis maneh ing Go)

Aku sampeyan kabeh wis katon sampurna kaya Grafana lan ngerti masalah tanpa kula, supaya aku ora bakal kakehan kirim karo gambar.

kesimpulan

Aku sengaja ora njlèntrèhaké rincian technical, nanging mung diterangake desain dhasar saka sistem iki. Kaping pisanan, kanggo njlèntrèhaké sistem kanthi teknis, artikel liya bakal dibutuhake. Kapindho, ora kabeh wong bakal kasengsem ing iki. Tulis ing komentar apa rincian teknis sing pengin sampeyan ngerti.

Yen ana sing duwe pitakon ngluwihi ruang lingkup artikel iki, sampeyan bisa nulis menyang aku ing a.rodin @ qedr.com

Source: www.habr.com