16 modema, 4 operatorë celularë = Shpejtësia e daljes 933.45 Mbit/s
Hyrje
Përshëndetje! Ky është një artikull për atë se si ne shkruam një sistem të ri monitorimi për veten tonë. Ai dallon nga ekzistuesit me mundësinë e marrjes sinkrone të metrikeve në frekuenca shumë të larta dhe me një konsum shumë të ulët të burimeve. Frekuenca e pyetjeve mund të arrijë deri në 0.1 milisekonda me saktësi sinkronizimi midis metrikeve në 10 nanosekonda. Të gjitha skedarët binarë zënë 6 megabajt.
PĂ«r projektin
Ne kemi njĂ« produkt mjaft specifik. Ne prodhojmĂ« njĂ« zgjidhje komplekse pĂ«r pĂ«rmbledhjen e kapacitetit dhe qĂ«ndrueshmĂ«risĂ« sĂ« kanaleve tĂ« transmetimit tĂ« tĂ« dhĂ«nave. Kjo ndodh kur ka disa kanale, le tĂ« themi Operator1 (40 Mbit/s) + Operator2 (30 Mbit/s) + Diçka tjetĂ«r (5 Mbit/s), rezultati Ă«shtĂ« njĂ« kanal stabil dhe tĂ« shpejtĂ«, shpejtĂ«sia e tĂ« cilit do tĂ« jetĂ« pĂ«rafĂ«rsisht kĂ«shtu: (40+30+5)x0.92=75Ă0.92=69 Mbit/s.
Këto zgjidhje janë të nevojshme atje ku kapaciteti i çdo kanali të vetëm është i pamjaftueshëm. Për shembull, transporti, sistemet e video-monitorimit dhe transmetimit të videos në kohë reale, transmetimi i drejtpërdrejtë të programeve televizive dhe radiofonike, çdo objekt jashtë qytetit ku opsionet e operatorëve të komunikimit janë vetëm përfaqësues të katërshes së madhe dhe shpejtësia në një modem/kanal është e pamjaftueshme.
PĂ«r secilĂ«n nga kĂ«to drejtime, ne nxjerrim njĂ« linjĂ« tĂ« veçantĂ« pajisjesh, megjithatĂ« pjesa e tyre software Ă«shtĂ« pothuajse identike dhe njĂ« sistem i cilĂ«sisĂ« monitorimi â Ă«shtĂ« njĂ« nga modulet kryesore, pa implementimin e duhur tĂ« cilit produkti do tĂ« ishte i pamundur.
Në disa vjet, ne arritëm të krijojmë një sistem monitorimi me shumë nivele, me shpejtësi, multplatformë dhe të lehtë. Këtë dëshirojmë të ndajmë me komunitetin e nderuar.
Vendosja e detyrës
Sistemi i monitorimit siguron marrjen e metrikeve të dy klasave fundamentalisht të ndryshme: metrike të kohës reale dhe të gjitha të tjera. Sistemi i monitorimit kishte vetëm këto kërkesa:
- Marrje sinchronike me frekuencë të lartë të metrikeve të kohës reale dhe transmetimi i tyre në sistemin e menaxhimit të komunikimit pa vonesa.
Frekuenca e lartĂ« dhe sinkronizimi i metrikeve tĂ« ndryshme â jo vetĂ«m qĂ« Ă«shtĂ« i rĂ«ndĂ«sishĂ«m, por Ă«shtĂ« jetĂ«sor pĂ«r analizĂ«n e entropic tĂ« kanaleve tĂ« transmetimit tĂ« tĂ« dhĂ«nave. NĂ«se nĂ« njĂ« kanal transmetimi, vonesa mesatare Ă«shtĂ« 30 milisekonda, njĂ« gabim nĂ« sinkronizim midis metrikeve tĂ« tjera prej vetĂ«m njĂ« milisekonde do tĂ« sjellĂ« njĂ« degradim tĂ« shpejtĂ«sisĂ« sĂ« kanalit pĂ«rkatĂ«s rreth 5%. NĂ«se ne gabojmĂ« nĂ« sinkronizim me 1 milisekondĂ« nĂ« 4 kanale, degradimi i shpejtĂ«sisĂ« mund tĂ« bjerĂ« lehtĂ«sisht deri nĂ« 30%. PĂ«rveç kĂ«saj, entropia nĂ« kanale ndryshon shumĂ« shpejt, prandaj nĂ«se e masim atĂ« mĂ« rrallĂ« se njĂ« herĂ« nĂ« 0.5 milisekonda, nĂ« kanalet e shpejta me vonesĂ« tĂ« vogĂ«l, do tĂ« pĂ«rfitojmĂ« njĂ« degradim tĂ« lartĂ« tĂ« shpejtĂ«sisĂ«. Natyrisht, kjo saktĂ«si nuk Ă«shtĂ« e nevojshme pĂ«r tĂ« gjitha metrikat dhe jo nĂ« tĂ« gjitha kushtet. Kur vonesa nĂ« kanal Ă«shtĂ« 500 milisekonda, dhe ne punojmĂ« me tĂ« tilla, gabimi prej 1 milisekondĂ« nuk do tĂ« duket. Gjithashtu, pĂ«r metrikat e sistemeve tĂ« mbĂ«shtetjes sĂ« jetĂ«s, na mjafton frekuenca e pyetjes dhe sinkronizimi nĂ« 2 sekonda, megjithatĂ«, vetĂ« sistemi i monitorimit duhet tĂ« jetĂ« nĂ« gjendje tĂ« punojĂ« me frekuenca tĂ« jashtĂ«zakonshme tĂ« pyetjes dhe sinkronizim tĂ« jashtĂ«zakonshĂ«m tĂ« metrikeve. - Konsumimi minimal i burimeve dhe njĂ« arkitekturĂ« tĂ« unifikuar.
Krahu përfundimtar mund të paraqesë si një kompleks të fuqishëm bord, që mund të analizoje situatën në rrugë ose të kryejë regjistrimin biometrik të individëve, ashtu edhe një kompjuter me një kartë të vetme në madhësinë e pëllëmbës, që mbështetet nën një jelek mbrojtës nga një ushtar elitar për të transmetuar video në kohë reale në kushte të lidhjes të dobët. Pavarësisht nga kjo larmi arkitekturash dhe fuqish përpunimi, ne dëshirojmë të kemi të njëjtin stek softuerik. - Arkitektura e çadrës
Metrikat duhet tĂ« mblidhen dhe tĂ« agregohen nĂ« pajisjen pĂ«rfundimtare, tĂ« kenĂ« njĂ« sistem lokal ruajtjeje dhe vizualizimi nĂ« kohĂ« reale dhe retrospektivisht. NĂ« rast se ka lidhje â tĂ« dĂ«rgojnĂ« tĂ« dhĂ«nat nĂ« sistemin qendror tĂ« monitorimit. Kur nuk ka lidhje â radhĂ«t pĂ«r dĂ«rgim duhet tĂ« grumbullohen dhe tĂ« mos konsumojnĂ« memorie operative. - API pĂ«r integrimin nĂ« sistemin e monitorimit tĂ« klientit, sepse askujt nuk i nevojiten shumĂ« sisteme monitorimi. Klienti duhet tĂ« mbledhĂ« tĂ« dhĂ«na nga çdo pajisje dhe rrjet nĂ« njĂ« monitorim tĂ« vetĂ«m.
ĂfarĂ« rezultati u arrit
Për të mos e ngarkuar më tej këtë artikull të gjatë, nuk do të jap shembuj dhe matje të të gjithë sistemeve të monitorimit. Kjo do të sillte një artikull tjetër. Thjesht do të them se nuk arritëm të gjejmë një sistem monitorimi që mund të marrë dy metrika në të njëjtën kohë me një saktësi më të vogël se 1 milisekondë dhe që punon njësoj efikas si në arkitekturën ARM me 64MB RAM ashtu edhe në arkitekturën x86_64 me 32GB RAM. Prandaj, vendosëm të shkruajmë tonin, i cili di të bëjë gjithçka këtë. Ja çfarë arritëm:
Shumimi i kapacitetit të tre kanaleve për topologji të ndryshme rrjeti
Vizualizimi i disa metrikave kyçe
Arkitektura
Si gjuhĂ«n kryesore tĂ« programimit, si nĂ« pajisje ashtu edhe nĂ« QendrĂ«n e tĂ« DhĂ«nave, ne pĂ«rdorim Golang. Ai e ka thjeshtuar ndjeshĂ«m jetĂ«n me implementimin e tij tĂ« ĐŒĐœĐŸĐłĐŸĐ·Đ°ĐŽĐ°ŃĐœĐŸŃŃĐž dhe mundĂ«sinĂ« pĂ«r tĂ« marrĂ« njĂ« skedar ekzekutiv tĂ« lidhur statikisht pĂ«r çdo shĂ«rbim. Si rezultat, ne kursejmĂ« ndjeshĂ«m nĂ« burime, metoda dhe trafik pĂ«r deploymentin e shĂ«rbimeve nĂ« pajisjet fundore, si dhe kohĂ«n e zhvillimit dhe debugs e kodit.
Sistemi është realizuar në bazë të parimit të modulit klasik dhe përmban disa nën-sisteme:
- Regjistrimi i metricave.
Secila metrikë shërbehet nga një rrjedhë e vetme dhe sinkronizohet përmes kanaleve. Na ka arritur të sigurojmë një saktësi sinkronizimi deri në 10 nanosekonda. - Ruajtja e metricave
Ne pohoqim mes të shkruajmë një depo të vetën për seritë e përkohshme ose të përdorim diçka nga ato që ekzistojnë. Një bazë të dhënash nevojitet për të dhënat retrospektive që pritet të vizualizohen më pas. Domethënë, aty nuk ka të dhëna për vonesat në kanale çdo 0.5 milisekonda ose për leximet e gabimeve në rrjetin e transportit, por ka shpejtësinë në çdo ndërfaqe çdo 500 milisekonda. Përveç kërkesave të larta për ndërplatformësi dhe konsumin e ulët të burimeve, na është shumë e rëndësishme të kemi mundësinë për të përpunuar të dhënat aty ku ato ruhen. Kjo kursen masivisht burimet kompjuterike. Që nga viti 2016, ne përdorim DBMS Tarantool në këtë projekt dhe deri tani nuk shohim asnjë zëvendësim në horizont. Fleksibël, me një konsum optimal të burimeve dhe mbështetje teknike më se të kënaqshme. Në Tarantool është implementuar gjithashtu moduli GIS. Sigurisht, ai nuk është aq i fuqishëm sa PostGIS, por është mjaft për ne për ruajtjen e disa metrikeve të lidhura me lokacionin (qartësisht e rëndësishme për transportin). - Vizualizimi i metrikeve
Këtu gjithçka është relativisht e thjeshtë. Merret të dhënat nga depoja dhe ato shfaqen ose në kohë reale ose retrospektivisht. - Sinkronizimi i të dhënave me sistemin qendror të monitorimit.
Sistemi qendror i monitorimit pranon tĂ« dhĂ«nat nga tĂ« gjitha pajisjet, i ruan ato me njĂ« retrospektivĂ« tĂ« caktuar dhe pĂ«rmes API-sĂ« i dĂ«rgon ato nĂ« sistemin e monitorimit tĂ« Klientit. Ndryshe nga sistemet klasike tĂ« monitorimit, ku "koka" shkon dhe mbledh tĂ« dhĂ«nat â ne kemi njĂ« skemĂ« tjetĂ«r. Pajisjet vetĂ« dĂ«rgojnĂ« tĂ« dhĂ«nat kur kanĂ« lidhje. Ky Ă«shtĂ« njĂ« moment shumĂ« i rĂ«ndĂ«sishĂ«m, sepse lejon marrjen e tĂ« dhĂ«nave nga pajisja pĂ«r ato periudha kohe, kur ajo nuk ishte e aksesueshme dhe nuk e ngarkon kanalin dhe burimet nĂ« atĂ« kohĂ« kur pajisja nuk Ă«shtĂ« e aksesueshme. Si sistem qendror tĂ« monitorimit pĂ«rdorim serverin e monitorimit Influx. Ndryshe nga homologĂ«t, ai din tĂ« importojĂ« tĂ« dhĂ«nat retrospektive (tĂ« tilla si me njĂ« etiketĂ« kohe tĂ« ndryshme nga momenti i marrjes sĂ« metrikĂ«s). Metrikat e mbledhura janĂ« vizualizuar nga Grafana, e cila Ă«shtĂ« pĂ«rmirĂ«suar pĂ«r kĂ«tĂ« qĂ«llim. Ky stek standard u zgjodh gjithashtu pĂ«r shkak se ka API gatishmĂ«ri pĂ«r integrim me pothuajse çdo sistem monitorimi tĂ« klientit. - Sinkronizimi i tĂ« dhĂ«nave me sistemin qendror tĂ« menaxhimit tĂ« pajisjeve.
Sistemi i menaxhimit të pajisjeve implementon Zero Touch Provisioning (përditësimi i softuerit, konfigurimi, etj.) dhe, ndryshe nga sistemi i monitorimit, merr vetëm problemet e pajisjeve. Këto janë triigerat e funksionimit të shërbimeve mbrojtëse harduerike dhe të gjitha metrikat e sistemeve të mbështetjes së jetës: temperatura e CPU dhe SSD, ngarkesa e CPU, hapësira e lirë dhe shëndeti S.M.A.R.T në disqet. Ruajtja e nën-sistemit është gjithashtu e ndërtuar mbi Tarantool. Kjo na ofron një shpejtësi të rëndësishme në agregimin e serive temporale për mijëra pajisje, si dhe zgjidh plotësisht çështjen e sinchronizimit të të dhënave me këto pajisje. Tarantool ka një sistem të shkëlqyer të radhëve dhe dorëzimit të garantuar. Kjo veçori e rëndësishme e morëm nga kutia, shkëlqyer!
Sistemi i menaxhimit të rrjetit
ĂfarĂ« ndodh mĂ« pas
Derisa lidhja më e dobët për momentin është sistemi i qendror i monitorimit. Ai është implementuar në 99.9% mbi një stiv standard dhe ka një sërë të metash:
- InfluxDB humb të dhëna në rast të ndalimit të energjisë. Në përgjithësi, Klienti merr shpejt gjithçka që vjen nga pajisjet dhe në vetë DB nuk ka të dhëna më të vjetra se 5 minuta, megjithatë, në të ardhmen kjo mund të bëhet një problem.
- Grafana ka një sërë problemesh me agregimin e të dhënave dhe sinkronizimin e shfaqjes së tyre. Problemi më i zakonshëm është kur në bazë është një rregull temporal me interval prej 2 sekondash duke filluar nga orari 00:00:00, ndërsa Grafana fillon të tregojë të dhënat në agregim nga +1 sekondë. Si rezultat, përdoruesi sheh një grafik të lëkundur.
- Sasia e tepërt e kodit për integrimin e API-së me sistemet e tjera të monitorimit. Mund të bëhet shumë më kompakt dhe sigurisht të shkruhet në Go :)
Mendoj se të gjithë e keni parë si duket Grafana dhe e dini problemet e saj, kështu që nuk do ta mbingarkoj postimin me fotografi.
PĂ«rfundimi
Unë qëllimisht nuk kam përshkruar detajet teknike, por kam përshkruar vetëm dizajnin themelor të këtij sistemi. Së pari, për të përshkruar teknike plotësisht sistemin do të duhej një artikull tjetër. Së dyti, shumë njerëz nuk do ta kenë këtë interes. Shkruani në komentet se cilat detaje teknike dëshironi të dini.
Nëse dikush ka pyetje jashtë këtij artikulli, mund të më shkruani në adresën a.rodin @ qedr.com
Burimi: habr.com
