16 modemuri, 4 operatori celulari = Viteza de iesire 933.45 Mbit/s
Introducere
Buna ziua! Acest articol este despre modul în care am scris un nou sistem de monitorizare pentru noi înșine. Se deosebește de cele existente prin capacitatea sa de a obține metrici sincrone de înaltă frecvență și un consum foarte scăzut de resurse. Rata de sondare poate ajunge la 0.1 milisecunde cu o precizie de sincronizare între valori de 10 nanosecunde. Toate fișierele binare ocupă 6 megaocteți.
Despre proiect
Avem un produs destul de specific. Producem o soluție cuprinzătoare pentru a rezuma debitul și toleranța la erori a canalelor de transmisie a datelor. Acesta este atunci când există mai multe canale, să spunem Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Altceva (5 Mbit/s), rezultatul este un canal stabil și rapid, a cărui viteză va fi ceva de genul aceasta: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Astfel de soluții sunt solicitate acolo unde capacitatea oricărui canal este insuficientă. De exemplu, transport, sisteme de supraveghere video și streaming video în timp real, difuzare de emisiuni de televiziune și radio în direct, orice facilități suburbane unde printre operatorii de telecomunicații sunt doar reprezentanți ai celor patru mari și viteza pe un singur modem/canal nu este suficientă .
Pentru fiecare dintre aceste zone, producem o linie separată de dispozitive, dar partea lor de software este aproape aceeași și un sistem de monitorizare de înaltă calitate este unul dintre modulele sale principale, fără implementarea corectă a căruia produsul nu ar fi posibil.
Pe parcursul mai multor ani, am reușit să creăm un sistem de monitorizare pe mai multe niveluri, rapid, multi-platformă și ușor. Acesta este ceea ce vrem să împărtășim cu comunitatea noastră respectată.
Declarație de problemă
Sistemul de monitorizare furnizează metrici din două clase fundamental diferite: metrici în timp real și toate celelalte. Sistemul de monitorizare avea doar următoarele cerințe:
- Achiziția sincronă de înaltă frecvență a metricilor în timp real și transferul lor către sistemul de management al comunicațiilor fără întârziere.
Frecvența înaltă și sincronizarea diferitelor metrici nu sunt doar importante, ci sunt vitale pentru analiza entropiei canalelor de transmisie a datelor. Dacă într-un canal de transmisie de date întârzierea medie este de 30 de milisecunde, atunci o eroare de sincronizare între valorile rămase de doar o milisecundă va duce la degradarea vitezei canalului rezultat cu aproximativ 5%. Dacă greșim sincronizarea cu 1 milisecundă pe 4 canale, degradarea vitezei poate scădea cu ușurință la 30%. În plus, entropia în canale se modifică foarte repede, așa că dacă o măsurăm mai puțin de o dată la 0.5 milisecunde, pe canalele rapide cu o mică întârziere vom obține degradarea la viteză mare. Desigur, o astfel de acuratețe nu este necesară pentru toate valorile și nu în toate condițiile. Când întârzierea canalului este de 500 de milisecunde și lucrăm cu acestea, atunci o eroare de 1 milisecundă nu va fi aproape vizibilă. De asemenea, pentru valorile sistemului de susținere a vieții, avem suficiente rate de interogare și sincronizare de 2 secunde, dar sistemul de monitorizare în sine trebuie să poată funcționa cu rate de sondare ultra-înalte și sincronizare ultra-preciză a metricilor. - Consum minim de resurse și o singură stivă.
Dispozitivul final poate fi fie un complex puternic la bord, care poate analiza situația de pe drum sau poate efectua înregistrarea biometrică a oamenilor, fie un computer cu o singură placă de dimensiunea palmei pe care un soldat al forțelor speciale îl poartă sub armura pentru a transmite videoclipuri. în timp real în condiții proaste de comunicare. În ciuda unei asemenea varietăți de arhitecturi și putere de calcul, ne-am dori să avem aceeași stivă de software. - Arhitectura umbrelă
Valorile trebuie colectate și agregate pe dispozitivul final, stocate local și vizualizate în timp real și retroactiv. Dacă există o conexiune, transferați datele către sistemul central de monitorizare. Când nu există nicio conexiune, coada de expediere ar trebui să se acumuleze și să nu consume RAM. - API pentru integrarea în sistemul de monitorizare al clientului, deoarece nimeni nu are nevoie de multe sisteme de monitorizare. Clientul trebuie să colecteze date de pe orice dispozitiv și rețele într-o singură monitorizare.
Ce s-a întâmplat
Pentru a nu îngreuna citirea deja impresionantă, nu voi da exemple și măsurători ale tuturor sistemelor de monitorizare. Acest lucru va duce la un alt articol. Voi spune doar că nu am reușit să găsim un sistem de monitorizare care să fie capabil să preia două metrici simultan cu o eroare de mai puțin de 1 milisecundă și care să funcționeze la fel de eficient atât pe arhitectura ARM cu 64 MB de RAM, cât și pe arhitectura x86_64 cu 32. GB de RAM. Prin urmare, am decis să scriem propria noastră, care poate face toate acestea. Iată ce avem:
Rezumarea debitului a trei canale pentru diferite topologii de rețea
Vizualizarea unor valori cheie
Arhitectură
Folosim Golang ca limbaj principal de programare, atât pe dispozitiv, cât și în centrul de date. A simplificat foarte mult viața prin implementarea sa de multitasking și capacitatea de a obține un fișier binar executabil legat static pentru fiecare serviciu. Ca rezultat, economisim semnificativ resurse, metode și trafic pentru implementarea serviciului pe dispozitivele finale, timp de dezvoltare și depanare a codului.
Sistemul este implementat după principiul modular clasic și conține mai multe subsisteme:
- Înregistrarea metricilor.
Fiecare valoare este deservită de propriul său fir și sincronizată pe canale. Am reușit să obținem o precizie de sincronizare de până la 10 nanosecunde. - Stocarea valorilor
Am ales între să ne scriem propriul stocare pentru serii cronologice sau să folosim ceva care era deja disponibil. Baza de date este necesară pentru datele retrospective care sunt supuse unei vizualizări ulterioare, adică nu conține date despre întârzierile în canal la fiecare 0.5 milisecunde sau citiri de eroare în rețeaua de transport, dar există viteză pe fiecare interfață la fiecare 500 de milisecunde. Pe lângă cerințele ridicate pentru multi-platformă și consumul redus de resurse, este extrem de important pentru noi să putem procesa. datele este locul unde sunt stocate. Acest lucru economisește resurse de calcul enorme. Folosim DBMS Tarantool în acest proiect din 2016 și până acum nu vedem un înlocuitor pentru acesta la orizont. Flexibil, cu consum optim de resurse, suport tehnic mai mult decât adecvat. Tarantool implementează și un modul GIS. Desigur, nu este la fel de puternic ca PostGIS, dar este suficient pentru sarcinile noastre de stocare a unor valori legate de locație (relevante pentru transport). - Vizualizarea metricilor
Totul este relativ simplu aici. Preluăm date din depozit și le afișăm fie în timp real, fie retroactiv. - Sincronizarea datelor cu sistemul central de monitorizare.
Sistemul central de monitorizare primește date de la toate dispozitivele, le stochează cu un istoric specificat și le trimite către sistemul de monitorizare al Clientului prin API. Spre deosebire de sistemele clasice de monitorizare, în care „capul” se plimbă și colectează date, avem schema opusă. Dispozitivele în sine trimit date atunci când există o conexiune. Acesta este un punct foarte important, deoarece vă permite să primiți date de pe dispozitiv pentru acele perioade de timp în care acestea nu au fost disponibile și să nu încărcați canale și resurse cât timp dispozitivul este indisponibil. Folosim serverul de monitorizare Influx ca sistem central de monitorizare. Spre deosebire de analogii săi, poate importa date retrospective (adică cu un marcaj de timp diferit de momentul în care au fost primite metricile) metricile colectate sunt vizualizate de Grafana, modificate cu un fișier. Această stivă standard a fost aleasă și pentru că are integrări API gata făcute cu aproape orice sistem de monitorizare a clienților. - Sincronizarea datelor cu un sistem central de management al dispozitivului.
Sistemul de management al dispozitivelor implementează Zero Touch Provisioning (actualizare firmware, configurare etc.) și, spre deosebire de sistemul de monitorizare, primește doar probleme pe dispozitiv. Acestea sunt declanșatoare pentru funcționarea serviciilor de supraveghere hardware de la bord și toate valorile sistemelor de susținere a vieții: temperatura CPU și SSD, încărcarea CPU, spațiul liber și sănătatea SMART pe discuri. De asemenea, stocarea subsistemului este construită pe Tarantool. Acest lucru ne oferă o viteză semnificativă în agregarea seriilor de timp pe mii de dispozitive și, de asemenea, rezolvă complet problema sincronizării datelor cu aceste dispozitive. Tarantool are un sistem excelent de coadă și livrare garantată. Am scos din cutie această caracteristică importantă, grozav!
Sistem de management al rețelei
Ce urmează
Până acum, cea mai slabă verigă a noastră este sistemul central de monitorizare. Este implementat 99.9% pe o stivă standard și are o serie de dezavantaje:
- InfluxDB pierde date atunci când se pierde alimentarea. De regulă, Clientul colectează cu promptitudine tot ceea ce vine de la dispozitive, iar baza de date în sine nu conține date mai vechi de 5 minute, dar în viitor acest lucru poate deveni o durere.
- Grafana are o serie de probleme cu agregarea datelor și sincronizarea afișajului său. Cea mai frecventă problemă este atunci când baza de date conține o serie temporală cu un interval de 2 secunde începând de la, să zicem, 00:00:00, iar Grafana începe să arate date în agregare de la +1 secundă. Ca rezultat, utilizatorul vede un grafic dansant.
- Cantitate excesivă de cod pentru integrarea API cu sisteme de monitorizare terțe. Poate fi făcut mult mai compact și, desigur, rescris în Go)
Cred că toți ați văzut perfect cum arată Grafana și cunoașteți problemele sale fără mine, așa că nu voi supraîncărca postarea cu poze.
Concluzie
Nu am descris în mod deliberat detaliile tehnice, ci am descris doar designul de bază al acestui sistem. În primul rând, pentru a descrie complet sistemul din punct de vedere tehnic, va fi necesar un alt articol. În al doilea rând, nu toată lumea va fi interesată de acest lucru. Scrieți în comentarii ce detalii tehnice doriți să aflați.
Dacă cineva are întrebări dincolo de scopul acestui articol, îmi puteți scrie la a.rodin @ qedr.com
Sursa: www.habr.com