Veel monitorimissüsteeme

16 modemid, 4 mobiilioperaatorit = Väljaminekukiirus 933,45 Mbit/s

Sissejuhatus

Tere! See artikkel räägib sellest, kuidas me lasime endale luua uue monitorimissüsteemi. See erineb olemasolevatest selle poolest, et see võimaldab kõrge sagedusega sünkroonselt mõõtmeid kätte saada ning tarbib väga vähe ressursse. Küsimise sagedus võib ulatuda 0,1 millisekundini ja sünkroniseerimise täpsus mõõtmiste vahel on 10 nanosekundit. Kõik binaarfailid võtavad 6 megabaiti.

Projektist

Meie toode on üsna spetsiifiline. Me toodame kompleksset lahendust, et kokku liita andmeedastuse kanalite läbilaskevõime ja rikke kaitse. See tähendab, et on mitu kanalit, näiteks Operaator1 (40 Mbit/s) + Operaator2 (30 Mbit/s) + Midagi veel (5 Mbit/s), mille tulemusena tekib üks stabiilne ja kiire kanal, mille kiirus on ligikaudu järgmine: (40+30+5)x0,92=75×0,92=69 Mbit/s.

Need for such solutions arises in situations where the capacity of a single channel is insufficient. For example, transportation, video surveillance systems, real-time video streaming, broadcasting live television and radio programs, and any remote locations where only representatives of the major telecommunications players are available, resulting in inadequate speeds on a single modem/channel.
For each of these areas, we produce a separate line of devices, although the software component is nearly identical, with a quality monitoring system being one of its key modules, without which the product would be impossible.

Over the years, we have developed a multi-level, fast, cross-platform, and lightweight monitoring system. This is something we wish to share with the esteemed community.

Ülesande seadmine

The monitoring system provides metrics of two fundamentally different classes: real-time metrics and all others. The system had only the following requirements:

1. High-frequency synchronous acquisition of real-time metrics and their transmission to the communication management system without delays.
   Kõrge sagedus ja erinevate mõõdikute sünkroniseerimine ei ole mitte lihtsalt oluline, vaid eluliselt vajalik andmeedastuskanalite entropia analüüsimiseks. Kui ühe andmeedastuskanali keskmine viivitus on 30 millisekundit, siis ühekordne ühe millisekundi sünkroniseerimisviga teiste mõõdikute vahel toob kaasa ligikaudu 5% võrgu kanali kiiruslanguse. Kui me teeme 1 millisekundi sünkroniseerimisvea neljas kanalis, võib kiirus langeva hindamine kergesti langeda kuni 30%. Peale selle muutub entropia kanalites väga kiiresti, seega, kui me mõõdame seda harvem kui üks kord 0,5 millisekundi jooksul, siis kiiretel kanalitel väikese viivitusega saame me tõsise kiiruslanguse. Loomulikult ei ole selline täpsus vajalik kõigi mõõdikute ja mitte kõikides tingimustes. Kui kanali viivitus on 500 millisekundit, millega me tõepoolest kokku puutume, siis 1 millisekundi tõrge ei paista peaaegu silma. Samuti, elutähtsate süsteemide mõõdikute jaoks on meil piisav jaotusfrequentse ja sünkroniseerimine 2 sekundi jooksul, kuid iseenda jälgimisseade peab suutma töötada äärmiselt kõrgete mõõtmise sageduste ja äärmiselt täpse mõõdikute sünkroniseerimisega.
2. Minimaalne ressursikasutus ja ühtne virna.
   Lõppseade võib olla kas võimas pardakompleks, mis analüüsib teedeolusid või viib läbi bio-meetrilist andmete kogumist, või siis peopesa suurune arvuti, mida kannab eriüksuse sõdur, et edastada reaalajas videot halva ühenduse tingimustes. Sellise arhitektuuride ja arvutusvõimekuse mitmekesisuse juures tahaksime, et meil oleks ühtne tarkvarakuhja.
3. Katusarhitektuur
   Mõõdikud peavad olema kogutud ja koondatud lõppseadmest, omama kohalikku andmesalvestust ning visualiseerimist reaalajas ja retrospektiivselt. Kui ühendus on olemas, tuleb andmed edastada keskse monitoringu süsteemi. Kui ühendust pole, peab edastamise järjekord kogunema ja mitte tarbima operatiivmälu.
4. API integratsiooniks kliendi monitoringu süsteemiga, kuna kellelegi ei ole vaja palju monitoringu süsteeme. Klient peab koguma andmeid igasugustelt seadmetelt ja võrkudelt ühte monitooringusse.

Mis välja tuli

Kuna mitte koormata juba niigi mahukat teksti, ei hakka ma tooma näiteid ega mõõte kõikidest jälgimissüsteemidest. See tooks kaasa veel ühe artikli. Ütlen lihtsalt, et me ei leidnud ühtegi jälgimissüsteemi, mis suudaks samal ajal mõõta kahte metoodikat täpsusega alla ühe millisekundi ja töötaks sama tõhusalt nii ARM-architectuuri 64MB RAM-iga kui ka x86_64 architectuuri 32GB RAM-iga. Seetõttu otsustasime kirjutada oma süsteemi, mis oskab kõike seda teha. Siin on, mida me saavutasime:

Kolme kanali läbilaskevõime summeerimine erineva võrgu topoloogia jaoks

Mõnede võtmemõõdikute visualiseerimine

Arhitektuur

Peamise programmeerimiskeelena nii seadmes kui ka andmekeskuses kasutame Go keelt. Selle mitmeülesandega teostus on oluliselt lihtsustanud elu ja võimaldanud iga teenuse jaoks saada ühe staatiliselt lingitud käivitatava binaarfaili. Selle tulemuseks on märkimisväärne ressursi, meetodite ja teenuse paigutamise liikide kokkuhoid, samuti arendamise ja koodi silumisaja kokkuhoid.

Süsteem tugineb klassikalisele modulaarsele põhimõttele ja sisaldab mitmeid alam-süsteeme:

1. Mõõdikute registreerimine.
   Iga mõõdikut teenindab oma voog ning need süsynhroniseeritakse kanalite kaudu. Oleme saavutanud süsinhroniseerimise täpsuse kuni 10 nanossekundi.
2. Mõõdikute säilitamine
   Me valisime omavahel, kas kirjutada oma ajasüsteemi andmehoidla või kasutada midagi olemasolevat. Andmebaas on vajalik tagasivaate andmete jaoks, mida hiljem visualiseeritakse. St, selles ei ole andmeid kanalite viivituste kohta iga 0,5 millisekundi või veateadete kohta transpordivõrgus, vaid on kiirus igal liidese puhul iga 500 millisekundi järel. Lisaks kõrgetele nõudmistele platvormidevahelisele ühilduvusele ja madalale ressursikasutusele, on meie jaoks äärmiselt oluline, et saaksime andmeid töödelda seal, kus nad asuvad. See säästab tohutult arvutusressursse. Alates 2016. aastast oleme kasutnud Tarantooli andmebaasi käesolevas projektis ja ei näe hetkel vahetusohtu. Paindlik, optimaalse ressursikanatsemisega, ning enam kui piisava tehnilise toe tagamisega. Samuti on Tarantoolis rakendatud GIS moodul. Kuigi see ei ole nii võimas kui PostGIS, piisab sellest meie jaoks, et salvestada teatud asukohta seotud mõõdikuid (relevantne transportimiseks).
3. Mõõdikute visualiseerimine
   Siin on kõik suhteliselt lihtne. Võtame andmed andmehoidlast ja näitame neid kas reaalajas või tagasivaates.
4. Andmete sünkroniseerimine keskse monitoorimisse süsteemiga.
   Keskne monitoorimissüsteem võtab andmeid kõikidelt seadmetelt, talletab neid määratud ajalooga ja edastab API kaudu kliendi monitoorimisse süsteemi. Erinevalt klassikalistest monitoorimissüsteemidest, kus "pea" käib ja kogub andmeid — meil on vastupidine skeem. Seadmed saadavad andmeid olenemata ühenduse olemasolust. See on väga oluline aspekt, kuna see võimaldab saada andmeid seadmetelt ka siis, kui need olid väljas, ilma et kanaleid ja ressursse koormataks ajal, mil seade on mittekaubanduslik. Keskse monitoorimissüsteemina kasutame Influx monitoorimiserverit. Erinevalt analoogidest suudab see importida ajaloolisi andmeid (st ajamargiga, mis erineb mõõtmise hetkest). Kogutud mõõtmisi visualiseerib neid kohandatud Grafana. See standardne virn valiti ka seetõttu, et sellel on valmis API integreerimine praktiliselt igasse kliendi monitoorimisse süsteemi.
5. Andmete sünkroniseerimine keskse seadmete juhtimise süsteemiga.
   Seadme haldussüsteem rakendab Zero Touch Provisioning (firmware'i värskendamine, konfiguratsioon jne) ja erinevalt jälgimisse systému, saab see ainult seadmete probleemidest. Need on pardal olevate riistvarateenuste äratused ja kõik elutähtsad süsteemide meetrikad: CPU ja SSD temperatuur, CPU koormus, vaba ruum ja S.M.A.R.T tervis ketastel. Alam-süsteemi salvestus on samuti üles ehitatud Tarantoolile. See tagab meile märkimisväärse kiirus ajaveergude kogumisel tuhandest seadmest ning lahendab täielikult andmete sünkroonimise nende seadmetega. Tarantool sisaldab suurepärast järjekorrateenust ja tagatud kohaletoimetamist. Selle olulise funktsiooni saime pakendis, suurepärane!

Võrgu haldussüsteem

Mis edasi

Praegu on meie kõige nõrgem lüli keskne jälgimissüsteem. See on rakendatud 99,9% ulatuses tavalise tehnoloogia stack'il ja tal on mitu puudust:

1. InfluxDB kaotab andmeid, kui toide katkeb. Üldiselt pöördub klient kiiresti tagasi kõikide seadmetelt saadud andmete juurde ja andmebaasis pole andmeid, mis oleks vanemad kui 5 minutit, kuid tulevikus võib see muutuda probleemiks.
2. Grafana'il on mitmeid probleem, mis on seotud andmete agregatsiooni ja sünkroonimisega nende kuvamisel. Kõige levinum probleem on see, kui andmebaasis on ajarežiim kahe sekundi intervalliga, alustades ütleme kell 00:00:00, ja Grafana hakkab näitama andmeid agregaadina +1 sekundi pealt. Tulemusena näeb kasutaja tantsivat graafikut.
3. Liigne kood API integratsiooniks kolmandate osapoolte jälgimissüsteemidega. Seda saaks teha palju kompaktsemalt ja muidugi kirjutada Go'sse.)

Ma usun, et olete kõik näinud, kuidas Grafana välja näeb ja teate ilma minuta selle probleeme, seega ei hakka ma postitust piltidega üle koormama.

Kokkuvõte

Otsustasin tehnilisi detaile mitte kirja panna, vaid kirjeldada ainult toetavat disaini seda süsteemi. Esiteks, et süsteemi tehniliselt täielikult kirjeldada, on vaja veel ühte artiklit. Teiseks, kaugel kõigile see ei pruugi huvi pakkuda. Kirjutage kommentaaridesse, milliseid tehnilisi detaile sooviksite teada.

Kui kellelgi tekib selle artikli väljaspool küsimusi, võib mulle kirjutada aadressil a.rodin @ qedr.com

Allikas: habr.com