16 modemų, 4 korinio ryšio operatoriai = Siuntimo greitis 933.45 Mbit/s
įvedimas
Sveiki! Šis straipsnis yra apie tai, kaip sukūrėme sau naują stebėjimo sistemą. Jis skiriasi nuo esamų savo galimybe gauti aukšto dažnio sinchroninius rodiklius ir labai mažu išteklių suvartojimu. Apklausos greitis gali siekti 0.1 milisekundės, o sinchronizavimo tikslumas tarp metrikų yra 10 nanosekundžių. Visi dvejetainiai failai užima 6 megabaitus.
apie
Turime gana specifinį produktą. Gaminame išsamų sprendimą duomenų perdavimo kanalų pralaidumui ir gedimams apibendrinti. Tai kai yra keli kanalai, tarkime Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Dar kažkas (5 Mbit/s), rezultatas yra vienas stabilus ir greitas kanalas, kurio greitis bus maždaug toks. tai: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tokie sprendimai yra paklausūs ten, kur vieno kanalo pajėgumai yra nepakankami. Pavyzdžiui, transportas, vaizdo stebėjimo sistemos ir vaizdo transliacija realiuoju laiku, tiesioginės televizijos ir radijo transliacijos, bet kokie priemiesčio įrenginiai, kur tarp telekomunikacijų operatorių yra tik Didžiojo ketverto atstovai, o greičio per vieną modemą / kanalą nepakanka. .
Kiekvienai iš šių sričių gaminame atskirą įrenginių liniją, tačiau jų programinė dalis beveik ta pati ir kokybiška stebėjimo sistema yra vienas pagrindinių jos modulių, be kurio teisingo įdiegimo produktas nebūtų įmanomas.
Per kelerius metus mums pavyko sukurti kelių lygių, greitą, kelių platformų ir lengvą stebėjimo sistemą. Tuo norime pasidalinti su mūsų gerbiamąja bendruomene.
Problemos teiginys
Stebėjimo sistema pateikia dviejų iš esmės skirtingų klasių metriką: realaus laiko metriką ir visas kitas. Stebėjimo sistemai buvo keliami tik šie reikalavimai:
- Aukšto dažnio sinchroninis realaus laiko metrikų gavimas ir jų perkėlimas į komunikacijos valdymo sistemą nedelsiant.
Didelis dažnis ir skirtingų metrikų sinchronizavimas yra ne tik svarbus, bet ir gyvybiškai svarbus analizuojant duomenų perdavimo kanalų entropiją. Jei viename duomenų perdavimo kanale vidutinė delsa yra 30 milisekundžių, tai tik vienos milisekundės metrikos sinchronizavimo klaida sukels gauto kanalo greičio sumažėjimą maždaug 5%. Jei 1 kanaluose nustatysime laiką 4 milisekunde, greičio sumažėjimas gali lengvai sumažėti iki 30%. Be to, entropija kanaluose kinta labai greitai, todėl matuojant ją rečiau nei kartą per 0.5 milisekundės, greituose kanaluose su nedideliu uždelsimu gausime didelės spartos degradaciją. Žinoma, toks tikslumas reikalingas ne visoms metrikoms ir ne visomis sąlygomis. Kai kanalo delsa yra 500 milisekundžių, o mes su tokiais dirbame, tada 1 milisekundės paklaida bus beveik nepastebima. Taip pat gyvybės palaikymo sistemos metrikai turime pakankamai 2 sekundžių apklausos ir sinchronizavimo greičio, tačiau pati stebėjimo sistema turi dirbti su itin dideliais apklausų rodikliais ir itin tiksliai sinchronizuoti metriką. - Minimalus išteklių suvartojimas ir vienas krūvas.
Galutinis įrenginys gali būti galingas borto kompleksas, galintis analizuoti situaciją kelyje arba atlikti biometrinius žmonių įrašus, arba delno dydžio vienos plokštės kompiuteris, kurį specialiųjų pajėgų karys nešioja po šarvais, kad galėtų perduoti vaizdo įrašą. realiu laiku esant blogoms ryšio sąlygoms. Nepaisant tokios architektūros ir skaičiavimo galios įvairovės, norėtume turėti tą patį programinės įrangos paketą. - Skėčių architektūra
Metrika turi būti renkama ir kaupiama galutiniame įrenginyje, saugoma vietoje ir vizualizuojama realiuoju laiku bei retrospektyviai. Jei yra ryšys, perkelkite duomenis į centrinę stebėjimo sistemą. Kai nėra ryšio, siuntimo eilė turėtų kauptis ir nevartoti RAM. - API integracijai į kliento stebėjimo sistemą, nes daug stebėjimo sistemų niekam nereikia. Klientas turi rinkti duomenis iš bet kokių įrenginių ir tinklų į vieną stebėjimą.
Kas nutiko
Kad neapsunkinčiau ir taip įspūdingo ilgo skaitymo, nepateiksiu visų stebėjimo sistemų pavyzdžių ir matavimų. Tai paskatins kitą straipsnį. Aš tik pasakysiu, kad mums nepavyko rasti stebėjimo sistemos, galinčios vienu metu gauti dvi metrikas su mažesne nei 1 milisekundės paklaida ir kuri vienodai efektyviai veiktų tiek ARM architektūroje su 64 MB RAM, tiek x86_64 architektūra su 32. GB RAM. Todėl nusprendėme parašyti savo, kuri gali visa tai padaryti. Štai ką gavome:
Apibendrinant trijų kanalų pralaidumą skirtingoms tinklo topologijoms
Kai kurių pagrindinių metrikų vizualizacija
Architektūra
Mes naudojame Golang kaip pagrindinę programavimo kalbą tiek įrenginyje, tiek duomenų centre. Tai labai supaprastino gyvenimą, nes įdiegtas daugiafunkcinis darbas ir galimybė gauti vieną statiškai susietą dvejetainį vykdomąjį failą kiekvienai paslaugai. Dėl to žymiai sutaupome išteklių, metodų ir srauto diegdami paslaugą galutiniuose įrenginiuose, kūrimo laiką ir kodo derinimą.
Sistema įgyvendinama pagal klasikinį modulinį principą ir susideda iš kelių posistemių:
- Metrikos registracija.
Kiekviena metrika aptarnaujama pagal atskirą giją ir sinchronizuojama kanaluose. Mums pavyko pasiekti iki 10 nanosekundžių sinchronizavimo tikslumą. - Metrikos saugojimas
Pasirinkome rašyti savo saugyklą laiko eilutėms arba naudoti ką nors, kas jau buvo prieinama. Duomenų bazė reikalinga retrospektyviems duomenims, kurie vėliau vizualizuojami, tai yra, joje nėra duomenų apie kanalo vėlavimus kas 0.5 milisekundės arba klaidų rodmenis transporto tinkle, tačiau kiekvienoje sąsajoje yra greitis kas 500 milisekundžių. Be aukštų kelių platformų reikalavimų ir mažo išteklių suvartojimo, mums nepaprastai svarbu mokėti apdoroti. duomenys yra ten, kur jie saugomi. Taip sutaupomi didžiuliai skaičiavimo ištekliai. Šiame projekte Tarantool DBVS naudojame nuo 2016 m. ir kol kas nematome jo pakeitimo. Lankstus, optimalus išteklių suvartojimas, daugiau nei tinkama techninė pagalba. Tarantool taip pat įdiegia GIS modulį. Žinoma, jis nėra toks galingas kaip PostGIS, bet jo pakanka mūsų užduotims saugoti kai kurias su vieta susijusias metrikas (susijusias su transportu). - Metrikos vizualizacija
Čia viskas palyginti paprasta. Duomenis paimame iš sandėlio ir rodome realiu laiku arba retrospektyviai. - Duomenų sinchronizavimas su centrine stebėjimo sistema.
Centrinė stebėjimo sistema gauna duomenis iš visų įrenginių, išsaugo juos su nurodyta istorija ir siunčia į Kliento stebėjimo sistemą per API. Skirtingai nuo klasikinių stebėjimo sistemų, kuriose „galva“ vaikšto ir renka duomenis, mes turime priešingą schemą. Patys įrenginiai siunčia duomenis, kai yra ryšys. Tai labai svarbus dalykas, nes leidžia gauti duomenis iš įrenginio tuo laikotarpiu, kai jis nebuvo pasiekiamas, ir neįkelti kanalų bei išteklių, kol įrenginys nepasiekiamas. Mes naudojame Influx stebėjimo serverį kaip centrinę stebėjimo sistemą. Skirtingai nuo analogų, jis gali importuoti retrospektyvius duomenis (tai yra su kitokia laiko žyma nei metrikos gavimo momento) Surinktus rodiklius vizualizuoja Grafana, modifikuoja failu. Šis standartinis rinkinys taip pat buvo pasirinktas, nes jame yra paruoštos API integracijos su beveik bet kokia klientų stebėjimo sistema. - Duomenų sinchronizavimas su centrine įrenginių valdymo sistema.
Įrenginių valdymo sistema įgyvendina Zero Touch Provisioning (atnaujinama programinė įranga, konfigūracija ir kt.) ir, skirtingai nei stebėjimo sistema, gauna tik problemas kiekvienam įrenginiui. Tai yra įtaisytosios aparatinės įrangos stebėjimo paslaugų ir visų gyvybę palaikančių sistemų metrikų veikimo paleidikliai: procesoriaus ir SSD temperatūra, procesoriaus apkrova, laisva vieta ir SMART būklė diskuose. Posistemio saugykla taip pat sukurta Tarantool. Tai suteikia mums didelį greitį kaupiant laiko eilutes tūkstančiuose įrenginių ir visiškai išsprendžia duomenų sinchronizavimo su šiais įrenginiais problemą. Tarantool turi puikią eilių ir garantuoto pristatymo sistemą. Išimėme šią svarbią funkciją, puiku!
Tinklo valdymo sistema
Kas toliau?
Kol kas silpniausia mūsų grandis – centrinė stebėjimo sistema. Jis įdiegtas 99.9% standartinio krūvos ir turi keletą trūkumų:
- InfluxDB praranda duomenis, kai dingsta maitinimas. Paprastai Klientas operatyviai surenka viską, kas ateina iš įrenginių, o pačioje duomenų bazėje nėra senesnių nei 5 minutes duomenų, tačiau ateityje tai gali tapti kančia.
- „Grafana“ turi nemažai problemų, susijusių su duomenų kaupimu ir ekrano sinchronizavimu. Dažniausia problema yra tada, kai duomenų bazėje yra laiko eilutė su 2 sekundžių intervalu, pradedant, tarkime, nuo 00:00:00, o „Grafana“ pradeda rodyti apibendrintus duomenis nuo +1 sekundės. Dėl to vartotojas mato šokių grafiką.
- Per daug kodo API integravimui su trečiųjų šalių stebėjimo sistemomis. Jį galima padaryti daug kompaktiškesnį ir, žinoma, perrašyti Go)
Manau, jūs visi puikiai matėte, kaip atrodo Grafana, ir žinote jos problemas be manęs, todėl neperkrausiu įrašo nuotraukomis.
išvada
Sąmoningai neaprašiau techninių detalių, o aprašiau tik pagrindinį šios sistemos dizainą. Pirma, norint techniškai visiškai apibūdinti sistemą, reikės dar vieno straipsnio. Antra, ne visiems tai bus įdomu. Komentaruose parašykite kokias technines detales norėtumėte sužinoti.
Jei kas nors turi klausimų, kurie nepatenka į šį straipsnį, galite parašyti man adresu a.rodin @ qedr.com
Šaltinis: www.habr.com