16 ta modem, 4 ta uyali aloqa operatori = Chiqish tezligi 933.45 Mbit/s
kirish
Salom! Ushbu maqola o'zimiz uchun yangi monitoring tizimini qanday yozganimiz haqida. U yuqori chastotali sinxron ko'rsatkichlarni olish qobiliyati va juda kam resurs iste'moli bilan mavjudlaridan farq qiladi. Ovoz berish tezligi 0.1 nanosekundlik ko'rsatkichlar orasidagi sinxronizatsiya aniqligi bilan 10 millisekundga yetishi mumkin. Barcha ikkilik fayllar 6 megabaytni egallaydi.
Loyiha haqida
Bizda juda aniq mahsulot bor. Biz ma'lumotlar uzatish kanallarining o'tkazuvchanligi va xatolarga chidamliligini umumlashtirish uchun keng qamrovli yechim ishlab chiqaramiz. Bu bir nechta kanallar mavjud bo'lganda, aytaylik Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Yana bir narsa (5 Mbit/s), natijada bitta barqaror va tez kanal, tezligi shunga o'xshash bo'ladi. bu: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Bunday echimlar har qanday kanalning sig'imi etarli bo'lmagan hollarda talab qilinadi. Masalan, transport, videokuzatuv tizimlari va real vaqt rejimida video striming, jonli teleko'rsatuvlar va radioeshittirishlar, telekommunikatsiya operatorlari orasida faqat "Katta to'rtlik" vakillari bo'lgan va bitta modem/kanaldagi tezlik etarli bo'lmagan har qanday shahar atrofi ob'ektlari. .
Ushbu sohalarning har biri uchun biz qurilmalarning alohida qatorini ishlab chiqaramiz, ammo ularning dasturiy qismi deyarli bir xil va yuqori sifatli monitoring tizimi uning asosiy modullaridan biri bo'lib, uni to'g'ri amalga oshirmasdan mahsulotni ishlab chiqarish mumkin emas.
Bir necha yil davomida biz ko'p darajali, tezkor, o'zaro platformali va engil monitoring tizimini yaratishga muvaffaq bo'ldik. Buni biz hurmatli hamjamiyatimiz bilan baham ko'rmoqchimiz.
Muammoni shakllantirish
Monitoring tizimi bir-biridan farq qiluvchi ikkita sinf ko'rsatkichlarini taqdim etadi: real vaqt ko'rsatkichlari va boshqalar. Monitoring tizimi faqat quyidagi talablarga ega edi:
- Haqiqiy vaqtda ko'rsatkichlarni yuqori chastotali sinxron ravishda olish va ularni aloqani boshqarish tizimiga kechiktirmasdan o'tkazish.
Turli ko'rsatkichlarning yuqori chastotasi va sinxronizatsiyasi nafaqat muhim, balki ma'lumotlarni uzatish kanallarining entropiyasini tahlil qilish uchun juda muhimdir. Agar bitta ma'lumot uzatish kanalida o'rtacha kechikish 30 millisekundni tashkil qilsa, qolgan bir millisekundlik ko'rsatkichlar o'rtasidagi sinxronizatsiya xatosi hosil bo'lgan kanal tezligining taxminan 5% ga pasayishiga olib keladi. Agar biz 1 ta kanal bo'ylab vaqtni 4 millisekundga noto'g'ri qo'ysak, tezlikning pasayishi osongina 30% gacha tushishi mumkin. Bundan tashqari, kanallardagi entropiya juda tez o'zgaradi, shuning uchun agar biz uni har 0.5 millisekundda bir martadan kamroq o'lchasak, kichik kechikish bilan tez kanallarda biz yuqori tezlikdagi buzilishlarni olamiz. Albatta, bunday aniqlik barcha ko'rsatkichlar uchun kerak emas va barcha sharoitlarda emas. Kanaldagi kechikish 500 millisekund bo'lsa va biz ular bilan ishlasak, 1 millisekundlik xato deyarli sezilmaydi. Bundan tashqari, hayotni qo'llab-quvvatlash tizimi ko'rsatkichlari uchun bizda 2 soniyalik so'rov va sinxronizatsiya tezligi etarli, ammo monitoring tizimining o'zi o'ta yuqori so'rov stavkalari va o'lchovlarning o'ta aniq sinxronizatsiyasi bilan ishlay olishi kerak. - Minimal resurs iste'moli va bitta stek.
Yakuniy qurilma yo'ldagi vaziyatni tahlil qila oladigan yoki odamlarning biometrik qaydini o'tkaza oladigan kuchli bort majmuasi yoki maxsus kuchlar askari videoni uzatish uchun zirh ostida kiyadigan kaft o'lchamli bir bortli kompyuter bo'lishi mumkin. yomon aloqa sharoitida real vaqt. Turli xil arxitektura va hisoblash quvvatiga qaramay, biz bir xil dasturiy ta'minot to'plamiga ega bo'lishni xohlaymiz. - Soyabon arxitekturasi
Ko'rsatkichlar oxirgi qurilmada to'planishi va jamlanishi, mahalliy saqlanishi va real vaqtda va retrospektiv tarzda ko'rsatilishi kerak. Agar ulanish mavjud bo'lsa, ma'lumotlarni markaziy monitoring tizimiga o'tkazing. Ulanish bo'lmaganda, yuborish navbati to'planishi va RAMni iste'mol qilmasligi kerak. - Mijozning monitoring tizimiga integratsiya qilish uchun API, chunki hech kimga ko'p monitoring tizimlari kerak emas. Mijoz har qanday qurilma va tarmoqlardan ma'lumotlarni bitta monitoringda to'plashi kerak.
Nima bo'ldi
Ta'sirchan uzoq o'qishni og'irlashtirmaslik uchun men barcha monitoring tizimlarining misollari va o'lchovlarini keltirmayman. Bu boshqa maqolaga olib keladi. Aytmoqchimanki, biz bir vaqtning o‘zida 1 millisekunddan kam xatolik bilan ikkita ko‘rsatkichni olishga qodir bo‘lgan va 64 MB operativ xotiraga ega ARM arxitekturasida ham, 86 ga teng x64_32 arxitekturasida ham birdek samarali ishlaydigan monitoring tizimini topa olmadik. GB RAM. Shuning uchun biz bularning barchasini qila oladigan o'zimizni yozishga qaror qildik. Mana bizda nima bor:
Turli xil tarmoq topologiyalari uchun uchta kanalning o'tkazuvchanligini sarhisob qilish
Ba'zi asosiy ko'rsatkichlarning vizualizatsiyasi
arxitektura
Biz Golang tilidan qurilmada ham, maʼlumotlar markazida ham asosiy dasturlash tili sifatida foydalanamiz. U ko'p vazifalarni amalga oshirish va har bir xizmat uchun bitta statik bog'langan bajariladigan ikkilik faylni olish qobiliyati bilan hayotni sezilarli darajada soddalashtirdi. Natijada, xizmatni oxirgi qurilmalarga joylashtirish, ishlab chiqish vaqti va kodni tuzatish uchun resurslar, usullar va trafikni sezilarli darajada tejaymiz.
Tizim klassik modul printsipiga muvofiq amalga oshiriladi va bir nechta quyi tizimlarni o'z ichiga oladi:
- Ko'rsatkichlarni ro'yxatdan o'tkazish.
Har bir ko'rsatkich o'z oqimi orqali xizmat qiladi va kanallar bo'ylab sinxronlashtiriladi. Biz 10 nanosoniyagacha sinxronizatsiya aniqligiga erisha oldik. - Ko'rsatkichlarni saqlash
Vaqt seriyalari uchun o'z xotiramizni yozish yoki allaqachon mavjud bo'lgan narsadan foydalanishni tanladik. Ma'lumotlar bazasi keyinchalik vizualizatsiya qilinadigan retrospektiv ma'lumotlar uchun kerak.Ya'ni, u kanaldagi har 0.5 millisekundda kechikishlar yoki transport tarmog'idagi xato ko'rsatkichlari haqidagi ma'lumotlarni o'z ichiga olmaydi, lekin har bir interfeysda har 500 millisekundda tezlik mavjud. O'zaro platformalar va kam resurs iste'moli uchun yuqori talablarga qo'shimcha ravishda, biz qayta ishlash imkoniyatiga ega bo'lishimiz juda muhimdir. ma'lumotlar saqlanadigan joydir. Bu katta hisoblash resurslarini tejaydi. Biz ushbu loyihada Tarantool DBMS dan 2016 yildan beri foydalanmoqdamiz va hozirgacha ufqda uning o'rnini ko'rmayapmiz. Moslashuvchan, optimal resurslar iste'moli bilan, etarli texnik yordamdan ko'ra ko'proq. Tarantool shuningdek, GIS modulini ham amalga oshiradi. Albatta, bu PostGIS kabi kuchli emas, lekin bu bizning joylashuvga oid ba'zi ko'rsatkichlarni (transport uchun tegishli) saqlash vazifalarimiz uchun etarli. - Ko'rsatkichlarning vizualizatsiyasi
Bu erda hamma narsa nisbatan sodda. Biz ombordan ma'lumotlarni olamiz va uni real vaqtda yoki retrospektiv tarzda namoyish qilamiz. - Ma'lumotlarni markaziy monitoring tizimi bilan sinxronlashtirish.
Markaziy monitoring tizimi barcha qurilmalardan ma'lumotlarni oladi, ma'lum bir tarix bilan saqlaydi va API orqali mijozning monitoring tizimiga yuboradi. Klassik monitoring tizimlaridan farqli o'laroq, "bosh" aylanib yuradi va ma'lumotlarni to'playdi, bizda teskari sxema mavjud. Ulanish mavjud bo'lganda qurilmalarning o'zi ma'lumotlarni yuboradi. Bu juda muhim nuqta, chunki u mavjud bo'lmagan vaqt davomida qurilmadan ma'lumot olish va qurilma mavjud bo'lmaganda kanallar va resurslarni yuklamaslik imkonini beradi. Biz Influx monitoring serveridan markaziy monitoring tizimi sifatida foydalanamiz. Analoglaridan farqli o'laroq, u retrospektiv ma'lumotlarni import qilishi mumkin (ya'ni, ko'rsatkichlar olingan paytdan farqli vaqt belgisi bilan).To'plangan ko'rsatkichlar Grafana tomonidan tasvirlangan, fayl bilan o'zgartirilgan. Ushbu standart stek ham deyarli har qanday mijoz monitoringi tizimi bilan tayyor API integratsiyasiga ega bo'lgani uchun tanlangan. - Markaziy qurilmalarni boshqarish tizimi bilan ma'lumotlarni sinxronlashtirish.
Qurilmani boshqarish tizimi Zero Touch Provisioningni (proshivka, konfiguratsiyani yangilash va h.k.) amalga oshiradi va monitoring tizimidan farqli o'laroq, har bir qurilmada faqat muammolarni qabul qiladi. Bular bort apparat nazorati xizmatlarining ishlashi va hayotni qo'llab-quvvatlash tizimlarining barcha ko'rsatkichlari uchun triggerlar: protsessor va SSD harorati, protsessor yuki, bo'sh joy va disklardagi SMART salomatligi. Quyi tizim xotirasi ham Tarantool-da qurilgan. Bu bizga minglab qurilmalarda vaqt seriyasini yig'ishda sezilarli tezlikni beradi, shuningdek, ushbu qurilmalar bilan ma'lumotlarni sinxronlashtirish masalasini to'liq hal qiladi. Tarantool ajoyib navbat va kafolatli yetkazib berish tizimiga ega. Biz ushbu muhim xususiyatni qutidan oldik, ajoyib!
Tarmoqni boshqarish tizimi
Keyin nima
Hozircha bizning eng zaif bo'g'inimiz markaziy monitoring tizimidir. U standart stekda 99.9% amalga oshiriladi va bir qator kamchiliklarga ega:
- Quvvat uzilganda InfluxDB ma'lumotlarni yo'qotadi. Qoidaga ko'ra, Mijoz qurilmalardan kelgan hamma narsani zudlik bilan to'playdi va ma'lumotlar bazasining o'zi 5 daqiqadan eski ma'lumotlarni o'z ichiga olmaydi, ammo kelajakda bu og'riqli bo'lishi mumkin.
- Grafana-da ma'lumotlarni yig'ish va displeyni sinxronlashtirishda bir qator muammolar mavjud. Eng keng tarqalgan muammo shundaki, ma'lumotlar bazasida, masalan, 2:00:00 dan boshlanadigan 00 soniya intervalli vaqt seriyasi mavjud bo'lsa va Grafana +1 soniyadan boshlab ma'lumotlarni yig'ishda ko'rsata boshlaydi. Natijada, foydalanuvchi raqsga tushadigan grafikni ko'radi.
- Uchinchi tomon monitoring tizimlari bilan API integratsiyasi uchun ortiqcha kod miqdori. Uni ancha ixcham qilish mumkin va, albatta, Go-da qayta yoziladi)
O'ylaymanki, barchangiz Grafana qanday ko'rinishini juda yaxshi ko'rgansiz va mensiz uning muammolarini bilasiz, shuning uchun postni rasmlar bilan ortiqcha yuklamayman.
xulosa
Men atayin texnik tafsilotlarni tasvirlamadim, lekin faqat ushbu tizimning asosiy dizaynini tasvirlab berdim. Birinchidan, tizimni texnik jihatdan to'liq tavsiflash uchun yana bir maqola kerak bo'ladi. Ikkinchidan, hamma ham bunga qiziqmaydi. Izohlarda qanday texnik tafsilotlarni bilmoqchi ekanligingizni yozing.
Agar kimdirda ushbu maqola doirasidan tashqarida savollar bo'lsa, menga a.rodin @ qedr.com manziliga yozishingiz mumkin.
Manba: www.habr.com