Încă un sistem de monitorizare

16 modeme, 4 operatori de telefonie mobilă = Viteză de ieșire 933.45 Mbit/s

Introducere

Salut! Acesta este un articol despre cum am scris pentru noi un nou sistem de monitorizare. Acesta se distinge de cele existente prin capacitatea de a obține metrici de înaltă frecvență în mod sincron și prin consumul foarte mic de resurse. Frecvența de sondare poate atinge 0.1 milisecunde, cu o precizie de sincronizare între metrici de 10 nanosecunde. Toate fișierele binare ocupă 6 megabai.

Despre proiect

Avem un produs destul de specific. Produșii o soluție complexă pentru sumarea lățimii de bandă și a redundanței canalelor de transmisie a datelor. Asta înseamnă că există mai multe canale, să zicem Operator1 (40 Mbit/s) + Operator2 (30 Mbit/s) + Ceva altceva (5 Mbit/s), iar rezultatul este un canal stabil și rapid, cu o viteză de aproximativ: (40+30+5)x0.92=75x0.92=69 Mbit/s.

Astfel de soluții sunt cerute acolo unde capacitatea unui singur canal este insuficientă. De exemplu, transport, sisteme de supraveghere video și transmitere de video în timp real, difuzarea de emisiuni televizate și radio, orice obiecte de țară unde operatorii de telecomunicații sunt doar reprezentanții celor patru mari, iar viteza pe un modem/canal este insuficientă.
Pentru fiecare din aceste domenii, lansăm o gamă separată de dispozitive, totuși partea software a acestora este aproape identică, iar un sistem de monitorizare de calitate este unul dintre modulele principale, fără de care produsul nu ar fi posibil.

În câțiva ani, am reușit să creăm un sistem de monitorizare multi-nivel, rapid, cross-platform și ușor. Cu care dorim să ne împărtășim cu respectatul comunității.

Formularea problemei

Sistemul de monitorizare asigură obținerea de metrici din două clase fundamental diferite: metrici în timp real și toate celelalte. Sistemul de monitorizare a avut doar următoarele cerințe:

1. Obținerea sincronizată a metricilor în timp real și transmiterea acestora către sistemul de management al comunicațiilor fără întârzieri.
   Frecvența ridicată și sincronizarea diferitelor metrici nu sunt doar importante, ci absolut esențiale pentru analiza entropiei canalelor de transmisie a datelor. Dacă într-un canal de transmisie media întârzierea este de 30 de milisecunde, atunci o eroare de sincronizare între celelalte metrici de doar o milisecundă va duce la o degradare a vitezei canalului rezultat de aproximativ 5%. Dacă greșim în sincronizare cu 1 milisecundă în 4 canale, degradarea vitezei poate scădea ușor la 30%. În plus, entropia din canale se schimbă foarte repede, așa că, dacă măsurăm mai rar decât o dată la 0.5 milisecunde, în canale rapide cu întârziere mică, vom obține o degradare a vitezei foarte mare. Desigur, o astfel de precizie nu este necesară pentru toate metricile și nu în toate condițiile. Când întârzierea în canal va fi de 500 de milisecunde, iar noi lucrăm și cu astfel de canale, eroarea de 1 milisecundă va trece aproape neobservată. De asemenea, pentru metricile sistemelor de suport vital, ne ajunge o frecvență de sondare și sincronizare de 2 secunde, dar însăși sistemul de monitorizare trebuie să fie capabil să funcționeze cu frecvențe de sondare foarte mari și sincronizarea extrem de precisă a metricilor.
2. Consum minim de resurse și un singur stack.
   Dispozitivul final poate fi atât un complex puternic de bord, care poate analiza situația de pe drum sau realiza înregistrarea biometrică a persoanelor, cât și un computer cu o singură placă, de dimensiunea unei palme, pe care un soldat de elită îl poartă sub vestă pentru a transmite video în timp real în condiții de conexiune slabă. În ciuda acestei varietăți de arhitecturi și puteri de calcul, ne-am dori să avem un stack software uniform.
3. Arhitectură umbrelă
   Metricile trebuie colectate și agregate pe dispozitivul final, trebuie să aibă un sistem local de stocare și vizualizare în timp real și retroactiv. În caz de conexiune — datele trebuie transmise în sistemul central de monitorizare. Când conexiunea lipsește — coada pentru expediere trebuie să se acumuleze și să nu consume memorie operativă.
4. 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 la orice dispozitive și rețele într-o singură monitorizare.

Ce am obținut

Pentru a nu încărca un longread deja impresionant, nu voi oferi exemple sau măsurători pentru toate sistemele de monitorizare. Aceasta ar necesita un alt articol. Voi spune doar că nu am reușit să găsim un sistem de monitorizare capabil să preia două metrici simultan cu o marjă de eroare de sub 1 milisecundă și care funcționează la fel de eficient atât pe arhitectura ARM cu 64MB RAM, cât și pe arhitectura x86_64 cu 32GB RAM. Așadar, am decis să ne creăm propriul sistem care să facă toate acestea. Iată ce am realizat:

Suma lățimii de bandă a trei canale pentru topologii de rețea diferite

Vizualizarea unor metrici cheie

Arhitectură

Ca limbaj principal de programare, atât pe dispozitiv cât și în Data Center, folosim Golang. Acesta ne-a simplificat considerabil viața prin implementarea sa de multitasking și prin posibilitatea de a obține un fișier binar executabil, legat static, pentru fiecare serviciu. Ca rezultat, economisim semnificativ la resurse, metode și trafic în desfășurarea serviciului pe dispozitivele finale, timpul de dezvoltare și de depanare a codului.

Sistemul este implementat pe principiul modular clasic și conține mai multe subsisteme:

1. Înregistrarea metricilor.
   Fiecare metrică este gestionată de un thread propriu și sincronizată prin canale. Am reușit să obținem o precizie de sincronizare de până la 10 nanosecunde.
2. Stocarea metricilor
   Am avut de ales între a ne construi propriul depozit pentru serii temporale sau a folosi ceva existent. O bază de date este necesară pentru datele retrospective care urmează să fie vizualizate ulterior. Adică nu conține date despre întârzierile din canal la fiecare 0,5 milisecunde sau despre citirile erorilor din rețeaua de transport, ci conține viteza pe fiecare interfață la fiecare 500 de milisecunde. Pe lângă cerințele ridicate de portabilitate și consum redus de resurse, este esențial pentru noi să avem capacitatea de a procesa datele acolo unde sunt stocate. Acest lucru economisește semnificativ resursele de calcul. Folosim SGBD Tarantool în acest proiect din 2016 și în prezent nu vedem nicio înlocuire pe termen scurt. Este flexibil, cu un consum optim de resurse și un suport tehnic mai mult decât adecvat. De asemenea, Tarantool dispune de un modul GIS. Nu este la fel de puternic ca PostGIS, dar este suficient pentru sarcinile noastre de stocare a unor metrici legate de locație (relevant pentru transport).
3. Vizualizarea metricilor
   Aici totul este relativ simplu. Preluăm datele din depozit și le afișăm fie în timp real, fie retrospectiv.
4. Sincronizarea datelor cu sistemul central de monitorizare.
   Sistemul central de monitorizare primește date de la toate dispozitivele, le stochează cu o retrospectivă dată și le furnizează prin API în sistemul de monitorizare al Clientului. Spre deosebire de sistemele de monitorizare clasice, în care 'capul' se deplasează și colectează date, noi avem o schemă inversă. Dispozitivele trimit singure datele atunci când au conexiune. Acesta este un punct foarte important, deoarece permite obținerea datelor de la dispozitive pentru intervalele de timp în care acestea nu au fost disponibile, fără a suprasolicita canalele și resursele în vreme ce dispozitivul este inaccesibil. Ca sistem central de monitorizare, folosim serverul de monitorizare Influx. Spre deosebire de omologii săi, acesta poate importa date retrospective (adică cu un marcaj temporal diferit de momentul primirii metricii). Metricile colectate sunt vizualizate de Grafana, îmbunătățită după necesități. Această stivă standard a fost aleasă și pentru că are API-uri gata de integrare practic cu orice sistem de monitorizare al clientului.
5. Sincronizarea datelor cu sistemul central de gestionare a dispozitivelor.
   Sistemul de gestionare a dispozitivelor implementează Zero Touch Provisioning (actualizarea firmware-ului, configurației etc.) și, spre deosebire de sistemul de monitorizare, primește doar probleme legate de dispozitive. Acestea sunt declanșatoare pentru funcționarea serviciilor de supraveghere hardware la bord și toate metricile sistemelor de suport: temperatura CPU și SSD, încărcarea CPU, spațiul liber și sănătatea S.M.A.R.T pe discuri. Stocarea subsistemului este construită tot pe Tarantool. Acest lucru ne oferă o viteză semnificativă în agregarea seriilor temporale pentru mii de dispozitive și rezolvă complet problema sincronizării datelor cu aceste dispozitive. Tarantool are un sistem excelent de cozi și livrare garantată. Această caracteristică importantă a fost obținută din cutie, minunat!

Sistemul de gestionare a rețelei

Ce urmează

Deocamdată, cel mai slab element este sistemul central de monitorizare. Este implementat în 99,9% pe un stivă standard și are o serie de dezavantaje:

1. InfluxDB pierde date în cazul întreruperii alimentării. De obicei, Clientul preia rapid tot ceea ce vine de la dispozitive și în baza de date nu există date mai vechi de 5 minute, dar în viitor aceasta ar putea deveni o problemă.
2. Grafana are o serie de probleme cu agregarea datelor și sincronizarea afișării acestora. Cea mai frecventă problemă este atunci când în baza de date există o serie temporală cu un interval de 2 secunde începând, să zicem, de la 00:00:00, iar Grafana începe să afișeze date în agregare cu +1 secundă. Ca urmare, utilizatorul vede un grafic fluctuant.
3. Un număr excesiv de cod pentru integrarea API-ului cu sisteme externe de monitorizare. Se poate realiza mult mai compact și, desigur, poate fi rescris în Go.

Cred că toți ați văzut cum arată Grafana și știți problemele ei, așa că nu voi aglomera postarea cu imagini.

Concluzie

Aleg să nu descriu detalii tehnice, ci să descriu doar designul de bază al acestui sistem. În primul rând, pentru a descrie tehnic complet sistemul, ar fi necesar un alt articol. În al doilea rând, nu tuturor le-ar interesa. Scrieți în comentarii ce detalii tehnice ați dori să aflați.

Dacă cineva are întrebări în afara acestui articol, îmi pot scrie la adresa a.rodin @ qedr.com

Sursa: habr.com