Penjumlahan kecepatan pada 16 modem dari 4 operator seluler. Kecepatan keluar dalam satu aliran - 933,45 Mbps
Pendahuluan
Hai Artikel ini adalah tentang bagaimana kami menulis sistem pemantauan baru untuk diri kami sendiri. Ini berbeda dari yang ada oleh kemungkinan akuisisi sinkron frekuensi tinggi metrik dan konsumsi sumber daya yang sangat rendah. Frekuensi jajak pendapat dapat mencapai 0,1 milidetik dengan akurasi sinkronisasi antara metrik 10 nanodetik. Semua file biner menempati 6 megabita.
Tentang proyek
Kami memiliki produk yang agak spesifik. Kami menghasilkan solusi komprehensif untuk merangkum throughput dan toleransi kesalahan saluran data. Ini adalah ketika ada beberapa saluran, misalnya, Operator1 (40Mbit / s) + Operator2 (30Mbit / s) + Sesuatu yang lain (5 Mbit / s), hasilnya adalah satu saluran yang stabil dan cepat, kecepatannya akan seperti ini: (40+ 30 + 5) x0.92 = 75x0.92 = 69 Mbps.
Solusi semacam itu diminati di mana kapasitas setiap saluran tidak mencukupi. Misalnya, transportasi, pengawasan video waktu-nyata dan sistem streaming video, siaran langsung televisi dan radio, benda luar kota di mana operator telekomunikasi hanya memiliki perwakilan Big Four, dan kecepatan pada satu modem / saluran tidak cukup.
Untuk masing-masing bidang ini, kami memproduksi garis perangkat yang terpisah, namun, bagian perangkat lunaknya hampir sama dan sistem pemantauan berkualitas tinggi adalah salah satu modul utamanya, tanpa implementasi yang benar di mana produk tidak akan mungkin.
Selama beberapa tahun, kami telah berhasil menciptakan sistem pemantauan cepat, lintas platform, dan ringan multi-level. Apa yang ingin kami bagikan dengan komunitas yang memiliki reputasi baik.
Pernyataan masalah
Sistem pemantauan menyediakan metrik untuk dua kelas yang berbeda secara mendasar: metrik waktu-nyata dan yang lainnya. Sistem pemantauan memiliki persyaratan sebagai berikut:
- Akuisisi sinkron frekuensi tinggi dari metrik waktu-nyata dan transfernya ke sistem kontrol komunikasi tanpa penundaan.
Frekuensi tinggi dan sinkronisasi metrik yang berbeda tidak hanya penting, sangat penting untuk analisis entropi saluran transmisi data. Jika ada penundaan rata-rata 30 milidetik dalam satu saluran data, maka kesalahan dalam sinkronisasi antara metrik yang tersisa dengan hanya satu milidetik akan menyebabkan penurunan kecepatan saluran yang dihasilkan sekitar 5%. Jika kita melakukan kesalahan dalam sinkronisasi selama 1 milidetik dalam 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 degradasi kecepatan tinggi. Tentu saja, akurasi tersebut tidak diperlukan untuk semua metrik dan tidak dalam semua kondisi. Ketika penundaan dalam saluran adalah 500 milidetik, dan kami bekerja dengan itu, kesalahan 1 milidetik hampir tidak akan terlihat. Juga, untuk metrik sistem pendukung kehidupan, frekuensi pemungutan suara dan sinkronisasi 2 detik sudah cukup bagi kami, namun, sistem pemantauan itu sendiri harus dapat bekerja dengan frekuensi pemungutan suara sangat tinggi dan sinkronisasi metrik sangat presisi. - Konsumsi sumber daya minimal dan satu tumpukan.
Perangkat terakhir dapat menjadi kompleks on-board yang kuat yang dapat menganalisis situasi di jalan atau merekam biometrik orang, atau komputer seukuran papan tunggal yang dikenakan oleh tentara pasukan khusus di bawah pelindung tubuh untuk mengirimkan video real-time dalam kondisi komunikasi yang buruk. Meskipun terdapat beragam arsitektur dan daya komputasi, kami ingin memiliki tumpukan perangkat lunak yang sama. - Arsitektur payung
Metrik harus dikumpulkan dan dikumpulkan pada perangkat akhir, memiliki sistem penyimpanan lokal dan visualisasi secara real time dan retrospektif. Jika komunikasi tersedia, transfer data ke sistem pemantauan pusat. Ketika tidak ada koneksi, antrian pengiriman harus menumpuk dan tidak mengkonsumsi RAM. - API untuk diintegrasikan ke dalam sistem pemantauan pelanggan, karena tidak ada yang membutuhkan banyak sistem pemantauan. Pelanggan harus mengumpulkan data dari perangkat dan jaringan apa pun dalam satu pemantauan.
Apa yang terjadi
Untuk memuat longrid yang sudah mengesankan, saya tidak akan memberikan contoh dan pengukuran semua sistem pemantauan. Ini akan menarik 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 yang berfungsi sama efisiennya pada arsitektur ARM dengan 64 MB RAM dan arsitektur x86_64 dengan 32 GB RAM. Karena itu, kami memutuskan untuk menulis sendiri, yang dapat melakukan hal itu. Inilah yang kami dapatkan:
Menjumlahkan throughput tiga saluran untuk topologi jaringan yang berbeda
Visualisasi beberapa metrik kunci
Arsitektur
Sebagai bahasa pemrograman utama, baik di perangkat maupun di pusat data, kami menggunakan Golang. Dia sangat menyederhanakan hidupnya dengan menerapkan multitasking dan kemampuan untuk mendapatkan satu biner yang dapat dieksekusi yang terhubung secara statis untuk setiap layanan. Akibatnya, kami secara signifikan menghemat sumber daya, metode, dan lalu lintas penyebaran layanan ke perangkat akhir, waktu pengembangan, dan debugging kode.
Sistem ini diimplementasikan sesuai dengan prinsip modular klasik dan berisi beberapa subsistem:
- Registrasi metrik.
Setiap metrik dilayani oleh alirannya sendiri dan disinkronkan melalui saluran. Kami berhasil mendapatkan akurasi sinkronisasi hingga 10 nanodetik. - Penyimpanan metrik
Kami memilih antara menulis repositori kami untuk deret waktu atau menggunakan salah satu dari yang tersedia. Basis data diperlukan untuk data retrospektif, yang akan dikenakan visualisasi berikutnya, yaitu tidak memiliki data keterlambatan dalam saluran setiap 0,5 milidetik atau indikasi kesalahan dalam jaringan transportasi, tetapi ada kecepatan pada setiap antarmuka setiap 500 milidetik. Selain persyaratan tinggi untuk lintas platform dan konsumsi sumber daya yang rendah, sangat penting bagi kami untuk dapat memproses. data di tempat yang sama di mana ia disimpan. Ini sangat menghemat sumber daya komputasi. Sejak 2016, kami telah menggunakan Tarantool DBMS dalam proyek ini dan sejauh ini kami tidak melihat penggantinya di cakrawala. Fleksibel, dengan konsumsi sumber daya yang optimal, lebih dari cukup dukungan teknis. Tarantool juga memiliki modul GIS. Ini tentu saja tidak sekuat PostGIS, tetapi cukup untuk tugas kita menyimpan beberapa metrik yang terkait dengan lokasi (relevan untuk transportasi). - Visualisasi Metrik
Semuanya relatif sederhana di sini. Kami mengambil data dari penyimpanan dan menunjukkannya secara real time atau retrospektif. - Sinkronisasi data dengan sistem pemantauan pusat.
Sistem pemantauan pusat menerima data dari semua perangkat, menyimpannya dengan retrospektif yang diberikan, dan mengirimkannya melalui API ke sistem pemantauan Pelanggan. Tidak seperti sistem pemantauan klasik, di mana "kepala" berjalan dan mengumpulkan data - kami memiliki skema sebaliknya. Perangkat itu sendiri mengirim data ketika ada koneksi. Ini adalah poin yang sangat penting, karena memungkinkan Anda untuk menerima data dari perangkat untuk periode waktu di mana itu tidak tersedia dan tidak memuat saluran dan sumber daya saat perangkat tidak tersedia. Sebagai sistem pemantauan pusat, kami menggunakan server pemantauan Influx. Tidak seperti analog, ini dapat mengimpor data retrospektif (yaitu, dengan cap waktu yang berbeda dari saat metrik diterima) Metrik yang dikumpulkan divisualisasikan oleh file Grafana yang dimodifikasi. Tumpukan standar ini juga dipilih karena memiliki API integrasi siap pakai dengan hampir semua sistem pemantauan pelanggan. - Sinkronisasi data dengan sistem manajemen perangkat pusat.
Sistem manajemen perangkat mengimplementasikan Zero Touch Provisioning (memperbarui firmware, konfigurasi, dll.) Dan, tidak seperti sistem pemantauan, hanya menerima masalah perangkat. Ini adalah pemicu dari layanan pengawas perangkat keras onboard dan semua metrik sistem pendukung kehidupan: CPU dan suhu SSD, beban CPU, ruang bebas dan kesehatan SMART pada disk. Penyimpanan subsistem juga dibangun di atas Tarantool. Ini memberi kita kecepatan yang signifikan dalam agregasi seri waktu di ribuan perangkat, dan juga sepenuhnya menyelesaikan masalah sinkronisasi data dengan perangkat ini. Tarantool memiliki sistem antrian yang sangat baik dan pengiriman yang terjamin. Kami punya fitur penting ini di luar kotak, hebat!
Sistem manajemen jaringan
Apa selanjutnya
Sejauh ini, mata rantai terlemah di negara kita adalah sistem pemantauan pusat. Diimplementasikan pada 99,9% pada stack standar dan memiliki sejumlah kelemahan:
- InfluxDB kehilangan data saat daya dimatikan. Sebagai aturan, Pelanggan segera mengambil semua yang datang dari perangkat dan tidak ada data yang lebih lama dari 5 menit dalam database itu sendiri, tetapi di masa depan hal ini dapat menyebalkan.
- Grafana memiliki sejumlah masalah dengan agregasi data dan sinkronisasi tampilan mereka. Masalah yang paling umum adalah ketika database berisi deret waktu dengan interval 2 detik mulai dari, katakanlah, 00:00:00, dan Grafana mulai menampilkan data dalam agregasi dari +1 detik. Akibatnya, pengguna melihat grafik menari.
- Kode kelebihan untuk integrasi API dengan sistem pemantauan pihak ketiga. Dapat dibuat jauh lebih ringkas dan tentu saja menulis ulang untuk Go)
Saya kira Anda semua benar-benar melihat seperti apa Grafana dan tanpa saya Anda tahu masalahnya, karena itu saya tidak akan membebani pos dengan gambar.
Kesimpulan
Saya sengaja tidak menjelaskan detail teknis, tetapi hanya mendeskripsikan desain pendukung sistem ini. Pertama, untuk mendeskripsikan sistem secara teknis, diperlukan satu artikel lagi. Kedua, tidak semua orang akan tertarik. Tulis di komentar detail teknis apa yang ingin Anda ketahui.
Jika ada yang memiliki pertanyaan di luar artikel ini, saya dapat menulis ke a.rodin @ qedr.com