16 modema, 4 mobilna operatera = Odlazna brzina 933.45 Mbit/s
Uvod
Zdravo! Ovaj članak govori o tome kako smo sami napisali novi sustav nadzora. Razlikuje se od postojećih po sposobnosti dobivanja visokofrekventnih sinkronih metrika i vrlo maloj potrošnji resursa. Brzina anketiranja može doseći 0.1 milisekundu uz točnost sinkronizacije između metrika od 10 nanosekundi. Sve binarne datoteke zauzimaju 6 megabajta.
oko
Imamo dosta specifičan proizvod. Proizvodimo sveobuhvatno rješenje za sažimanje propusnosti i tolerancije na pogreške kanala za prijenos podataka. To je kada postoji nekoliko kanala, recimo Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Nešto drugo (5 Mbit/s), rezultat je jedan stabilan i brz kanal, čija će brzina biti otprilike kao ovo: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Takva rješenja su tražena tamo gdje je kapacitet bilo kojeg kanala nedovoljan. Na primjer, prijevoz, sustavi video nadzora i video streaminga u stvarnom vremenu, prijenos televizijskih i radijskih prijenosa uživo, bilo kakvi prigradski objekti u kojima su među telekom operaterima samo predstavnici velike četvorke, a brzina na jednom modemu/kanalu nije dovoljna .
Za svako od ovih područja proizvodimo zasebnu liniju uređaja, no njihov softverski dio je gotovo isti te je kvalitetan nadzorni sustav jedan od njegovih glavnih modula bez čije pravilne implementacije proizvod ne bi bio moguć.
Tijekom nekoliko godina uspjeli smo stvoriti višerazinski, brz, višeplatformski i lagan sustav nadzora. To je ono što želimo podijeliti s našom poštovanom zajednicom.
Formuliranje problema
Sustav praćenja pruža metriku dviju fundamentalno različitih klasa: metriku u stvarnom vremenu i sve ostale. Sustav nadzora imao je samo sljedeće zahtjeve:
- Visokofrekventno sinkrono prikupljanje metrika u stvarnom vremenu i njihov prijenos u sustav upravljanja komunikacijom bez odgode.
Visoka frekvencija i sinkronizacija različitih metrika nije samo važna, već je vitalna za analizu entropije kanala prijenosa podataka. Ako je u jednom kanalu prijenosa podataka prosječno kašnjenje 30 milisekundi, tada će pogreška u sinkronizaciji između preostalih metrika od samo jedne milisekunde dovesti do degradacije brzine rezultirajućeg kanala za približno 5%. Ako pogrešno odredimo vrijeme za 1 milisekundu na 4 kanala, degradacija brzine može lako pasti na 30%. Osim toga, entropija se u kanalima mijenja vrlo brzo, pa ako je mjerimo rjeđe od jednom svakih 0.5 milisekundi, na brzim kanalima s malim kašnjenjem dobit ćemo brzu degradaciju. Naravno, takva točnost nije potrebna za sve metrike i ne u svim uvjetima. Kada je kašnjenje u kanalu 500 milisekundi, a mi radimo s takvima, tada se pogreška od 1 milisekunde gotovo neće primijetiti. Također, za metriku sustava za održavanje života imamo dovoljno stope anketiranja i sinkronizacije od 2 sekunde, ali sam sustav za praćenje mora moći raditi s ultra-visokim stopama anketiranja i ultra-preciznom sinkronizacijom metrike. - Minimalna potrošnja resursa i jedan stog.
Krajnji uređaj može biti ili snažan ugrađeni kompleks koji može analizirati situaciju na cesti ili provoditi biometrijsko snimanje ljudi ili jednopločno računalo veličine dlana koje vojnik specijalnih postrojbi nosi ispod oklopa za prijenos videa u stvarnom vremenu u lošim komunikacijskim uvjetima. Unatoč tolikoj raznolikosti arhitektura i računalne snage, željeli bismo imati isti softverski skup. - Kišobran arhitektura
Mjerni podaci moraju se prikupljati i agregirati na krajnjem uređaju, imati lokalnu pohranu i vizualizirati u stvarnom vremenu i retrospektivno. Ako postoji veza, prenesite podatke u središnji nadzorni sustav. Kada nema veze, red čekanja za slanje trebao bi se nakupljati i ne bi trošio RAM. - API za integraciju u sustav nadzora kupca, jer nitko ne treba mnogo sustava za nadzor. Kupac mora prikupljati podatke s bilo kojeg uređaja i mreže u jedinstveni nadzor.
Što se dogodilo
Kako ne bih opterećivao ionako impresivno čitanje, neću navoditi primjere i mjerenja svih sustava nadzora. Ovo će dovesti do drugog članka. Samo ću reći da nismo uspjeli pronaći sustav za praćenje koji je sposoban uzimati dvije metrike istovremeno s pogreškom manjom od 1 milisekunde i koji jednako učinkovito radi i na arhitekturi ARM sa 64 MB RAM-a i na arhitekturi x86_64 sa 32 GB RAM-a. Stoga smo odlučili napisati vlastitu, koja sve to može. Evo što smo dobili:
Sažimanje propusnosti triju kanala za različite topologije mreže
Vizualizacija nekih ključnih metrika
arhitektura
Koristimo Golang kao glavni programski jezik, kako na uređaju tako i u podatkovnom centru. Uvelike je pojednostavio život svojom implementacijom multitaskinga i mogućnošću dobivanja jedne statički povezane izvršne binarne datoteke za svaku uslugu. Kao rezultat toga, značajno štedimo u resursima, metodama i prometu za implementaciju usluge na krajnje uređaje, vrijeme razvoja i otklanjanje pogrešaka koda.
Sustav je izveden po klasičnom modularnom principu i sastoji se od nekoliko podsustava:
- Registracija metrike.
Svaku metriku opslužuje vlastita nit i sinkronizira se preko kanala. Uspjeli smo postići točnost sinkronizacije do 10 nanosekundi. - Pohrana metrike
Birali smo između pisanja vlastite pohrane za vremenske serije ili korištenja nečega što je već bilo dostupno. Baza je potrebna za retrospektivne podatke koji podliježu naknadnoj vizualizaciji, odnosno ne sadrži podatke o kašnjenjima u kanalu svakih 0.5 milisekundi ili očitanjima grešaka u transportnoj mreži, već ima brzinu na svakom sučelju svakih 500 milisekundi. Uz visoke zahtjeve za više platformi i nisku potrošnju resursa, iznimno nam je važno biti u mogućnosti procesirati. podaci su tamo gdje su pohranjeni. Time se štede ogromni računalni resursi. U ovom projektu koristimo Tarantool DBMS od 2016. godine i do sada ne vidimo zamjenu za njega na horizontu. Fleksibilan, s optimalnom potrošnjom resursa, više nego adekvatnom tehničkom podrškom. Tarantool također implementira GIS modul. Naravno, nije moćan kao PostGIS, ali je dovoljan za naše zadatke pohranjivanja nekih lokacijskih metrika (relevantnih za transport). - Vizualizacija metrike
Ovdje je sve relativno jednostavno. Uzimamo podatke iz skladišta i prikazujemo ih u stvarnom vremenu ili retrospektivno. - Sinkronizacija podataka sa centralnim nadzornim sustavom.
Centralni nadzorni sustav prima podatke sa svih uređaja, pohranjuje ih s određenom poviješću i putem API-ja šalje u nadzorni sustav Korisnika. Za razliku od klasičnih sustava nadzora, u kojima “glava” hoda okolo i skuplja podatke, imamo suprotnu shemu. Sami uređaji šalju podatke kada postoji veza. Ovo je vrlo važna točka, jer vam omogućuje primanje podataka s uređaja za one vremenske periode tijekom kojih nisu bili dostupni i ne opterećuju kanale i resurse dok je uređaj nedostupan. Kao središnji nadzorni sustav koristimo Influx monitoring server. Za razliku od svojih analoga, može uvoziti retrospektivne podatke (to jest, s vremenskim žigom koji se razlikuje od trenutka prijema metrike).Prikupljene metrike vizualizira Grafana, modificirana datotekom. Ovaj standardni skup također je odabran jer ima gotove API integracije s gotovo svim sustavima za praćenje korisnika. - Sinkronizacija podataka sa središnjim sustavom upravljanja uređajima.
Sustav za upravljanje uređajima implementira Zero Touch Provisioning (ažuriranje firmvera, konfiguracije itd.) i, za razliku od sustava za nadzor, prima samo probleme po uređaju. Ovo su okidači za rad ugrađenih hardverskih nadzornih usluga i svih metrika sustava za održavanje života: CPU i SSD temperatura, CPU opterećenje, slobodni prostor i SMART zdravlje na diskovima. Podsustav za pohranu također je izgrađen na Tarantoolu. To nam daje značajnu brzinu u agregiranju vremenskih serija na tisućama uređaja, a također u potpunosti rješava problem sinkronizacije podataka s tim uređajima. Tarantool ima odličan sustav čekanja i zajamčene isporuke. Dobili smo ovu važnu značajku iz kutije, odlično!
Sustav upravljanja mrežom
što dalje
Zasad nam je najslabija karika centralni nadzorni sustav. Implementiran je 99.9% na standardnom stogu i ima brojne nedostatke:
- InfluxDB gubi podatke kada nestane struje. Kupac u pravilu promptno prikuplja sve što dolazi s uređaja, a sama baza podataka ne sadrži podatke starije od 5 minuta, no u budućnosti to može postati muka.
- Grafana ima niz problema s agregacijom podataka i sinkronizacijom svog prikaza. Najčešći problem je kada baza sadrži vremensku seriju s intervalom od 2 sekunde počevši od recimo 00:00:00, a Grafana počinje prikazivati podatke agregirano od +1 sekunde. Kao rezultat, korisnik vidi plesni grafikon.
- Pretjerana količina koda za integraciju API-ja sa sustavima za nadzor trećih strana. Može se učiniti mnogo kompaktnijim i naravno prepisati u Go)
Mislim da ste svi savršeno vidjeli kako Grafana izgleda i znate njene probleme i bez mene, pa neću pretrpavati post slikama.
Zaključak
Namjerno nisam opisao tehničke detalje, već sam opisao samo osnovni dizajn ovog sustava. Prvo, za tehnički potpuni opis sustava bit će potreban još jedan članak. Drugo, neće svi biti zainteresirani za ovo. Napišite u komentarima koje tehničke detalje želite znati.
Ako netko ima pitanja izvan opsega ovog članka, može mi pisati na a.rodin @ qedr.com
Izvor: www.habr.com