Satu lagi sistem pemantauan

16 modem, 4 operator selular = Kelajuan keluar 933.45 Mbit/s

Pengenalan

hello! Artikel ini adalah tentang cara kami menulis sistem pemantauan baharu untuk diri kami sendiri. Ia berbeza daripada yang sedia ada dalam keupayaannya untuk mendapatkan metrik segerak frekuensi tinggi dan penggunaan sumber yang sangat rendah. Kadar pengundian boleh mencapai 0.1 milisaat dengan ketepatan penyegerakan antara metrik 10 nanosaat. Semua fail binari menduduki 6 megabait.

mengenai

Kami mempunyai produk yang agak spesifik. Kami menghasilkan penyelesaian yang komprehensif untuk meringkaskan daya pemprosesan dan toleransi kesalahan saluran penghantaran data. Ini apabila terdapat beberapa saluran, katakan Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Sesuatu yang lain (5 Mbit/s), hasilnya adalah satu saluran yang stabil dan pantas, yang kelajuannya akan menjadi seperti ini: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Penyelesaian sedemikian adalah dalam permintaan apabila kapasiti mana-mana satu saluran tidak mencukupi. Sebagai contoh, pengangkutan, sistem pengawasan video dan penstriman video masa nyata, penyiaran siaran langsung televisyen dan radio, sebarang kemudahan pinggir bandar di mana di kalangan pengendali telekomunikasi hanya terdapat wakil Big Four dan kelajuan pada satu modem/saluran tidak mencukupi. .
Bagi setiap kawasan ini, kami menghasilkan barisan peranti yang berasingan, tetapi bahagian perisiannya hampir sama dan sistem pemantauan berkualiti tinggi adalah salah satu modul utamanya, tanpa pelaksanaan yang betul yang mana produk itu tidak akan dapat dilaksanakan.

Sepanjang beberapa tahun, kami berjaya mencipta sistem pemantauan berbilang peringkat, pantas, merentas platform dan ringan. Inilah yang ingin kami kongsikan dengan komuniti kami yang dihormati.

Pernyataan masalah

Sistem pemantauan menyediakan metrik dua kelas yang berbeza secara asas: metrik masa nyata dan semua yang lain. Sistem pemantauan hanya mempunyai keperluan berikut:

1. Pemerolehan segerak frekuensi tinggi bagi metrik masa nyata dan pemindahannya ke sistem pengurusan komunikasi tanpa berlengah-lengah.
   Frekuensi tinggi dan penyegerakan metrik yang berbeza bukan sahaja penting, ia adalah penting untuk menganalisis entropi saluran penghantaran data. Jika dalam satu saluran penghantaran data, kelewatan purata ialah 30 milisaat, maka ralat dalam penyegerakan antara baki metrik hanya satu milisaat akan membawa kepada penurunan kelajuan saluran yang terhasil sebanyak lebih kurang 5%. Jika kita tersilap masa sebanyak 1 milisaat merentasi 4 saluran, kemerosotan kelajuan boleh turun dengan mudah kepada 30%. Di samping itu, entropi dalam saluran berubah dengan sangat cepat, jadi jika kita mengukurnya kurang daripada sekali setiap 0.5 milisaat, pada saluran pantas dengan kelewatan kecil kita akan mendapat degradasi kelajuan tinggi. Sudah tentu, ketepatan sedemikian tidak diperlukan untuk semua metrik dan bukan dalam semua keadaan. Apabila kelewatan dalam saluran adalah 500 milisaat, dan kami bekerja dengan sedemikian, maka ralat 1 milisaat hampir tidak dapat dilihat. Selain itu, untuk metrik sistem sokongan hayat, kami mempunyai kadar pengundian dan penyegerakan yang mencukupi selama 2 saat, tetapi sistem pemantauan itu sendiri mesti dapat berfungsi dengan kadar undian ultra tinggi dan penyegerakan metrik ultra-tepat.
2. Penggunaan sumber yang minimum dan satu timbunan.
   Peranti akhir boleh sama ada kompleks atas kapal yang berkuasa yang boleh menganalisis keadaan di jalan raya atau menjalankan rakaman biometrik orang, atau komputer papan tunggal bersaiz tapak tangan yang dipakai oleh askar pasukan khas di bawah perisai badannya untuk menghantar video dalam masa nyata dalam keadaan komunikasi yang lemah. Walaupun begitu pelbagai seni bina dan kuasa pengkomputeran, kami ingin mempunyai susunan perisian yang sama.
3. Seni bina payung
   Metrik mesti dikumpulkan dan diagregatkan pada peranti akhir, mempunyai storan setempat dan divisualisasikan dalam masa nyata dan retrospektif. Jika terdapat sambungan, pindahkan data ke sistem pemantauan pusat. Apabila tiada sambungan, baris gilir penghantaran harus terkumpul dan tidak menggunakan RAM.
4. API untuk penyepaduan ke dalam sistem pemantauan pelanggan, kerana tiada siapa yang memerlukan banyak sistem pemantauan. Pelanggan mesti mengumpul data daripada mana-mana peranti dan rangkaian ke dalam satu pemantauan.

Apa yang berlaku

Untuk tidak membebankan bacaan panjang yang sudah mengagumkan, saya tidak akan memberikan contoh dan ukuran semua sistem pemantauan. Ini akan membawa kepada artikel lain. Saya hanya akan mengatakan bahawa kami tidak dapat mencari sistem pemantauan yang mampu mengambil dua metrik serentak dengan ralat kurang daripada 1 milisaat dan yang berfungsi sama berkesan pada seni bina ARM dengan 64 MB RAM dan pada seni bina x86_64 dengan 32 GB RAM. Oleh itu, kami memutuskan untuk menulis kami sendiri, yang boleh melakukan semua ini. Inilah yang kami dapat:

Merumuskan pemprosesan tiga saluran untuk topologi rangkaian yang berbeza

Visualisasi beberapa metrik utama

seni bina

Kami menggunakan Golang sebagai bahasa pengaturcaraan utama, pada peranti dan pusat data. Ia sangat memudahkan kehidupan dengan pelaksanaan multitasking dan keupayaan untuk mendapatkan satu fail binari boleh laku yang dipautkan secara statik untuk setiap perkhidmatan. Akibatnya, kami menjimatkan sumber, kaedah dan trafik dengan ketara untuk menggunakan perkhidmatan untuk menamatkan peranti, masa pembangunan dan penyahpepijatan kod.

Sistem ini dilaksanakan mengikut prinsip modular klasik dan mengandungi beberapa subsistem:

1. Pendaftaran metrik.
   Setiap metrik disediakan oleh urutannya sendiri dan disegerakkan merentas saluran. Kami dapat mencapai ketepatan penyegerakan sehingga 10 nanosaat.
2. Storan metrik
   Kami memilih antara menulis storan kami sendiri untuk siri masa atau menggunakan sesuatu yang sudah tersedia. Pangkalan data diperlukan untuk data retrospektif yang tertakluk kepada visualisasi berikutnya. Iaitu, ia tidak mengandungi data tentang kelewatan dalam saluran setiap 0.5 milisaat atau bacaan ralat dalam rangkaian pengangkutan, tetapi terdapat kelajuan pada setiap antara muka setiap 500 milisaat. Sebagai tambahan kepada keperluan yang tinggi untuk merentas platform dan penggunaan sumber yang rendah, adalah amat penting bagi kami untuk dapat memproses. data adalah tempat ia disimpan. Ini menjimatkan sumber pengkomputeran yang besar. Kami telah menggunakan Tarantool DBMS dalam projek ini sejak 2016 dan setakat ini kami tidak melihat penggantinya di kaki langit. Fleksibel, dengan penggunaan sumber yang optimum, lebih daripada sokongan teknikal yang mencukupi. Tarantool juga melaksanakan modul GIS. Sudah tentu, ia tidak sekuat PostGIS, tetapi ia cukup untuk tugas kami menyimpan beberapa metrik berkaitan lokasi (berkaitan untuk pengangkutan).
3. Visualisasi metrik
   Segala-galanya agak mudah di sini. Kami mengambil data dari gudang dan memaparkannya sama ada dalam masa nyata atau secara retrospektif.
4. Penyegerakan data dengan sistem pemantauan pusat.
   Sistem pemantauan pusat menerima data daripada semua peranti, menyimpannya dengan sejarah tertentu dan menghantarnya ke sistem pemantauan Pelanggan melalui API. Tidak seperti sistem pemantauan klasik, di mana "kepala" berjalan-jalan dan mengumpul data, kami mempunyai skema yang bertentangan. Peranti itu sendiri menghantar data apabila terdapat sambungan. Ini adalah perkara yang sangat penting, kerana ia membolehkan anda menerima data daripada peranti untuk tempoh masa semasa ia tidak tersedia dan tidak memuatkan saluran dan sumber semasa peranti tidak tersedia. Kami menggunakan pelayan pemantauan Influx sebagai sistem pemantauan pusat. Tidak seperti analognya, ia boleh mengimport data retrospektif (iaitu, dengan cap masa yang berbeza daripada saat metrik diterima). Metrik yang dikumpul divisualisasikan oleh Grafana, diubah suai dengan fail. Tindanan standard ini juga dipilih kerana ia mempunyai integrasi API siap pakai dengan hampir mana-mana sistem pemantauan pelanggan.
5. Penyegerakan data dengan sistem pengurusan peranti pusat.
   Sistem pengurusan peranti melaksanakan Zero Touch Provisioning (mengemas kini perisian tegar, konfigurasi, dll.) dan, tidak seperti sistem pemantauan, hanya menerima masalah bagi setiap peranti. Ini adalah pencetus untuk pengendalian perkhidmatan pengawas perkakasan atas papan dan semua metrik sistem sokongan hayat: suhu CPU dan SSD, beban CPU, ruang kosong dan kesihatan SMART pada cakera. Storan subsistem juga dibina pada Tarantool. Ini memberi kami kelajuan yang ketara dalam mengagregatkan siri masa merentas beribu-ribu peranti, dan juga menyelesaikan sepenuhnya isu penyegerakan data dengan peranti ini. Tarantool mempunyai sistem penghantaran beratur yang sangat baik dan terjamin. Kami mendapat ciri penting ini daripada kotak, hebat!

Sistem pengurusan rangkaian

Apa yang Seterusnya

Setakat ini, pautan paling lemah kami ialah sistem pemantauan pusat. Ia dilaksanakan 99.9% pada timbunan standard dan mempunyai beberapa kelemahan:

1. InfluxDB kehilangan data apabila kuasa hilang. Sebagai peraturan, Pelanggan segera mengumpul semua yang datang dari peranti dan pangkalan data itu sendiri tidak mengandungi data yang lebih lama daripada 5 minit, tetapi pada masa hadapan ini mungkin menjadi sakit.
2. Grafana mempunyai beberapa masalah dengan pengagregatan data dan penyegerakan paparannya. Masalah yang paling biasa ialah apabila pangkalan data mengandungi siri masa dengan selang 2 saat bermula dari, katakan, 00:00:00, dan Grafana mula menunjukkan data dalam pengagregatan dari +1 saat. Akibatnya, pengguna melihat graf menari.
3. Jumlah kod yang berlebihan untuk penyepaduan API dengan sistem pemantauan pihak ketiga. Ia boleh dibuat lebih padat dan sudah tentu ditulis semula dalam Go)

Saya rasa anda semua telah melihat dengan sempurna rupa Grafana dan mengetahui masalahnya tanpa saya, jadi saya tidak akan membebankan siaran dengan gambar.

Kesimpulan

Saya sengaja tidak menerangkan butiran teknikal, tetapi hanya menerangkan reka bentuk asas sistem ini. Pertama, untuk menerangkan sistem secara teknikal sepenuhnya, artikel lain akan diperlukan. Kedua, tidak semua orang akan berminat dengan ini. Tulis dalam komen butiran teknikal yang anda ingin ketahui.

Jika sesiapa mempunyai soalan di luar skop artikel ini, anda boleh menulis kepada saya di a.rodin @ qedr.com

Sumber: www.habr.com