16 modem, 4 operator seluler = Kecepatan keluar 933.45 Mbit/s
pengenalan
Halo! Artikel ini tentang bagaimana kami menulis sistem pemantauan baru untuk diri kami sendiri. Ini berbeda dari yang sudah ada dalam kemampuannya memperoleh metrik sinkron frekuensi tinggi dan konsumsi sumber daya yang sangat rendah. Kecepatan pollingnya bisa mencapai 0.1 milidetik dengan akurasi sinkronisasi antar metrik 10 nanodetik. Semua file biner menempati 6 megabyte.
tentang
Kami memiliki produk yang agak spesifik. Kami menghasilkan solusi komprehensif untuk merangkum throughput dan toleransi kesalahan saluran transmisi data. Ini bila ada beberapa saluran, misalkan Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Sesuatu yang lain (5 Mbit/s), hasilnya adalah satu saluran yang stabil dan cepat, yang kecepatannya kira-kira seperti ini: (40+ 30+5)x0.92=75Γ0.92=69 Mbit/dtk.
Solusi seperti ini dibutuhkan ketika kapasitas satu saluran tidak mencukupi. Misalnya, transportasi, sistem pengawasan video dan streaming video real-time, siaran siaran langsung televisi dan radio, fasilitas pinggiran kota di mana di antara operator telekomunikasi hanya terdapat perwakilan dari Empat Besar dan kecepatan pada satu modem/saluran saja tidak cukup. .
Untuk masing-masing area ini, kami memproduksi rangkaian perangkat terpisah, tetapi bagian perangkat lunaknya hampir sama dan sistem pemantauan berkualitas tinggi adalah salah satu modul utamanya, tanpa implementasi yang benar maka produk tidak akan mungkin dihasilkan.
Selama beberapa tahun, kami berhasil menciptakan sistem pemantauan multi-level, cepat, lintas platform, dan ringan. Inilah yang ingin kami bagikan dengan komunitas kami yang terhormat.
Pernyataan masalah
Sistem pemantauan menyediakan metrik dari dua kelas yang berbeda secara mendasar: metrik waktu nyata dan lainnya. Sistem pemantauan hanya memiliki persyaratan berikut:
- Akuisisi metrik real-time secara sinkron frekuensi tinggi dan transfernya ke sistem manajemen komunikasi tanpa penundaan.
Frekuensi tinggi dan sinkronisasi metrik yang berbeda tidak hanya penting, tetapi juga penting untuk menganalisis entropi saluran transmisi data. Jika dalam satu saluran transmisi data rata-rata penundaan adalah 30 milidetik, maka kesalahan sinkronisasi antara metrik yang tersisa hanya satu milidetik akan menyebabkan penurunan kecepatan saluran yang dihasilkan sekitar 5%. Jika kita salah mengatur waktu sebesar 1 milidetik di 4 saluran, penurunan kecepatan dapat dengan mudah turun hingga 30%. Selain itu, entropi dalam saluran berubah dengan sangat cepat, jadi jika kita mengukurnya kurang dari sekali setiap 0.5 milidetik, pada saluran cepat dengan penundaan kecil kita akan mendapatkan penurunan kecepatan tinggi. Tentu saja, akurasi seperti itu tidak diperlukan untuk semua metrik dan tidak di semua kondisi. Ketika penundaan saluran adalah 500 milidetik, dan kami mengerjakannya, maka kesalahan 1 milidetik hampir tidak terlihat. Selain itu, untuk metrik sistem pendukung kehidupan, kami memiliki tingkat polling dan sinkronisasi 2 detik yang cukup, namun sistem pemantauan itu sendiri harus mampu bekerja dengan tingkat polling yang sangat tinggi dan sinkronisasi metrik yang sangat presisi. - Konsumsi sumber daya minimal dan satu tumpukan.
Perangkat akhir dapat berupa kompleks terpasang yang kuat yang dapat menganalisis situasi di jalan atau melakukan perekaman biometrik orang, atau komputer papan tunggal seukuran telapak tangan yang dikenakan oleh prajurit pasukan khusus di bawah pelindung tubuhnya untuk mengirimkan video. waktu nyata dalam kondisi komunikasi yang buruk. Terlepas dari beragamnya arsitektur dan daya komputasi, kami ingin memiliki tumpukan perangkat lunak yang sama. - Arsitektur payung
Metrik harus dikumpulkan dan diagregasi pada perangkat akhir, disimpan secara lokal, dan divisualisasikan secara real time dan retrospektif. Jika ada koneksi, transfer data ke sistem pemantauan pusat. Ketika tidak ada koneksi, antrian pengiriman harus terakumulasi dan tidak memakan RAM. - API untuk integrasi ke dalam sistem pemantauan pelanggan, karena tidak ada yang membutuhkan banyak sistem pemantauan. Pelanggan harus mengumpulkan data dari perangkat dan jaringan apa pun ke dalam satu pemantauan.
Apa yang terjadi
Agar tidak membebani jangka panjang yang sudah mengesankan, saya tidak akan memberikan contoh dan pengukuran semua sistem pemantauan. Ini akan mengarah ke artikel lain. Saya hanya akan mengatakan bahwa kami tidak dapat menemukan sistem pemantauan yang mampu mengambil dua metrik secara bersamaan dengan kesalahan kurang dari 1 milidetik dan bekerja sama efektifnya pada arsitektur ARM dengan RAM 64 MB dan pada arsitektur x86_64 dengan 32 GB RAM. Oleh karena itu, kami memutuskan untuk menulis sendiri, yang dapat melakukan semua ini. Inilah yang kami dapatkan:
Meringkas throughput tiga saluran untuk topologi jaringan yang berbeda
Visualisasi beberapa metrik utama
Arsitektur
Kami menggunakan Golang sebagai bahasa pemrograman utama, baik pada perangkat maupun pada data center. Ini sangat menyederhanakan kehidupan dengan implementasi multitasking dan kemampuan untuk mendapatkan satu file biner yang dapat dieksekusi yang terhubung secara statis untuk setiap layanan. Hasilnya, kami menghemat sumber daya, metode, dan lalu lintas secara signifikan untuk menerapkan layanan ke perangkat akhir, waktu pengembangan, dan debugging kode.
Sistem ini diimplementasikan berdasarkan prinsip modular klasik dan berisi beberapa subsistem:
- Pendaftaran metrik.
Setiap metrik disajikan oleh rangkaian pesannya sendiri dan disinkronkan di seluruh saluran. Kami mampu mencapai akurasi sinkronisasi hingga 10 nanodetik. - Penyimpanan metrik
Kami memilih antara menulis penyimpanan kami sendiri untuk deret waktu atau menggunakan sesuatu yang sudah tersedia. Basis data diperlukan untuk data retrospektif yang akan divisualisasikan selanjutnya, yaitu tidak berisi data penundaan saluran setiap 0.5 milidetik atau pembacaan kesalahan di jaringan transportasi, tetapi terdapat kecepatan pada setiap antarmuka setiap 500 milidetik. Selain persyaratan lintas platform yang tinggi dan konsumsi sumber daya yang rendah, sangat penting bagi kami untuk dapat memprosesnya. data adalah tempat penyimpanannya. Ini menghemat sumber daya komputasi yang sangat besar. Kami telah menggunakan Tarantool DBMS dalam proyek ini sejak 2016 dan sejauh ini kami belum melihat penggantinya. Fleksibel, dengan konsumsi sumber daya yang optimal, dukungan teknis yang lebih dari memadai. Tarantool juga mengimplementasikan modul GIS. Tentu saja, ini tidak sekuat PostGIS, tetapi cukup untuk tugas kita menyimpan beberapa metrik terkait lokasi (relevan untuk transportasi). - Visualisasi metrik
Semuanya relatif sederhana di sini. Kami mengambil data dari gudang dan menampilkannya secara real time atau retrospektif. - Sinkronisasi data dengan sistem pemantauan pusat.
Sistem pemantauan pusat menerima data dari semua perangkat, menyimpannya dengan riwayat tertentu dan mengirimkannya ke sistem pemantauan Pelanggan melalui API. Tidak seperti sistem pemantauan klasik, di mana βkepalaβ berkeliling dan mengumpulkan data, kami memiliki skema sebaliknya. Perangkat itu sendiri mengirimkan data ketika ada koneksi. Ini adalah poin yang sangat penting, karena memungkinkan Anda menerima data dari perangkat untuk periode waktu yang tidak tersedia dan tidak memuat saluran dan sumber daya saat perangkat tidak tersedia. Kami menggunakan server pemantauan Influx sebagai sistem pemantauan pusat. Tidak seperti analognya, ia dapat mengimpor data retrospektif (yaitu, dengan stempel waktu yang berbeda dari saat metrik diterima). Metrik yang dikumpulkan divisualisasikan oleh Grafana, dimodifikasi dengan sebuah file. Tumpukan standar ini juga dipilih karena memiliki integrasi API siap pakai dengan hampir semua sistem pemantauan pelanggan. - Sinkronisasi data dengan sistem manajemen perangkat pusat.
Sistem manajemen perangkat menerapkan Zero Touch Provisioning (memperbarui firmware, konfigurasi, dll.) dan, tidak seperti sistem pemantauan, hanya menerima masalah per perangkat. Ini adalah pemicu pengoperasian layanan pengawas perangkat keras terpasang dan semua metrik sistem pendukung kehidupan: suhu CPU dan SSD, beban CPU, ruang kosong, dan kesehatan SMART pada disk. Penyimpanan subsistem juga dibangun di Tarantool. Hal ini memberi kami kecepatan yang signifikan dalam menggabungkan rangkaian waktu di ribuan perangkat, dan juga menyelesaikan sepenuhnya masalah sinkronisasi data dengan perangkat tersebut. Tarantool memiliki sistem antrian yang sangat baik dan pengiriman yang terjamin. Kami sudah mengeluarkan fitur penting ini, bagus!
Sistem manajemen jaringan
Apa Selanjutnya
Sejauh ini, mata rantai terlemah kami adalah sistem pemantauan pusat. Ini diimplementasikan 99.9% pada tumpukan standar dan memiliki sejumlah kelemahan:
- InfluxDB kehilangan data ketika listrik padam. Sebagai aturan, Pelanggan segera mengumpulkan segala sesuatu yang berasal dari perangkat dan database itu sendiri tidak berisi data yang lebih lama dari 5 menit, tetapi di masa depan hal ini mungkin menyusahkan.
- Grafana memiliki sejumlah masalah dengan agregasi data dan sinkronisasi tampilannya. Masalah paling umum adalah ketika database berisi rangkaian waktu dengan interval 2 detik dimulai dari, katakanlah, 00:00:00, dan Grafana mulai menampilkan data dalam agregasi dari +1 detik. Hasilnya, pengguna melihat grafik menari.
- Jumlah kode yang berlebihan untuk integrasi API dengan sistem pemantauan pihak ketiga. Itu bisa dibuat lebih ringkas dan tentu saja ditulis ulang di Go)
Saya pikir Anda semua telah melihat dengan sempurna seperti apa Grafana dan mengetahui masalahnya tanpa saya, jadi saya tidak akan membebani postingan dengan gambar.
Kesimpulan
Sengaja saya tidak menjelaskan detail teknisnya, namun hanya menjelaskan desain dasar sistem ini. Pertama, untuk mendeskripsikan sistem secara teknis, diperlukan artikel lain. Kedua, tidak semua orang tertarik dengan hal ini. Tulis di komentar detail teknis apa yang ingin Anda ketahui.
Jika ada yang memiliki pertanyaan di luar cakupan artikel ini, Anda dapat menulis kepada saya di [email protected]
Sumber: www.habr.com