16 modema, 4 operatorë celularë = Shpejtësia e dërgimit 933.45 Mbit/s
Hyrje
Përshëndetje! Ky është një artikull mbi mënyrën si shkruam për veten tonë një sistem të ri monitorimi. Ajo dallon nga ato ekzistuese për mundësinë e marrjes me frekuencë të lartë dhe sinkronizimit të metrikave me një konsumim shumë të vogël të burimeve. Frekuenca e anketimit mund të arrijë deri në 0.1 milisekond, me saktësinë e sinkronizimit ndërmjet metrikave në 10 nanosekonda. Të gjithë skedarët binarë zënë 6 megabajt.
PĂ«r projektin
Ne kemi njĂ« produkt mjaft specifik. Ne prodhojmĂ« njĂ« zgjidhje tĂ« integruar pĂ«r pĂ«rmbledhjen e kapacitetit dhe qĂ«ndrueshmĂ«risĂ« sĂ« kanaleve tĂ« transmetimit tĂ« tĂ« dhĂ«nave. Kjo Ă«shtĂ« kur ka disa kanale, le tĂ« themi Operator1 (40Mbit/s) + Operator2 (30Mbit/s) + Diçka tjetĂ«r (5 Mbit/s), rezultati Ă«shtĂ« njĂ« kanal stabil dhe tĂ« shpejtĂ«, shpejtĂ«sia e tĂ« cilit do tĂ« jetĂ« afĂ«rsisht kĂ«shtu: (40+30+5)x0.92=75Ă0.92=69 Mbit/s.
Këto zgjidhje kërkohen aty ku kapaciteti i çdo kanali të vetëm është i pamjaftueshëm. P.sh., transporti, sistemet e video-monitorimit dhe transmetimit të videos në kohë reale, transmetimi i emisioneve të drejtpërdrejta radio-televizive, çdo objekt në periferi ku nga operatorët e komunikimit ka vetëm përfaqësues të katërshes së madhe dhe shpejtësitë në një modem/kanal nuk janë të mjaftueshme.
Për secilën nga këto drejtime, ne publikojmë një linjë të veçantë pajisjesh, megjithatë pjesa e tyre software është pothuajse e njëjtë dhe një sistem monitorimi cilësor është një nga modulat e tij kryesore, pa zbatimin e duhur të të cilit produkti do të ishte i pamundur.
Gjatë disa viteve, na ka arritur të krijojmë një sistem monitorimi të shpejtë, shumë-ndarje dhe të lehtë. Këtë edhe duam të ndajmë me komunitetin e nderuar.
Formulimi i detyrës
Sistema e monitorimit siguron marrjen e metrikave të dy klasave thelbësore të ndryshme: metrikat në kohë reale dhe të gjitha të tjera. Për sistemin e monitorimit ka pasur vetëm kërkesat e mëposhtme:
- Marrje sinkronike me frekuencë të lartë të metrikave në kohë reale dhe dërgimi i tyre në sistemin e menaxhimit të komunikacionit pa vonesa.
Frekuenca e lartë dhe sinkronizimi i metrikeve të ndryshme nuk është thjesht i rëndësishëm, por është jetësor për analizën e entropisë së kanaleve të transmetimit të të dhënave. Nëse në një kanal transmetimi mesatarja e vonesës është 30 milisekonda, gabimi në sinkronizim midis metrikeve të tjera me vetëm një milisekondë do të sjellë një degradim të shpejtësisë së kanalit përfundimtar rreth 5%. Nëse 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 matim atë më rrallë se një herë në 0.5 milisekonda, në kanale të shpejta me vonesë të vogël do të marrim degradim të lartë të shpejtësisë. Sigurisht, një saktësi e tillë nuk është e nevojshme për të gjitha metrike dhe në të gjitha kushtet. Kur vonesa në kanal është 500 milisekonda, dhe ne punojmë me të tilla, gabimi në 1 milisekondë nuk do të jetë pothuajse i dukshëm. Gjithashtu, për metrike të sistemeve të mbështetjes së jetës, na mjafton një frekuencë anketimi dhe sinkronizimi prej 2 sekondash, megjithatë vetë sistemi i monitorimit duhet të jetë në gjendje të punojë me frekuenca të jashtëzakonshme anketimi dhe sinkronizim të saktë të metrikeve. - Konsum minimal i burimeve dhe një grumbull i unifikuar.
Dispozitati përfundimtar mund të përfaqësojë si një kompleks të fuqishëm bord, i cili mund të analizoje situatën në rrugë ose të përcaktojë biometrikisht njerëzit, ashtu si një kompjuter njëpjesësh që është sa një pëllëmbë dhe që e bart një ushtar special për të transmetuar video në kohë reale në kushte lidhjeje të keqe. Pavarësisht këtij ndryshimi të arkitekturave dhe fuqive llogaritëse, dëshirojmë të kemi një grumbull të njëjtë softueri. - Arkitektura mbulues
Metriket duhet të mblidhen dhe agregohen në dispozitiven përfundimtare, të ketë një sistem lokal ruajtjeje dhe vizualizimi në kohë reale dhe retrospektivisht. Në rast se ka lidhje, duhet të dërgojë të dhënat në sistemin qendror të monitorimit. Kur nuk ka lidhje, radhitja për dërgim duhet të akumulohet dhe të mos konsumohet memorie operative. - API për integrimin në sistemin e monitorimit të klientit, sepse askujt nuk i nevojiten shumë sisteme monitorimi. Klienti duhet të mblidhte të dhëna nga çdo pajisje dhe rrjet në një monitorim të vetëm.
ĂfarĂ« rezultati kemi arritur
Për të mos e ngarkuar më tej këtë lëndë të gjerë, nuk do të jap shembuj dhe matje të të gjitha sistemeve të monitorimit. Kjo do të kërkonte një artikull tjetër. Thjesht do të thosha 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 në arhitekturën ARM me 64MB RAM dhe në arhitekturën x86_64 me 32GB RAM. Prandaj, vendosëm të shkruajmë një tonin tonë, e cila 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ë kryesore programimi, si në pajisje ashtu edhe në Qendrën e Të Dhënave (QTD), ne përdorim Golang. Ai ka thjeshtuar jetën tonë në mënyrë të konsiderueshme me realizimin e multithreading dhe mundësinë për të marrë një skedar binar të lidhur statikisht për çdo shërbim. Si rezultat, ne kursyemi ndjeshëm në burime, metoda dhe trafikun e shpërndarjes së shërbimit në pajisje të fundit, kohës së zhvillimit dhe debuggimit të kodit.
Sistemi është realizuar sipas parimeve klasike modulare dhe përmban disa nën-sisteme:
- Regjistrimi i metrikeve.
Ădo metrikĂ« trajtohet nga njĂ« proces i dedikuar dhe sinjalizohet pĂ«rmes kanaleve. Na arriti tĂ« arrijmĂ« saktĂ«si sinhronizimi deri nĂ« 10 nanosekonda. - Ruajtja e metrikeve
Kemi zgjedhur midis ndërtimit të deponisë sonë për seri temporale ose përdorimit të diçkaje që ekziston. Një bazë të dhënash është e nevojshme për të dhënat retrospaktive, të cilat do të pasojnë vizualizimin. Pra, nuk ka të dhëna për vonesat në kanal çdo 0.5 milisekonda ose përmbledhjet 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ërprerje të platformave të ndryshme dhe konsumim të ulët të burimeve, është thelbësore për ne të kemi mundësinë për të procesuar të dhënat atje ku ato ruhen. Kjo kursen në mënyrë kolosale burimet kompjuterike. Prej vitit 2016, ne përdorim sistemin e menaxhimit të të dhënave Tarantool për këtë projekt dhe për momentin nuk shohim asnjë zëvendësim në horizont. Fleksibël, me konsumim optimal të burimeve dhe mbështetje teknike më shumë se adekuate. Gjithashtu, në Tarantool është implementuar moduli GIS. Natyrisht, ai nuk është aq i fuqishëm sa PostGIS, por është i mjaftueshëm për detyrat tona të ruajtjes së disa metrikave të lidhura me lokacionin (relevante për transportin). - Vizualizimi i metrikave
Këtu gjithçka është relativisht e thjeshtë. Marrim të dhënat nga depoja dhe i tregojmë ose në kohë reale ose retrospktivisht. - Sinkronizimi i të dhënave me sistemin qendror të monitorimit.
Sistemi qendror i monitorimit merr tĂ« dhĂ«na nga tĂ« gjitha pajisjet, i ruan ato me njĂ« retrospektivĂ« tĂ« caktuar dhe pĂ«rmes API-ja i jep ato nĂ« sistemin e monitorimit tĂ« Klientit. Ndryshe nga sistemet klasike tĂ« monitorimit, ku 'koka' shkon dhe mbledh tĂ« dhĂ«na â ne kemi njĂ« skemĂ« tĂ« kundĂ«rt. Pajisjet vetĂ« dĂ«rgojnĂ« tĂ« dhĂ«na atĂ«herĂ« kur ka lidhje. Ky Ă«shtĂ« njĂ« moment shumĂ« i rĂ«ndĂ«sishĂ«m, pasi lejon marrjen e tĂ« dhĂ«nave nga pajisja pĂ«r ato periudha kohore kur ajo nuk ka qenĂ« e aksesueshme dhe nuk e ngarkon kanalin dhe burimet nĂ« kohĂ«n kur pajisja Ă«shtĂ« e paqartĂ«. Si sistem qendror i monitorimit ne pĂ«rdorim Influx monitoring server. Ndryshe nga homologĂ«t e tij, ai di tĂ« importojĂ« tĂ« dhĂ«na retrospaktive (dmth me njĂ« etiketĂ« kohe tĂ« ndryshme nga momenti i marrjes sĂ« metrikĂ«s). Metrikat e mbledhura vizualizohen nga Grafana e pĂ«rmirĂ«suar. Ky stack standard u zgjodh gjithashtu sepse ka API integrimi gati me çdo sistem monitorimi tĂ« klientit. - Sinkronizimi i tĂ« dhĂ«nave me sistemin qendror tĂ« menaxhimit tĂ« pajisjeve.
Sistemi i menaxhimit të pajisjeve zbaton Zero Touch Provisioning (përditësimi i firmware, konfigurimeve, etj.) dhe ndryshe nga sistemi i monitorimit, merr vetëm problemet nga pajisjet. Këto janë sprovat e shërbimeve të ruajtjes të bordit dhe të gjitha metrikat e sistemeve të jetesës: temperatura e CPU-së dhe SSD-së, ngarkesa e CPU-së, hapësira e lirë dhe shëndeti S.M.A.R.T në disqe. Ruajtja e nën-sistemit është gjithashtu e ndërtuar mbi Tarantool. Kjo na jep një shpejtësi të konsiderueshme në agregimin e serive temporale për mijëra pajisje, si dhe zgjidh plotësisht çështjen e sinkronizimit të të dhënave me këto pajisje. Tarantool përmban një sistem të shkëlqyer të radhitjeve dhe dorëzimit të garantuar. Këtë veçori të rëndësishme e morëm nga kutia, shkëlqyeshëm!
Sistemi i menaxhimit të rrjetit
ĂfarĂ« pason
Në këtë moment, pika më e dobët është sistemi qendror i monitorimit. Ai është implementuar në 99.9% në strukturën standarde dhe ka disa mangësi:
- InfluxDB humbet të dhëna kur ndalet energjia. Në përgjithësi, Klienti merr menjëherë gjithçka që vjen nga pajisjet dhe në vetë DB-në nuk ka të dhëna më të vjetra se 5 minuta, megjithatë kjo mund të bëhet një problem në të ardhmen.
- Grafana ka disa probleme me agregimin e të dhënave dhe sinkronizimin e shfaqjes së tyre. Problemi më i zakonshëm - është kur në bazën e të dhënave ekziston një seri temporale me një interval prej 2 sekondash duke filluar, thonë, nga 00:00:00, ndërsa Grafana fillon të tregojë të dhënat në agregim nga +1 sekondë. Si rezultat, përdoruesi sheh një grafik që luhatet.
- Më shumë kod për integrimin e API me sistemet e jashtme të monitorimit. Mund të bëhet shumë më kompakt dhe sigurisht të shkruhet përsëri në Go)
Mendoj se të gjithë e keni parë si duket Grafana dhe pa mua e dini problemet e saj, prandaj nuk do të ngarkoj postimin me imazhe.
PĂ«rfundim
Qëllimisht nuk e përshkrova detajet teknike, por përshkrova vetëm dizajnin përfundimtar të këtij sistemi. Fillimisht, për të përshkruar teknologjikisht sistemin do të nevojitej një artikull tjetër. E dyta, nuk do të jetë interesante për të gjithë. Shkruani në komentet se cilat detaje teknike do të dëshironit të dinit.
Nëse ndokush ka pyetje përtej këtij artikulli, mund të më shkruani në adresën a.rodin @ qedr.com
Burimi: habr.com
