Një tjetër sistem monitorimi

16 modeme, 4 operatorë celularë = Shpejtësia e daljes 933.45 Mbit/s

Paraqitje

Përshëndetje! Ky artikull ka të bëjë me mënyrën se si kemi shkruar një sistem të ri monitorimi për veten tonë. Ai ndryshon nga ato ekzistuese në aftësinë e tij për të marrë metrikë sinkrone me frekuencë të lartë dhe konsum shumë të ulët të burimeve. Shkalla e sondazhit mund të arrijë 0.1 milisekonda me një saktësi sinkronizimi midis metrikave prej 10 nanosekonda. Të gjithë skedarët binare zënë 6 megabajt.

O projekte

Ne kemi një produkt mjaft specifik. Ne prodhojmë një zgjidhje gjithëpërfshirëse për përmbledhjen e xhiros dhe tolerancës së gabimeve të 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 i qëndrueshëm dhe i shpejtë, shpejtësia e të cilit do të jetë diçka si kjo: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Zgjidhje të tilla kërkohen kur kapaciteti i çdo kanali është i pamjaftueshëm. Për shembull, transporti, sistemet e mbikëqyrjes video dhe transmetimi video në kohë reale, transmetimi i transmetimeve të drejtpërdrejta televizive dhe radiofonike, çdo objekt periferik ku midis operatorëve të telekomit ka vetëm përfaqësues të Big Four dhe shpejtësia në një modem/kanal nuk është e mjaftueshme. .
Për secilën prej këtyre zonave, ne prodhojmë një linjë të veçantë pajisjesh, por pjesa e tyre softuerike është pothuajse e njëjtë dhe një sistem monitorimi me cilësi të lartë është një nga modulet kryesore të tij, pa zbatimin e saktë të të cilit produkti nuk do të ishte i mundur.

Gjatë disa viteve, ne arritëm të krijonim një sistem monitorimi me shumë nivele, të shpejtë, ndër-platformë dhe të lehtë. Kjo është ajo që ne duam të ndajmë me komunitetin tonë të respektuar.

Formulimi i problemit

Sistemi i monitorimit ofron metrika të dy klasave thelbësisht të ndryshme: metrikat në kohë reale dhe të gjitha të tjerat. Sistemi i monitorimit kishte vetëm kërkesat e mëposhtme:

1. Përvetësimi sinkron me frekuencë të lartë të matjeve në kohë reale dhe transferimi i tyre nga sistemi i menaxhimit të komunikimit pa vonesa.
   Frekuenca e lartë dhe sinkronizimi i metrikave të ndryshme nuk është vetëm i rëndësishëm, por është jetik për analizimin e entropisë së kanaleve të transmetimit të të dhënave. Nëse në një kanal të transmetimit të të dhënave vonesa mesatare është 30 milisekonda, atëherë një gabim në sinkronizimin ndërmjet metrikës së mbetur prej vetëm një milisekondi do të çojë në degradim të shpejtësisë së kanalit që rezulton me afërsisht 5%. Nëse e zvogëlojmë kohën me 1 milisekondë në 4 kanale, degradimi i shpejtësisë mund të bjerë lehtësisht në 30%. Përveç kësaj, entropia në kanale ndryshon shumë shpejt, kështu që nëse e masim atë më pak se një herë në 0.5 milisekonda, në kanalet e shpejta me një vonesë të vogël do të kemi degradim me shpejtësi të lartë. Sigurisht, një saktësi e tillë 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ë tillë, atëherë një gabim prej 1 milisekonda pothuajse nuk do të vërehet. Gjithashtu, për matjet e sistemit të mbështetjes së jetës, ne kemi nivele të mjaftueshme votimi dhe sinkronizimi prej 2 sekondash, por vetë sistemi i monitorimit duhet të jetë në gjendje të punojë me norma ultra të larta sondazhi dhe sinkronizim ultra të saktë të metrikës.
2. Konsumi minimal i burimeve dhe një pirg i vetëm.
   Pajisja fundore mund të jetë ose një kompleks i fuqishëm në bord që mund të analizojë situatën në rrugë ose të kryejë regjistrim biometrik të njerëzve, ose një kompjuter me një dërrasë me madhësi të pëllëmbës që një ushtar i forcave speciale mban nën armaturën e tij për të transmetuar video në kohë reale në kushte të vështira komunikimi. Pavarësisht nga një shumëllojshmëri e tillë e arkitekturave dhe fuqisë kompjuterike, ne do të dëshironim të kishim të njëjtin grumbull softuerësh.
3. Arkitektura ombrellë
   Metrikat duhet të mblidhen dhe të grumbullohen në pajisjen fundore, të ruhen në nivel lokal dhe të vizualizohen në kohë reale dhe në mënyrë retrospektive. Nëse ka një lidhje, transferoni të dhënat në sistemin qendror të monitorimit. Kur nuk ka lidhje, radha e dërgimit duhet të grumbullohet dhe të mos konsumojë RAM.
4. API për integrim në sistemin e monitorimit të klientit, sepse askush nuk ka nevojë për shumë sisteme monitorimi. Klienti duhet të mbledhë të dhëna nga çdo pajisje dhe rrjet në një monitorim të vetëm.

Cfare ndodhi

Për të mos e rënduar të kaluarën tashmë mbresëlënëse, nuk do të jap shembuj dhe matje të të gjitha sistemeve të monitorimit. Kjo do të çojë në një artikull tjetër. Unë thjesht do të them se ne nuk mundëm të gjenim një sistem monitorimi që mund të marrë dy metrika njëkohësisht me një gabim prej më pak se 1 milisekonda dhe që funksionon në mënyrë të barabartë si në arkitekturën ARM me 64 MB RAM ashtu edhe në arkitekturën x86_64 me 32 GB RAM. Prandaj, vendosëm të shkruajmë tonën, e cila mund t'i bëjë të gjitha këto. Ja çfarë kemi:

Përmbledhja e xhiros së tre kanaleve për topologji të ndryshme të rrjetit

Vizualizimi i disa metrikave kryesore

Arkitekturë

Ne përdorim Golang si gjuhën kryesore të programimit, si në pajisje ashtu edhe në qendrën e të dhënave. Ai thjeshtoi shumë jetën me zbatimin e tij të multitasking dhe aftësinë për të marrë një skedar binar të ekzekutueshëm të lidhur statikisht për çdo shërbim. Si rezultat, ne kursejmë ndjeshëm burimet, metodat dhe trafikun për vendosjen e shërbimit në pajisjet fundore, kohën e zhvillimit dhe korrigjimin e kodit.

Sistemi zbatohet sipas parimit klasik modular dhe përmban disa nënsisteme:

1. Regjistrimi i metrikës.
   Çdo metrikë shërbehet nga filli i vet dhe sinkronizohet nëpër kanale. Ne ishim në gjendje të arrinim saktësinë e sinkronizimit deri në 10 nanosekonda.
2. Ruajtja e metrikës
   Ne po zgjidhnim midis shkrimit të hapësirës sonë të ruajtjes për seritë kohore ose përdorimit të diçkaje që ishte tashmë e disponueshme. Baza e të dhënave është e nevojshme për të dhëna retrospektive që i nënshtrohen vizualizimit të mëvonshëm. Dmth, ajo nuk përmban të dhëna për vonesat në kanal çdo 0.5 milisekonda ose lexime të gabimeve në rrjetin e transportit, por ka shpejtësi në çdo ndërfaqe çdo 500 milisekonda. Përveç kërkesave të larta për ndër-platformë dhe konsumit të ulët të burimeve, është jashtëzakonisht e rëndësishme që ne të jemi në gjendje të përpunojmë. të dhënat janë vendi ku ruhen. Kjo kursen burime të mëdha kompjuterike. Ne kemi përdorur Tarantool DBMS në këtë projekt që nga viti 2016 dhe deri më tani nuk shohim një zëvendësim për të në horizont. Fleksibël, me konsum optimal të burimeve, më shumë se mbështetje teknike adekuate. Tarantool gjithashtu zbaton një modul GIS. Sigurisht, nuk është aq i fuqishëm sa PostGIS, por mjafton për detyrat tona të ruajtjes së disa metrikave të lidhura me vendndodhjen (relevant për transportin).
3. Vizualizimi i metrikës
   Gjithçka është relativisht e thjeshtë këtu. Ne marrim të dhëna nga magazina dhe i shfaqim në kohë reale ose në mënyrë retrospektive.
4. 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ë histori të caktuar dhe i dërgon në sistemin e monitorimit të klientit nëpërmjet API. Ndryshe nga sistemet klasike të monitorimit, në të cilat "koka" sillet dhe mbledh të dhëna, ne kemi skemën e kundërt. Vetë pajisjet dërgojnë të dhëna kur ka një lidhje. Kjo është një pikë shumë e rëndësishme, pasi ju lejon të merrni të dhëna nga pajisja për ato periudha kohore gjatë të cilave ajo nuk ishte e disponueshme dhe të mos ngarkoni kanale dhe burime ndërsa pajisja nuk është e disponueshme. Ne përdorim serverin e monitorimit të Influx si një sistem qendror monitorimi. Ndryshe nga analogët e tij, ai mund të importojë të dhëna retrospektive (d.m.th., me një vulë kohore të ndryshme nga momenti i marrjes së metrikës). Metrikat e mbledhura vizualizohen nga Grafana, modifikohen me një skedar. Ky stack standard u zgjodh gjithashtu sepse ka integrime të gatshme API me pothuajse çdo sistem monitorimi të klientit.
5. Sinkronizimi i të dhënave me një sistem qendror të menaxhimit të pajisjes.
   Sistemi i menaxhimit të pajisjes zbaton Zero Touch Provisioning (përditësimi i firmuerit, konfigurimi, etj.) dhe, ndryshe nga sistemi i monitorimit, merr vetëm probleme për pajisje. Këta janë nxitës për funksionimin e shërbimeve mbikëqyrëse të harduerit në bord dhe të gjitha metrikat e sistemeve të mbështetjes së jetës: temperatura e CPU dhe SSD, ngarkesa e CPU-së, hapësira e lirë dhe shëndeti S.M.A.R.T në disqe. Ruajtja e nënsistemit është gjithashtu e ndërtuar në Tarantool. Kjo na jep shpejtësi të konsiderueshme në grumbullimin e serive kohore në mijëra pajisje, dhe gjithashtu zgjidh plotësisht çështjen e sinkronizimit të të dhënave me këto pajisje. Tarantool ka një sistem të shkëlqyer të radhës dhe të garantuar të shpërndarjes. Ne e morëm këtë veçori të rëndësishme nga kutia, shkëlqyeshëm!

Sistemi i menaxhimit të rrjetit

Ç'pritet më tej

Deri më tani, hallka jonë më e dobët është sistemi qendror i monitorimit. Zbatohet 99.9% në një pirg standard dhe ka një sërë disavantazhesh:

1. InfluxDB humbet të dhënat kur humbet energjia. Si rregull, Klienti mbledh menjëherë gjithçka që vjen nga pajisjet dhe vetë baza e të dhënave nuk përmban të dhëna më të vjetra se 5 minuta, por në të ardhmen kjo mund të bëhet një dhimbje.
2. Grafana ka një sërë problemesh me grumbullimin e të dhënave dhe sinkronizimin e ekranit të saj. Problemi më i zakonshëm është kur baza e të dhënave përmban një seri kohore me një interval prej 2 sekondash duke filluar, le të themi, nga ora 00:00:00, dhe Grafana fillon të tregojë të dhëna të grumbulluara nga +1 sekondë. Si rezultat, përdoruesi sheh një grafik vallëzimi.
3. Sasi e tepërt e kodit për integrimin e API me sistemet e monitorimit të palëve të treta. Mund të bëhet shumë më kompakte dhe sigurisht të rishkruhet në Go)

Mendoj se të gjithë e keni parë në mënyrë të përsosur se si duket Grafana dhe i dini problemet e saj pa mua, kështu që nuk do ta mbingarkoj postimin me foto.

Përfundim

Me dashje nuk i përshkrova detajet teknike, por përshkrova vetëm modelin bazë të këtij sistemi. Së pari, për të përshkruar plotësisht sistemin teknikisht, do të kërkohet një artikull tjetër. Së dyti, jo të gjithë do të jenë të interesuar për këtë. Shkruani në komente cilat detaje teknike dëshironi të dini.

Nëse dikush ka pyetje përtej qëllimit të këtij artikulli, mund të më shkruani në a.rodin @ qedr.com

Burimi: www.habr.com