16 modem, 4 operatori cellulari = Velocità in uscita 933.45 Mbit/s
Introduzione
Bonghjornu! Questu articulu hè nantu à cumu avemu scrittu un novu sistema di surviglianza per noi. Differisce da quelli esistenti in a so capacità di ottene metriche sincrone d'alta frequenza è cunsumu di risorse assai bassu. A tarifa di polling pò ghjunghje à 0.1 millisecondi cù una precisione di sincronizazione trà metriche di 10 nanosecondi. Tutti i schedari binari occupanu 6 megabytes.
À u prugettu
Avemu un pruduttu piuttostu specificu. Producemu una soluzione cumpleta per sintetizà u throughput è a tolleranza à i difetti di i canali di trasmissione di dati. Questu hè quandu ci sò parechji canali, dicemu Operator1 (40Mbit/s) + Operator2 (30Mbit/s) + Qualcosa altru (5 Mbit/s), u risultatu hè un canale stabile è veloce, a velocità di quale serà qualcosa cum'è. questu: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tali suluzioni sò in dumanda induve a capacità di qualsiasi canale hè insufficiente. Per esempiu, trasportu, sistemi di videosurveglianza è streaming video in tempu reale, trasmissione di televisione in diretta è emissioni di radiu, qualsiasi strutture suburbane induve trà l'operatori di telecomunicazioni ci sò solu rapprisentanti di i Big Four è a velocità in un modem / canale ùn hè micca abbastanza. .
Per ognunu di sti spazii, pruduciamu una linea separata di dispusitivi, ma a so parte di u software hè quasi a stessa è un sistema di surviglianza d'alta qualità hè unu di i so moduli principali, senza l'implementazione curretta di quale u pruduttu ùn saria micca pussibule.
In u corsu di parechji anni, avemu sappiutu di creà un sistema di surviglianza multi-livellu, veloce, multipiattaforma è ligeru. Hè ciò chì vulemu sparte cù a nostra cumunità rispettata.
Formulazione di u prublema
U sistema di surviglianza furnisce metriche di duie classi fundamentalmente diverse: metriche in tempu reale è tutti l'altri. U sistema di surviglianza avia solu i seguenti requisiti:
- Acquisizione sincrona à alta frequenza di metriche in tempu reale è u so trasferimentu à u sistema di gestione di cumunicazione senza ritardu.
L'alta frequenza è a sincronizazione di e diverse metriche ùn hè micca solu impurtante, hè vitale per analizà l'entropia di i canali di trasmissione di dati. Se in un canale di trasmissione di dati, u ritardu mediu hè di 30 millisecondi, allora un errore in a sincronizazione trà e metriche rimanenti di solu un millisecondu portarà à a degradazione di a velocità di u canali resultanti da circa 5%. Sè avemu mistime u timing da 1 millisecondu attraversu 4 canali, a degradazione di a velocità pò facilmente abbandunà à 30%. Inoltre, l'entropia in i canali cambia assai rapidamente, perchè si misurà menu di una volta ogni 0.5 millisecondi, nantu à i canali veloci cù un picculu ritardu, averemu una degradazione d'alta veloce. Di sicuru, una tale precisione ùn hè micca necessariu per tutti i metrichi è micca in tutte e cundizioni. Quandu u ritardu in u canali hè di 500 millisecondi, è avemu travagliatu cù tali, allora un errore di 1 millisecondu serà quasi micca notu. Inoltre, per i metrici di u sistema di supportu di vita, avemu abbastanza tassi di polling è di sincronizazione di 2 seconde, ma u sistema di monitoraghju stessu deve esse capace di travaglià cù ritmi di votazione ultra-alti è sincronizazione ultra-precisa di metrica. - Cunsumu minimu di risorse è una sola pila.
U dispusitivu finale pò esse sia un putente cumplessu à bordu chì pò analizà a situazione nantu à a strada o cunduce a registrazione biometrica di e persone, o un computer unicu di palma chì un suldatu di e forze speciali porta sottu a so armatura per trasmette video in tempu reale in cundizioni poveri di cumunicazione. Malgradu una tale varietà di architetture è putenza di computing, vulemu avè a stessa pila di software. - Architettura di umbrella
A metrica deve esse recullata è aggregata nantu à u dispositivu finale, almacenata in u locu, è visualizata in tempu reale è retrospettiva. Se ci hè una cunnessione, trasfiriri dati à u sistema di surviglianza cintrali. Quandu ùn ci hè micca una cunnessione, a fila di mandatu deve accumulà è micca cunsumà RAM. - API per integrazione in u sistema di monitoraghju di u cliente, perchè nimu hà bisognu di parechji sistemi di monitoraghju. U cliente deve raccoglie dati da qualsiasi dispositi è rete in un unicu monitoraghju.
Chì hè accadutu
Per ùn caccià a longa lettura dighjà impressiunanti, ùn daraghju micca esempi è misurazioni di tutti i sistemi di surviglianza. Stu vi purterà à un altru articulu. Dicu solu chì ùn pudemu micca truvà un sistema di monitoraghju chì hè capace di piglià duie metriche simultaneamente cù un errore di menu di 1 millisecondu è chì funziona ugualmente efficacemente sia in l'architettura ARM cù 64 MB di RAM sia in l'architettura x86_64 cù 32. GB di RAM. Dunque, avemu decisu di scrive u nostru propiu, chì pò fà tuttu questu. Eccu ciò chì avemu avutu:
Riassuntu u throughput di trè canali per diverse topologie di rete
Visualizazione di alcune metriche chjave
architettura
Avemu aduprà Golang cum'è a lingua di prugrammazione principale, sia in u dispusitivu sia in u centru di dati. Hè simplificatu assai a vita cù a so implementazione di multitasking è l'abilità di ottene un file binari eseguibile staticamente ligatu per ogni serviziu. In u risultatu, salvemu significativamente in risorse, metudi è trafficu per implementà u serviziu à i dispositi finali, u tempu di sviluppu è u debugging di codice.
U sistema hè implementatu secondu u principiu modulare classicu è cuntene parechji sottosistemi:
- Registrazione di metrica.
Ogni metrica hè servita da u so propiu filu è sincronizatu in i canali. Pudemu ottene una precisione di sincronizazione finu à 10 nanosecondi. - Storage di metrica
Avemu sceltu trà scrive u nostru propiu almacenamentu per a serie temporale o aduprà qualcosa chì era digià dispunibule. A basa di dati hè necessariu per e dati retrospettivi chì sò sottumessi à a visualizazione successiva, vale à dì, ùn cuntene micca dati nantu à i ritardi in u canali ogni 0.5 millisecondi o letture d'errore in a reta di trasportu, ma ci hè una veloce in ogni interfaccia ogni 500 milliseconds. In più di l'alti requisiti per u cunsumu cross-platform è pocu risorse, hè assai impurtante per noi di pudè processà. data hè induve hè guardatu. Questu salva enormi risorse informatiche. Avemu usatu u Tarantool DBMS in questu prughjettu da u 2016 è finu à avà ùn vedemu micca un sustitutu per questu in l'orizzonte. Flessibule, cù u cunsumu di risorse ottimali, più di supportu tecnicu adattatu. Tarantool implementa ancu un modulu GIS. Di sicuru, ùn hè micca cusì putente cum'è PostGIS, ma hè abbastanza per i nostri compiti di almacenà alcune metriche relative à u locu (pertinenti per u trasportu). - Visualizazione di metrica
Tuttu hè relativamente simplice quì. Pigliemu e dati da u magazzinu è li mostranu in tempu reale o retrospettiva. - Sincronizazione di dati cù u sistema di surviglianza cintrali.
U sistema di surviglianza cintrali riceve dati da tutti i dispusitivi, l'almacene cù una storia specifica è u manda à u sistema di surviglianza di u Cliente via API. A cuntrariu di i sistemi di surviglianza classica, in quale u "capu" cammina intornu è raccoglie dati, avemu u schema oppostu. I dispusitivi stessi mandanu dati quandu ci hè una cunnessione. Questu hè un puntu assai impurtante, postu chì permette di riceve dati da u dispositivu per quelli periodi di tempu durante u quali ùn era micca dispunibule è micca carricà canali è risorse mentre u dispusitivu ùn hè micca dispunibule. Utilizemu u servitore di monitoraghju Influx cum'è sistema di monitoraghju cintrali. A cuntrariu di i so analoghi, pò impurtà dati retrospettivi (vale à dì, cù un stampu di tempu diversu da u mumentu chì i metrici sò stati ricivuti) I metrici cullati sò visualizati da Grafana, mudificate cù un schedariu. Questa pila standard hè stata scelta ancu perchè hà integrazioni API pronti cù quasi ogni sistema di monitoraghju di i clienti. - Sincronizazione di dati cù un sistema di gestione di u dispositivu cintrali.
U sistema di gestione di u dispositivu implementa Zero Touch Provisioning (aghjurnà firmware, cunfigurazione, etc.) è, à u cuntrariu di u sistema di surviglianza, riceve solu prublemi per dispusitivu. Quessi sò attivatori per l'operazione di i servizii di vigilanza di hardware à bordu è tutte e metriche di i sistemi di supportu di vita: temperatura di CPU è SSD, carica di CPU, spaziu liberu è salute SMART nantu à i dischi. L'almacenamiento di u subsistema hè ancu custruitu nantu à Tarantool. Questu ci dà una velocità significativa in l'aggregazione di serie di tempu à traversu millaie di dispusitivi, è risolve ancu cumplettamente u prublema di sincronizà e dati cù questi dispositi. Tarantool hà un eccellente sistema di fila è di consegna garantita. Avemu avutu sta funzione impurtante fora di a scatula, grande!
Sistema di gestione di a rete
Chì vene
Finu à avà, u nostru ligame u più debule hè u sistema di monitoraghju cintrali. Hè implementatu annantu à 99.9% nantu à una pila standard è hà una quantità di svantaghji:
- InfluxDB perde dati quandu u putere hè persu. Comu regula, u Cliente prontamente raccoglie tuttu ciò chì vene da i dispositi è a basa di dati stessu ùn cuntene micca dati più vechji di 5 minuti, ma in u futuru questu pò esse un dolore.
- Grafana hà una quantità di prublemi cù l'agregazione di dati è a sincronizazione di a so visualizazione. U prublema più cumuna hè quandu a basa di dati cuntene una serie di tempu cù un intervallu di 2 seconde chì partenu da, per esempiu, 00:00:00, è Grafana cumencia à mostrà dati in aggregazione da + 1 seconde. In u risultatu, l'utilizatore vede un graficu di ballu.
- Una quantità eccessiva di codice per l'integrazione API cù sistemi di monitoraghju di terze parti. Pò esse fattu assai più compactu è, sicuru, riscrittu in Go)
Pensu chì tutti avete vistu perfettamente ciò chì Grafana s'assumiglia è cunnosci i so prublemi senza mè, perchè ùn aghju micca overload the post with pictures.
cunchiusioni
Deliberatamente ùn aghju micca descrittu i dettagli tecnichi, ma hà descrittu solu u disignu di basa di stu sistema. Prima, per descriverà in modu tecnicu u sistema, un altru articulu serà necessariu. Siconda, micca tutti seranu interessate in questu. Scrivite in i cumenti quali dettagli tecnichi vulete sapè.
Sì qualchissia hà dumande oltre u scopu di stu articulu, pudete scrive à mè à a.rodin @ qedr.com
Source: www.habr.com
