16 modem, 4 operadore mugikor = Irteerako abiadura 933.45 Mbit/s
Sarrera
Kaixo! Artikulu honek monitorizazio sistema berri bat nola idatzi genuen gure buruari buruzkoa da. Lehendik daudenetatik bereizten da maiztasun handiko metrika sinkronoak lortzeko eta baliabideen kontsumo oso baxua izateagatik. Inkesta-tasa 0.1 milisegundora irits daiteke 10 nanosegundoko metrika arteko sinkronizazio-zehaztasunarekin. Fitxategi bitar guztiek 6 megabyte hartzen dute.
Proiektuari buruz
Produktu zehatz samarra dugu. Irtenbide integral bat sortzen dugu datuen transmisio-kanalen errendimendua eta akatsen tolerantzia laburbiltzeko. Hau da hainbat kanal daudenean, demagun Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Beste zerbait (5 Mbit/s), emaitza kanal egonkor eta azkar bat da, zeinaren abiadura antzeko zerbait izango da. hau: (40+ 30+5)x0.92=75Γ0.92=69 Mbit/s.
Horrelako irtenbideak eskatzen dira kanal baten ahalmena nahikoa ez den kasuetan. Adibidez, garraioa, bideo-zaintza sistemak eta denbora errealeko bideo-streaminga, zuzeneko telebista eta irrati-emankizunen emisioa, telekomunikazio-operadoreen artean Lau Handien ordezkariak soilik dauden eta modem/kanal bateko abiadura nahikoa ez den aldirietako edozein instalazio. .
Arlo horietako bakoitzerako, gailu-lerro bereizi bat ekoizten dugu, baina haien software-zatia ia berdina da eta kalitate handiko monitorizazio-sistema da bere modulu nagusietako bat, produktua ezinezkoa izango litzatekeen ezarpen zuzenik gabe.
Hainbat urtetan zehar, maila anitzeko, bizkorra, plataforma gurutzatua eta monitorizazio sistema arina sortzea lortu genuen. Hau da gure komunitate errespetatuarekin partekatu nahi duguna.
Arazoaren formulazioa
Jarraipen-sistemak funtsezko bi klasetako metrika eskaintzen ditu: denbora errealeko metrika eta beste guztiak. Jarraipen-sistemak baldintza hauek baino ez zituen:
- Maiztasun handiko neurketak denbora errealean eskuratzea eta horiek komunikazioa kudeatzeko sistemara atzerapenik gabe transferitzea.
Maiztasun handia eta metrika ezberdinen sinkronizazioa ez dira garrantzitsuak bakarrik, ezinbestekoak dira datuen transmisio-kanalen entropia aztertzeko. Datu-transmisioko kanal batean batez besteko atzerapena 30 milisegundokoa bada, gainerako neurketen arteko sinkronizazioan akatsak milisegundo bakarreko akatsak ondoriozko kanalaren abiadura % 5 gutxi gorabehera hondatuko du. 1 kanaletan zehar denbora milisegundo 4 okertzen badugu, abiaduraren degradazioa erraz jaitsi daiteke %30era. Gainera, kanaletan entropia oso azkar aldatzen da, beraz, 0.5 milisegundotik behin baino gutxiagotan neurtzen badugu, atzerapen txiki batekin kanal bizkorretan abiadura handiko degradazioa lortuko dugu. Jakina, zehaztasun hori ez da beharrezkoa metrika guztietan eta ez baldintza guztietan. Kanalaren atzerapena 500 milisegundokoa denean, eta horrelakoekin lan egiten dugunean, orduan 1 milisegundoko errorea ia ez da nabarituko. Gainera, bizi-euskarriko sistemaren metriketarako, 2 segundoko nahikoa galdeketa eta sinkronizazio-tasa ditugu, baina monitorizazio-sistemak berak gai izan behar du galdeketa-tasa ultra-altuenekin eta neurgailuen sinkronizazio ultrazehatzekin. - Baliabideen kontsumo minimoa eta pila bakarra.
Amaierako gailua errepideko egoera aztertu edo pertsonen grabazio biometrikoa egin dezakeen barneko konplexu indartsu bat izan daiteke, edo indar bereziko soldadu batek armaduraren azpian daraman palmondo-tamainako taula bakarreko ordenagailua bideoa transmititzeko. denbora errealean komunikazio baldintza txarretan. Hainbat arkitektura eta konputazio-ahalmena izan arren, software pila bera izatea gustatuko litzaiguke. - Aterki arkitektura
Metrikoak amaierako gailuan bildu eta batu behar dira, lokalean gorde eta denbora errealean eta atzera begira bistaratu behar dira. Konexiorik badago, transferitu datuak monitorizazio sistema zentralera. Konexiorik ez dagoenean, bidalketa-ilarak pilatu behar du eta ez du RAM kontsumitu. - Bezeroaren monitorizazio sisteman integratzeko APIa, inork ez duelako monitorizazio sistema asko behar. Bezeroak edozein gailu eta saretako datuak bildu behar ditu monitorizazio bakar batean.
Zer gertatu zen
Dagoeneko ikusgarria den irakurketa luzea ez zamatze aldera, ez ditut monitorizazio-sistema guztien adibide eta neurketak emango. Horrek beste artikulu batera eramango du. Besterik gabe, esango dut ezin izan dugula aurkitu monitorizazio-sistema bat, milisegundo 1 baino gutxiagoko errore batekin aldi berean bi metrika hartzeko gai dena eta berdin funtzionatzen duena, bai ARM arkitekturan 64 MB RAM dituena eta bai x86_64 arkitekturan 32. GB RAM. Hori dela eta, gurea idaztea erabaki dugu, hau guztia egin dezakeena. Hona hemen lortu duguna:
Sare-topologia desberdinetarako hiru kanalen errendimendua laburtzea
Funtsezko metrika batzuen bistaratzea
arkitektura
Golang programazio-lengoaia nagusi gisa erabiltzen dugu, bai gailuan, bai datu-zentroan. Bizitza asko erraztu zuen ataza anitzeko ezarpenarekin eta zerbitzu bakoitzeko fitxategi bitar exekutagarri estatiko bat lortzeko gaitasunarekin. Ondorioz, baliabideak, metodoak eta trafikoa nabarmen aurrezten dugu zerbitzua amaierako gailuetan zabaltzeko, garapen denbora eta kodea arazketa.
Sistema modular printzipio klasikoaren arabera inplementatzen da eta hainbat azpisistema ditu:
- Metrikoen erregistroa.
Neurri bakoitza bere haritik hornitzen da eta kanaletan sinkronizatuta dago. 10 nanosegundorainoko sinkronizazioaren zehaztasuna lortu genuen. - Metrikoen biltegiratzea
Denbora serieetarako gure biltegiratzea idaztea edo jada eskuragarri zegoen zerbait erabiltzea aukeratzen ari ginen. Datu-basea beharrezkoa da ondoren bistaratuko diren atzera begirako datuetarako.Hau da, ez du kanaleko atzerapenei buruzko daturik 0.5 milisegundotik behin edo garraio sareko akatsen irakurketarik, baina interfaze bakoitzean abiadura dago 500 milisegundotik behin. Plataforma gurutzatua eta baliabideen kontsumo txikia izateaz gain, oso garrantzitsua da guretzat prozesatu ahal izatea. datuak gordetzen dira bertan. Horrek baliabide informatiko izugarriak aurrezten ditu. 2016az geroztik Tarantool DBMS erabiltzen ari gara proiektu honetan eta orain arte ez dugu haren ordezkorik ikusten horizontean. Malgua, baliabideen kontsumo optimoarekin, laguntza tekniko egokia baino gehiago. Tarantool-ek GIS modulu bat ere inplementatzen du. Noski, ez da PostGIS bezain indartsua, baina nahikoa da kokapen-neurri batzuk (garraiorako garrantzitsuak) gordetzeko gure zereginetarako. - Neurrien bistaratzea
Hemen dena nahiko erraza da. Biltegiko datuak hartzen ditugu eta denbora errealean edo atzera begira erakusten ditugu. - Datuak monitorizazio sistema zentralarekin sinkronizatzea.
Monitorizazio sistema zentralak gailu guztietako datuak jasotzen ditu, historia zehatz batekin gordetzen ditu eta Bezeroaren monitorizazio sistemara bidaltzen ditu API bidez. Monitorizazio sistema klasikoek ez bezala, zeinetan βburuaβ ibili eta datuak biltzen, kontrako eskema dugu. Gailuek eurek bidaltzen dituzte datuak konexioa dagoenean. Oso puntu garrantzitsua da, gailutik datuak jasotzeko aukera ematen baitu erabilgarri egon ez den denbora-tarteetarako eta kanalak eta baliabideak ez kargatzeko gailua erabilgarri ez dagoen bitartean. Influx monitoring zerbitzaria monitorizazio sistema zentral gisa erabiltzen dugu. Bere analogoek ez bezala, atzera begirako datuak inporta ditzake (hau da, metrikak jaso zirenetik desberdina den denbora-zigilu batekin) Bildutako neurketak Grafanak bistaratzen ditu, fitxategi batekin aldatuta. Pila estandar hau ere aukeratu zen, bezeroen jarraipena egiteko ia edozein sistemarekin API integrazioak prest dituelako. - Datuen sinkronizazioa gailuen kudeaketa sistema zentral batekin.
Gailuak kudeatzeko sistemak Zero Touch Provisioning ezartzen du (firmwarea eguneratzea, konfigurazioa, etab.) eta, monitorizazio sistemak ez bezala, gailu bakoitzeko arazoak soilik jasotzen ditu. Hauek dira barneko hardware-zaintza-zerbitzuen funtzionamenduaren abiarazleak eta bizi-euskarriko sistemen neurketa guztiak: CPU eta SSD tenperatura, CPU karga, espazio librea eta SMART osasuna diskoetan. Azpisistemaren biltegiratzea ere Tarantool-en eraikita dago. Horrek abiadura handia ematen digu denbora serieak milaka gailutan batzeko, eta gailu horiekin datuak sinkronizatzearen arazoa guztiz konpontzen du. Tarantool-ek ilara eta entrega-sistema bikaina du. Ezaugarri garrantzitsu hau kaxatik atera dugu, bikaina!
Sareak kudeatzeko sistema
Zer da hurrengoa
Orain arte, gure katerik ahulena monitorizazio sistema zentrala da. Pila estandar batean % 99.9 inplementatzen da eta hainbat desabantaila ditu:
- InfluxDB-k datuak galtzen ditu energia galtzen denean. Oro har, Bezeroak berehala biltzen du gailuetatik datorren guztia eta datu-baseak berak ez ditu 5 minutu baino zaharragoak diren datuak, baina etorkizunean mingarria izan daiteke.
- Grafanak hainbat arazo ditu datuen agregazioan eta pantailaren sinkronizazioan. Arazorik ohikoena datu-baseak 2 segundoko tartea duen denbora serie bat dauka, esate baterako, 00:00:00etatik hasita, eta Grafana +1 segundotik aurrera datuak batuta erakusten hasten denean. Ondorioz, erabiltzaileak dantza grafiko bat ikusten du.
- Kode kopuru handiegia APIa hirugarrenen monitorizazio sistemekin integratzeko. Askoz trinkoagoa egin daiteke eta noski Go-n berridatzi)
Uste dut denok primeran ikusi duzuela Grafana nolakoa den eta ezagutzen dituzuela ni gabe dituen arazoak, beraz ez dut argazkiz gainkargatuko mezua.
Ondorioa
Nahita ez ditut xehetasun teknikoak deskribatu, sistema honen oinarrizko diseinua soilik deskribatu. Lehenik eta behin, sistema teknikoki guztiz deskribatzeko, beste artikulu bat beharko da. Bigarrenik, denek ez dute horretan interesatuko. Idatzi iruzkinetan zein xehetasun tekniko jakin nahi dituzun.
Norbaitek artikulu honen esparrutik kanpo galderarik izanez gero, idatz diezazukezu a.rodin @ qedr.com helbidera
Iturria: www.habr.com