16 modem, 4 operatori mobili = Velocità in uscita 933.45 Mbit/s
Introduzione
Ciao! Questo è un articolo su come abbiamo sviluppato un nuovo sistema di monitoraggio. Si distingue da quelli esistenti per la possibilità di ottenere metriche ad alta frequenza in modo sincrono e per il suo bassissimo consumo di risorse. La frequenza di interrogazione può arrivare a 0.1 millisecondi con una precisione di sincronizzazione tra le metriche di 10 nanosecondi. Tutti i file binari occupano 6 megabyte.
Il progetto
Abbiamo un prodotto piuttosto specifico. Produciamo una soluzione integrata per sommare la larghezza di banda e la resilienza dei canali di trasmissione dei dati. Questo avviene quando ci sono più canali, per esempio Operatore1 (40 Mbit/s) + Operatore2 (30 Mbit/s) + Qualcos'altro (5 Mbit/s), risultando in un unico canale stabile e veloce, la cui velocità sarà approssimativamente: (40+30+5)x0.92=75×0.92=69 Mbit/s.
Queste soluzioni sono richieste dove la capacità di un singolo canale non è sufficiente. Ad esempio, nei trasporti, nei sistemi di videosorveglianza e nelle trasmissioni video in tempo reale, per le trasmissioni in diretta di programmi televisivi e radiofonici, in qualsiasi luogo isolato dove gli operatori di telecomunicazione sono solo rappresentanti delle big four e le velocità su un modem/canale non sono sufficienti.
Per ciascuno di questi settori produciamo una linea separata di dispositivi, tuttavia la loro parte software è quasi identica e un sistema di monitoraggio di qualità è uno dei suoi moduli principali, senza una corretta implementazione, il prodotto sarebbe impossibile.
In pochi anni, siamo riusciti a creare un sistema di monitoraggio multilivello, veloce, multipiattaforma e leggero. Questo è ciò che vogliamo condividere con la rispettata comunità.
Definizione del compito
Il sistema di monitoraggio garantisce l'ottenimento di metriche di due classi fondamentalmente diverse: metriche in tempo reale e tutte le altre. Al sistema di monitoraggio sono state poste solo le seguenti richieste:
- Ricezione sincrona di metriche in tempo reale ad alta frequenza e loro trasmissione al sistema di gestione della comunicazione senza ritardi.
Un'alta frequenza e la sincronizzazione di diverse metriche non sono semplicemente importanti, ma sono vitali per analizzare l'entropia dei canali di trasmissione dati. Se in un canale di trasmissione dati il ritardo medio è di 30 millisecondi, un errore di sincronizzazione tra le altre metriche di solo un millisecondo porterà a una degradazione della velocità del canale risultante di circa il 5%. Se sbagliamo nella sincronizzazione di 1 millisecondo in 4 canali, la degradazione della velocità potrebbe scendere fino al 30%. Inoltre, l'entropia nei canali cambia molto rapidamente, quindi se la misuriamo meno di una volta ogni 0,5 millisecondi, nei canali veloci con bassa latenza otterremo un'alta degradazione della velocità. Ovviamente, tale precisione non è necessaria per tutte le metriche e in tutte le condizioni. Quando la latenza nel canale sarà di 500 millisecondi, e lavoriamo anche con tali canali, un errore di 1 millisecondo sarà quasi impercettibile. Inoltre, per le metriche dei sistemi di supporto vitale, ci basta una frequenza di polling e sincronizzazione di 2 secondi, tuttavia il sistema di monitoraggio stesso deve essere in grado di lavorare con frequenze di polling estremamente elevate e sincronizzazioni estremamente precise delle metriche. - Minimo consumo di risorse e stack unificato.
Il dispositivo finale può rappresentare sia un potente complesso di bordo, in grado di analizzare la situazione sulla strada o di eseguire la registrazione biometrica delle persone, sia un computer a scheda singola delle dimensioni di un palmo, che un soldato delle forze speciali porta sotto il giubbotto antiproiettile per trasmettere video in tempo reale in condizioni di cattiva connettività. Nonostante questa varietà di architetture e potenze di calcolo, ci piacerebbe avere uno stack software uniforme. - Architettura a ombrello
Le metriche devono essere raccolte e aggregate sul dispositivo finale, avere un sistema di archiviazione locale e visualizzazione in tempo reale e retrospettiva. In caso di connettività — i dati devono essere trasmessi al sistema centrale di monitoraggio. Quando non c'è connessione — la coda per l'invio deve accumularsi e non consumare memoria operativa. - API per l'integrazione nel sistema di monitoraggio del cliente, perché a nessuno servono molti sistemi di monitoraggio. Il cliente deve raccogliere dati da qualsiasi dispositivo e rete in un unico monitoraggio.
Risultato ottenuto
Per non sovraccaricare ulteriormente questo lungo articolo, non fornirò esempi e misurazioni di tutti i sistemi di monitoraggio. Questo richiederebbe un altro articolo. Dirò solo che non siamo riusciti a trovare un sistema di monitoraggio in grado di acquisire simultaneamente due metriche con un errore inferiore a 1 millisecondo e che funzioni altrettanto bene sia su architettura ARM con 64MB di RAM, sia su architettura x86_64 con 32GB di RAM. Pertanto, abbiamo deciso di scrivere il nostro, in grado di fare tutto questo. Ecco cosa abbiamo ottenuto:
Sommatoria della larghezza di banda di tre canali per diverse topologie di rete
Visualizzazione di alcune metriche chiave
Architettura
Come linguaggio di programmazione principale, sia sui dispositivi che nei data center, utilizziamo Golang. Questo ha semplificato notevolmente la vita grazie alla sua implementazione del multithreading e alla possibilità di ottenere un singolo file binario eseguibile staticamente collegato per ciascun servizio. Di conseguenza, risparmiamo notevolmente in risorse, metodi e traffico nella distribuzione del servizio sui dispositivi finali, nonché nel tempo di sviluppo e debug del codice.
Il sistema è stato implementato secondo un classico principio modulare e comprende diverse sottosistemi:
- Registrazione delle metriche.
Ogni metrica è gestita da un proprio thread e sincronizzata tramite canali. Siamo riusciti a ottenere una precisione di sincronizzazione fino a 10 nanosecondi. - Archiviazione delle metriche
Abbiamo valutato se scrivere il nostro repository per le serie temporali o utilizzare qualcosa di esistente. Il database è necessario per i dati retrospettivi, che saranno successivamente visualizzati. Cioè, non contiene dati sui ritardi nel canale ogni 0,5 millisecondi o sui messaggi di errore nella rete di trasporto, ma registra la velocità su ogni interfaccia ogni 500 millisecondi. Oltre all'alta necessità di compatibilità cross-platform e a un basso consumo di risorse, è per noi estremamente importante poter elaborare i dati là dove vengono memorizzati. Questo riduce notevolmente il consumo di risorse computazionali. Da quando abbiamo iniziato nel 2016, utilizziamo il database Tarantool per questo progetto e non vediamo ancora alternative all'orizzonte. È flessibile, con un consumo di risorse ottimale e un supporto tecnico più che adeguato. Inoltre, Tarantool implementa un modulo GIS. Certo, non è potente come PostGIS, ma è sufficiente per le nostre esigenze di archiviazione di alcune metriche legate alla posizione (importante per i trasporti). - Visualizzazione delle metriche
Qui è tutto relativamente semplice. Prendiamo i dati dal repository e li mostriamo sia in tempo reale che retrospettivamente. - Sincronizzazione dei dati con il sistema centrale di monitoraggio.
Il sistema centrale di monitoraggio riceve i dati da tutti i dispositivi, li memorizza con una retrospettiva definita e tramite API li restituisce nel sistema di monitoraggio del Cliente. A differenza dei classici sistemi di monitoraggio, in cui "la testa" raccoglie i dati, noi abbiamo uno schema inverso. I dispositivi inviano autonomamente i dati quando sono connessi. Questo è un aspetto molto importante, poiché consente di ottenere dati dal dispositivo durante i periodi in cui non è disponibile, evitando di sovraccaricare i canali e le risorse quando il dispositivo è inattivo. Come sistema centrale di monitoraggio, utilizziamo il server di monitoraggio Influx. A differenza di altri, è in grado di importare dati retrospettivi (cioè con un timestamp diverso dal momento di ricezione della metrica). Le metriche raccolte vengono visualizzate tramite un Grafana ottimizzato. Questa configurazione standard è stata scelta anche perché dispone di API di integrazione pronte per quasi qualsiasi sistema di monitoraggio del cliente. - Sincronizzazione dei dati con il sistema centrale di gestione dei dispositivi.
Il sistema di gestione dei dispositivi implementa il Zero Touch Provisioning (aggiornamento del firmware, configurazione, ecc.) e, a differenza del sistema di monitoraggio, riceve solo problemi dai dispositivi. Questi sono i trigger per il funzionamento dei servizi di sorveglianza hardware di bordo e tutte le metriche dei sistemi di supporto vitale: temperatura della CPU e dell'SSD, carico della CPU, spazio libero e stato S.M.A.R.T dei dischi. Lo storage della sottosistema è costruito anch'esso su Tarantool. Questo ci offre una notevole velocità nell'aggregazione delle serie temporali su migliaia di dispositivi, e risolve completamente il problema della sincronizzazione dei dati con questi dispositivi. Tarantool ha un'eccellente sistema di code e consegna garantita. Abbiamo ricevuto questa importante funzionalità pronta all'uso, fantastico!
Sistema di gestione della rete
E ora?
Attualmente, il nostro punto più debole è il sistema centrale di monitoraggio. È implementato al 99,9% su un stack standard e presenta una serie di svantaggi:
- InfluxDB perde dati in caso di mancanza di alimentazione. Di solito, il cliente raccoglie rapidamente tutto ciò che riceve dai dispositivi e nel database non ci sono dati più vecchi di 5 minuti, tuttavia, in futuro questo potrebbe diventare un problema.
- Grafana ha una serie di problemi con l'aggregazione dei dati e la sincronizzazione della loro visualizzazione. Il problema più comune è quando nel database c'è una serie temporale con un intervallo di 2 secondi a partire da ad esempio le 00:00:00, mentre Grafana inizia a mostrare i dati in aggregazione con +1 secondo. Di conseguenza, l'utente vede un grafico a zig-zag.
- Eccesso di codice per l'integrazione API con sistemi di monitoraggio di terze parti. Può essere reso molto più compatto e certamente riscritto in Go)
Suppongo che tutti voi abbiate già visto come appare Grafana e conoscete i suoi problemi, quindi non voglio sovraccaricare il post con immagini.
Conclusione
Ho volutamente evitato di descrivere dettagli tecnici, limitandomi a delineare il design di base di questo sistema. In primo luogo, sarebbe necessaria un'altra articolo per descrivere tecnicamente il sistema in modo completo. In secondo luogo, non tutti potrebbero trovarlo interessante. Scrivete nei commenti quali dettagli tecnici vi piacerebbe sapere.
Se qualcuno ha domande oltre a quest'articolo, può contattarmi all'indirizzo a.rodin @ qedr.com
Fonte: habr.com
