Teine jälgimissüsteem

16 modemit, 4 mobiilsideoperaatorit = väljumiskiirus 933.45 Mbit/s

Sissejuhatus

Tere! See artikkel räägib sellest, kuidas kirjutasime enda jaoks uue seiresüsteemi. See erineb olemasolevatest kõrgsageduslike sünkroonmõõdikute hankimise ja väga väikese ressursikulu poolest. Küsitlussagedus võib ulatuda 0.1 millisekundini, sünkroonimistäpsusega 10 nanosekundit. Kõik binaarfailid võtavad 6 megabaiti.

umbes

Meil on üsna spetsiifiline toode. Toodame tervikliku lahenduse andmeedastuskanalite läbilaskevõime ja tõrketaluvuse kokkuvõtmiseks. See on siis, kui kanaleid on mitu, ütleme Operaator1 (40Mbit/s) + Operaator2 (30Mbit/s)+ Midagi veel (5 Mbit/s), tulemuseks on üks stabiilne ja kiire kanal, mille kiirus saab olema umbes selline see: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Sellised lahendused on nõutud, kui ühe kanali läbilaskevõime ei ole piisav. Näiteks transport, videovalvesüsteemid ja reaalajas video voogesitus, televisiooni- ja raadiosaadete otseülekanne, kõik äärelinna rajatised, kus telekommunikatsioonioperaatorite hulgas on ainult Suure Neliku esindajad ja ühe modemi/kanali kiirusest ei piisa. .
Iga nimetatud valdkonna jaoks toodame eraldi seadmesarja, kuid nende tarkvaraline osa on peaaegu sama ja kvaliteetne monitooringusüsteem on üks selle põhimooduleid, mille korrektse teostuseta poleks toode võimalik.

Mitme aasta jooksul õnnestus meil luua mitmetasandiline, kiire, platvormideülene ja kerge seiresüsteem. Seda tahame oma lugupeetud kogukonnaga jagada.

Probleemi avaldus

Seiresüsteem pakub kahe põhimõtteliselt erineva klassi mõõdikuid: reaalajas mõõdikuid ja kõiki teisi. Seiresüsteemil olid ainult järgmised nõuded:

1. Reaalajas mõõdikute kõrgsageduslik sünkroonne hankimine ja nende viivitusteta ülekandmine sidehaldussüsteemist.
   Erinevate mõõdikute kõrge sagedus ja sünkroniseerimine pole mitte ainult oluline, vaid ülioluline andmeedastuskanalite entroopia analüüsimisel. Kui ühes andmeedastuskanalis on keskmine viivitus 30 millisekundit, siis ainult ühe millisekundi pikkune ülejäänud mõõdikute vaheline sünkroniseerimisviga viib tulemuseks oleva kanali kiiruse vähenemiseni ligikaudu 5%. Kui ajastada 1 kanali ajastus 4 millisekundi võrra valesti, võib kiiruse langus kergesti langeda 30%-ni. Lisaks muutub entroopia kanalites väga kiiresti, nii et kui mõõta seda harvem kui kord 0.5 millisekundi jooksul, siis kiiretel kanalitel väikese viivitusega saame suure kiiruse halvenemise. Muidugi pole sellist täpsust vaja kõigi mõõdikute ja mitte kõikides tingimustes. Kui kanali viivitus on 500 millisekundit ja me töötame sellega, pole 1 millisekundi viga peaaegu märgatav. Samuti on elu toetavate süsteemide mõõdikute jaoks piisavalt 2-sekundilist küsitlus- ja sünkroonimissagedust, kuid seiresüsteem ise peab suutma töötada ülikõrgete küsitlussageduste ja ülitäpse mõõdikute sünkroniseerimisega.
2. Minimaalne ressursikulu ja üks virn.
   Lõppseade võib olla kas võimas pardakompleks, mis suudab analüüsida olukorda teel või teostada inimeste biomeetrilist salvestust või peopesasuurune ühe pardaarvuti, mida eriväelane kannab soomusvesti all video edastamiseks. reaalajas halbades sidetingimustes. Vaatamata sellisele erinevale arhitektuurile ja arvutusvõimsusele sooviksime sama tarkvarapaketti.
3. Vihmavarju arhitektuur
   Mõõdikud tuleb koguda ja koondada lõppseadmesse, salvestada kohapeal ning visualiseerida reaalajas ja tagasiulatuvalt. Ühenduse olemasolul edastage andmed keskseiresüsteemi. Kui ühendust pole, peaks saatmisjärjekord kogunema ja mitte tarbima RAM-i.
4. API kliendi monitooringusüsteemi integreerimiseks, sest keegi ei vaja palju monitooringusüsteeme. Klient peab koguma andmeid mis tahes seadmetest ja võrkudest ühtseks monitooringuks.

Mis juhtus

Et mitte koormata niigi muljetavaldavat pikka lugemist, ei hakka ma tooma kõigi seiresüsteemide näiteid ja mõõtmisi. See viib teise artiklini. Ütlen vaid, et me ei suutnud leida seiresüsteemi, mis oleks võimeline võtma kahte mõõdikut üheaegselt alla 1 millisekundilise veaga ja mis toimiks võrdselt tõhusalt nii ARM-i arhitektuuril 64 MB muutmäluga kui ka x86_64 arhitektuuril 32-ga. GB RAM-i. Seetõttu otsustasime kirjutada oma, mis suudab seda kõike teha. Saime järgmist:

Kolme kanali läbilaskevõime kokkuvõte erinevate võrgutopoloogiate jaoks

Mõne põhimõõdiku visualiseerimine

arhitektuur

Peamise programmeerimiskeelena kasutame Golangi nii seadmes kui andmekeskuses. See lihtsustas oluliselt elu, rakendades multitegumtöötlust ja võimaluse hankida iga teenuse jaoks üks staatiliselt lingitud käivitatav binaarfail. Selle tulemusena hoiame oluliselt kokku ressursse, meetodeid ja liiklust teenuse juurutamiseks lõppseadmetesse, arendusaega ja koodi silumist.

Süsteem on rakendatud klassikalise modulaarse põhimõtte kohaselt ja sisaldab mitmeid alamsüsteeme:

1. Mõõdikute registreerimine.
   Iga mõõdikut teenindab oma lõim ja sünkroonitakse kanalite vahel. Suutsime saavutada kuni 10 nanosekundi sünkroonimistäpsuse.
2. Mõõdikute salvestamine
   Valisime, kas kirjutada aegridade jaoks oma salvestusruum või kasutada midagi, mis oli juba saadaval. Andmebaas on vajalik retrospektiivsete andmete jaoks, mis kuuluvad hilisemale visualiseerimisele, see tähendab, et see ei sisalda andmeid kanali viivituste kohta iga 0.5 millisekundi või veanäitude kohta transpordivõrgus, kuid igal liidesel on kiirus iga 500 millisekundi järel. Lisaks kõrgetele nõudmistele platvormideülesele ja madalale ressursikulule on meie jaoks äärmiselt oluline töötlemisvõime. andmed on seal, kus neid hoitakse. See säästab tohutult arvutusressursse. Tarantool DBMS-i oleme selles projektis kasutanud alates 2016. aastast ja seni ei näe me sellele asendust silmapiiril. Paindlik, optimaalse ressursitarbimisega, enam kui piisav tehniline tugi. Tarantool rakendab ka GIS-moodulit. Muidugi pole see nii võimas kui PostGIS, kuid sellest piisab meie ülesannete jaoks salvestada mõned asukohaga seotud mõõdikud (transpordi jaoks).
3. Mõõdikute visualiseerimine
   Siin on kõik suhteliselt lihtne. Võtame andmed laost ja kuvame need kas reaalajas või tagantjärele.
4. Andmete sünkroniseerimine keskseiresüsteemiga.
   Keskne seiresüsteem võtab andmed vastu kõikidelt seadmetelt, salvestab need koos määratud ajalooga ja saadab API kaudu Kliendi monitooringusüsteemi. Erinevalt klassikalistest seiresüsteemidest, kus “pea” käib ringi ja kogub andmeid, on meil vastupidine skeem. Seadmed ise saadavad andmeid, kui ühendus on olemas. See on väga oluline punkt, kuna see võimaldab teil vastu võtta seadmelt andmeid nende ajavahemike kohta, mil see ei olnud saadaval, ning mitte laadida kanaleid ja ressursse, kui seade pole saadaval. Keskse jälgimissüsteemina kasutame Influx monitooringuserverit. Erinevalt oma analoogidest suudab see importida tagasiulatuvaid andmeid (ehk mõõdikute vastuvõtmise hetkest erineva ajatempliga) Kogutud mõõdikud visualiseerib Grafana, muudab neid failiga. See standardne pinu valiti ka seetõttu, et sellel on valmis API-integratsioonid peaaegu kõigi klientide jälgimissüsteemiga.
5. Andmete sünkroonimine keskse seadmehaldussüsteemiga.
   Seadmehaldussüsteem rakendab Zero Touch Provisioning'i (värskendab püsivara, konfiguratsiooni jne) ja erinevalt jälgimissüsteemist saab seadme kohta ainult probleeme. Need on sisseehitatud riistvara valveteenuste ja kõigi elu toetavate süsteemide mõõdikute käivitajad: protsessori ja SSD temperatuur, protsessori koormus, vaba ruum ja ketaste SMART-i tervis. Alamsüsteemi salvestusruum on samuti ehitatud Tarantoolile. See annab meile märkimisväärse kiiruse tuhandete seadmete aegridade koondamisel ja lahendab täielikult ka andmete sünkroonimise nende seadmetega. Tarantoolil on suurepärane järjekordade ja garanteeritud kohaletoimetamise süsteem. Saime selle olulise funktsiooni karbist välja, suurepärane!

Võrguhaldussüsteem

mis edasi

Seni on meie nõrgim lüli keskne seiresüsteem. Seda rakendatakse 99.9% standardse virna peal ja sellel on mitmeid puudusi:

1. InfluxDB kaotab toite katkemisel andmed. Üldjuhul kogub Klient operatiivselt kõik, mis seadmetest tuleb ja andmebaasis endas ei ole vanemaid kui 5 minuti andmeid, kuid edaspidi võib see piinlikuks muutuda.
2. Grafanal on mitmeid probleeme andmete koondamise ja kuvari sünkroonimisega. Kõige tavalisem probleem on see, kui andmebaas sisaldab 2-sekundilise intervalliga aegridu, mis algavad näiteks 00:00:00-st ja Grafana hakkab andmeid näitama koondatuna alates +1 sekundist. Selle tulemusena näeb kasutaja tantsivat graafikut.
3. Liiga palju koodi API integreerimiseks kolmandate osapoolte jälgimissüsteemidega. Seda saab muuta palju kompaktsemaks ja muidugi Go-vormingus ümber kirjutada)

Ma arvan, et olete kõik suurepäraselt näinud, milline Grafana välja näeb, ja teate selle probleeme ka ilma minuta, nii et ma ei hakka postitust piltidega üle koormama.

Järeldus

Ma ei kirjeldanud meelega tehnilisi üksikasju, vaid kirjeldasin ainult selle süsteemi põhikonstruktsiooni. Esiteks on süsteemi tehniliseks täielikuks kirjeldamiseks vaja veel ühte artiklit. Teiseks ei huvita see kõik. Kirjuta kommentaaridesse, milliseid tehnilisi detaile soovid teada.

Kui kellelgi on küsimusi sellest artiklist kaugemale, võite kirjutada mulle aadressil a.rodin @ qedr.com

Allikas: www.habr.com