16 modemit, 4 mobiilioperaatorit = Väljaminev kiirus 933,45 Mbit/s
Sissejuhatus
Tere! See artikkel räägib sellest, kuidas me lõime endale uue jälgimisse süsteemi. See erineb olemasolevatest kõrge sagedusega paralleelsest mõõtmisest ja väga väikestest ressursside tarbimisest. Üksiku mõõtmise sagedus võib ulatuda 0,1 millisekundini, mõõtmete vahelise sünkroonimise täpsus on 10 nanosekundit. Kõik binaarfailid kaaluvad 6 megabaiti.
Projektist
Meil on üsna spetsiifiline toode. Valmistame kompleksset lahendust andmeedastuskanalite läbilaskevõime ja talitluse kindluse summamiseks. See tähendab, et on mitu kanali, näiteks Operaator1 (40 Mbit/s) + Operaator2 (30 Mbit/s) + Midagi muud (5 Mbit/s), mille tulemuseks on üks stabiilne ja kiire kanal, mille kiirus on ligikaudu järgmine: (40+30+5)x0,92=75×0,92=69 Mbit/s.
Selliseid lahendusi vajatakse seal, kus ühe kanali maht ei ole piisav. Näiteks transport, videovalve süsteemid ja reaalajas voogedastus, otseülekanded, kõik maanteega seotud objektid, kus sideoperaatoritest on ainult suure neliku esindajad ja ühes modemis/kanalis ei ole piisavalt kiirus.
Igaühe jaoks neist suundadest valmistame eraldi seadmelini, kuid nende tarkvara osa on peaaegu sama ning kvaliteetne jälgimisse süsteem on üks peamisi komponente, ilma õige teostuseta ei oleks toode võimalik.
Mõne aasta jooksul oleme suutelised loonud mitmeastmelise kiirrežiimi, platvormideülene ja kergkaalulise jälgimisse süsteemi. Mida soovime jagada austatud kogukonnaga.
Ülesande seadmine
Jälgimisse süsteem tagab kahte põhimõtteliselt erineva klasse mõõtmete saamise: reaalajas mõõtmed ja kõik teised. Jälgimisse süsteemile esitati vaid järgmised nõuded:
- Sagedane sünkrooniline reaalajas mõõtmise saamine ja nende edastamine side juhtimisse süsteemi viivitusteta.
Kõrge sagedus ja erinevate mõõdikute sünkroniseerimine ei ole lihtsalt oluline, vaid eluliselt vajalik andmeedastuskanalite entropia analüüsimiseks. Kui ühe andmeedastuskanali keskmine viivitus on 30 millisekundit, siis vea sünkroniseerimisel muude mõõdikute vahel, mis on vaid 1 millisekund, toob kaasa tulemuskande kiirusedegratsiooni umbes 5%. Kui me eksime sünkroniseerimisel 1 millisekundi vältel neljas kanalis, võib kiirusedegratsioon kergesti langeda 30%-le. Lisaks sellele muutub entropia kanalites väga kiiresti, seega, kui mõõta seda harvem kui kord 0,5 millisekundi jooksul, saame kiiretel kanalitel madala viivitusega kõrge kiirusedegratsiooni. Muidugi ei ole selline täpsus vajalik kõigi mõõdikutel ja kõikides tingimustes. Kui kanali viivitus on 500 millisekundit, ja me töötame ka sellistega, siis enam kui 1 millisekundi viga ei ole peaaegu märgata. Samuti piisab elutähtsate süsteemide mõõdikute jaoks, et küsitlus ja sünkroniseerimine toimuks iga 2 sekundi järel, kuid monitoringusüsteem ise peab suutma töötada ülikõrgete küsitluse sageduste ja äärmiselt täpse mõõdikute sünkroniseerimisega. - Minimaalne ressursside tarbimine ja ühtne virn.
Lõppseade võib olla nii võimas pardakompleks, mis suudab analüüsida teekonda või teostada inimeste biometrilist jälgimist, kui ka üheplaadine arvuti, mille suurus on peopesa ja mida sõdur kannab kuivikaku all video edastamiseks reaalajas halbades ühendusoludes. Hoolimata sellisest arhitektuuride ja arvutusvõimsuse mitmekesisusest, sooviksime, et meil oleks ühesugune tarkvaravirn. - Umbrella arhitektuur
Mõõdikud peavad koguma ja aggregaatima lõppseadmest, omama kohalikku salvestussüsteemi ja reaalajas ning retrospektiivset visualiseerimist. Kui ühendus on olemas, tuleb andmed edastada kesksetesse jälgimissüsteemidesse. Kui ühendust pole, peab saatmise järjekord kogunema ja mitte tarbima põhimälu. - API kliendi jälgimissüsteemiga integreerimiseks, sest keegi ei vaja palju jälgimissüsteeme. Klient peab koguma andmeid igasugustelt seadmetelt ja võrkudelt ühtsesse jälgimisse.
Mis välja tuli
Ette mitte koormata juba niigi mahukat artiklit, ma ei too näiteid ja mõõtmisi kõigist jälgimissüsteemidest. See võtaks veel ühe artikli. Lihtsalt ütlen, et me ei suutnud leida jälgimissüsteemi, mis suudab korraga mõõta kahte mõõdikut vähem kui 1 millisekundi täpsusega ja mis töötab sama efektiivselt nii ARM arhitektuuril 64 MB RAM-iga kui ka x86_64 arhitektuuril 32 GB RAM-iga. Seetõttu otsustasime kirjutada oma, mis oskab kõike seda. Siin on, mis meil välja tuli:
Kolme kanali läbilaskevõime kokkuvõtte erinevate võrgu topoloogiate jaoks
Mõnede oluliste mõõdikute visualiseerimine
Arhitektuur
Peamise programmeerimiskeelena kasutame nii seadmetes kui ka andmekeskuses Golangi. See on oluliselt lihtsustanud elu oma mitmeülesandelisuse rakendamise ja võimalusega iga teenuse jaoks saada üks staatiliselt lingitud täitmisfail. Tulemuseks on märkamatult suurenenud ressursside, meetodite ja teenuse juurutamise liikluse, arendamise ja koodi silumise kulude kokkuhoid.
Süsteem on ellu viidud klassikalise moodulipõhise printsipiga ja sisaldab mitmeid alamsüsteeme:
- Mõõdikute registreerimine.
Iga mõõdikut teenindab oma niit ja see sünkroniseeritakse kanalite kaudu. Oleme saavutanud sünkroniseerimise täpsuse kuni 10 nanosekundit. - Mõõdikute salvestamine
Me valisime, kas kirjutada oma ajajoonete salvestus või kasutada midagi olemasolevat. Andmebaas on vajalik retrospektiivsete andmete jaoks, mida hiljem visualiseeritakse. St selles pole andmeid viivitustest kanalites iga 0,5 millisekundi jooksul või vigade lugemist transportvõrgus, kuid näidikuliiklus on igal liidesel iga 500 millisekundi järel. Lisaks kõrgetele nõuetele platvormide vahelise ühilduvuse ja väikese ressursside kasutuse osas, on meil äärmiselt oluline võimalus andmeid töödelda seal, kus need on salvestatud. See säästab tohutult arvutusressursse. Alates 2016. aastast kasutame selle projekti raames andmebaasi Tarantool ja hetkel ei näe me mingit asendust. Paindlik, optimaalse ressursikasutusega ja rohkem kui adekvaatse tehnilise toe tagamisega. Samuti on Tarantoolis rakendatud GIS moodul. See ei ole küll nii võimas kui PostGIS, kuid meie vajaduste metoodika teatud mõõdikute salvestamiseks, mis on seotud asukohaga (millel on transport), on seda piisavalt. - Mõõdikute visualiseerimine
Siin on kõik suhteliselt lihtne. Võtame andmed salvestusest ja kuvame need kas reaalajas või retrospektiivselt. - Andmete sünkroniseerimine keskse jälgimissüsteemiga.
Keskne jälgimissüsteem võtab andmeid kõikidelt seadmetelt, salvestab need antud retrospektiiviga ja annab need API kaudu üle tellija jälgimissüsteemile. Erinevalt klassikalistest jälgimissüsteemidest, kus "pea" käib ja kogub andmeid — meil on vastupidine skeem. Seadmed saadavad andmeid iseseisvalt, kui side on olemas. See on väga oluline punkt, kuna see võimaldab saada andmeid seadmest nende ajavahemike jooksul, mil see polnud kätte saadav, ja mitte koormata kanaleid ja ressursse, kui seade on kätte saamatu. Keskse jälgimissüsteemina kasutame Influx monitoring serverit. Erinevalt analoogidest oskab see importida retrospektiivseid andmeid (st ajamärgisega, mis erineb mõõdiku saamise hetkest). Kogutud mõõdikud visualiseerib kohandatud Grafana. See standardne tehnoloogiapakk valiti ka, kuna sellel on valmis API integratsioon peaaegu iga tellija jälgimissüsteemiga. - Andmete sünkroniseerimine keskse seadme haldamise süsteemiga.
Seadmisehaldussüsteem rakendab Zero Touch Provisioning (firmware'i värskendamine, konfiguratsioon jne) ja erinevalt monitooringusüsteemist teeb see ainult seadmete probleemide tuvastamist. Need on pardal olevate riistvaralistest valvuritest ja kõigist elutähtsate süsteemide mõõdikest: CPU ja SSD temperatuur, CPU koormus, vaba ruum ja S.M.A.R.T. tervis ketastes. Alamsüsteemi salvestus on samuti rajatud Tarantoolile. See annab meile märgatava kiirusena ajajoonte agregatsioonis tuhandete seadmete vahel ning lahendab täielikult andmete sünkroonimise nende seadmetega. Tarantoolis on sisse ehitatud suurepärane järjekordade ja garanteeritud kohaletoimetamise süsteem. Selle olulise omaduse saime välja pakutuna, suurepärane!
Võrgu juhtimissüsteem
Mis edasi
Praegu on meie kõige nõrgem lüli kesksüsteem monitooringus. See on realiseeritud 99.9% ulatuses standardse tekiga ja sellel on mitmeid puudusi:
- InfluxDB kaotab andmeid toitekatkestuse korral. Üldiselt korjab Klient kiiresti üles kõik, mis seadmetelt tuleb, ja andmebaasis ei ole andmeid, mis oleks vanemad kui 5 minutit, kuid tulevikus võib see osutuda probleemiks.
- Grafanal on mitmeid andmete agregatsiooni ja nende kuvamise sünkroonsuse probleeme. Kõige sagedasem probleem on, kui andmebaasis on ajajoon, mille intervall on 2 sekundit, alates näiteks 00:00:00, kuid Grafana hakkab näitama andmeid agregatsioonis +1 sekundi võrra. Tulemuseks on see, et kasutaja näeb hüplevat graafikut.
- Liigne kood API integreerimiseks kolmandate osapoolte monitooringusüsteemidega. Seda saab teha palju kompaktselt ja loomulikult ringi kirjutada GOsse).
Usun, et olete kõik näinud, milline on Grafana ja ilma minuta teate juba selle probleeme, seetõttu ei tahaks ma postitust pilte täis laadida.
Kokkuvõte
Ma otsustasin teadlikult mitte kirjeldada tehnilisi detaile, vaid kirjeldasin ainult selle süsteemi tugikujundust. Esiteks, et süsteemi tehniliselt täielikult kirjeldada, on vaja veel ühte artiklit. Teiseks, see ei pruugi kaugeltki kõiki huvitada. Kirjutage kommentaarides, milliseid tehnilisi detaile sooviksite teada.
Kui kellelgi on selle artikli piirest küsimusi, võib mulle kirjutada aadressil a.rodin @ qedr.com
Allikas: habr.com
