16 modem, 4 operatori cellulari = Velocità in uscita 933.45 Mbit/s
Introduzione
Ciao! Questo articolo spiega come abbiamo scritto un nuovo sistema di monitoraggio per noi stessi. Si differenzia da quelli esistenti per la capacità di ottenere metriche sincrone ad alta frequenza e un consumo di risorse molto basso. La velocità di polling può raggiungere 0.1 millisecondi con una precisione di sincronizzazione tra i parametri di 10 nanosecondi. Tutti i file binari occupano 6 megabyte.
Sul progetto
Abbiamo un prodotto piuttosto specifico. Produciamo una soluzione completa per riassumere il throughput e la tolleranza agli errori dei canali di trasmissione dati. Questo è quando ci sono diversi canali, diciamo Operatore1 (40Mbit/s) + Operatore2 (30Mbit/s)+ Qualcos'altro (5 Mbit/s), il risultato è un canale stabile e veloce, la cui velocità sarà qualcosa come questo: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tali soluzioni sono richieste laddove la capacità di un canale è insufficiente. Ad esempio, trasporti, sistemi di videosorveglianza e streaming video in tempo reale, trasmissione di trasmissioni televisive e radiofoniche in diretta, qualsiasi struttura suburbana dove tra gli operatori di telecomunicazioni ci sono solo rappresentanti dei Big Four e la velocità su un modem/canale non è sufficiente .
Per ciascuna di queste aree produciamo una linea separata di dispositivi, ma la parte software è quasi la stessa e uno dei moduli principali è un sistema di monitoraggio di alta qualità, senza la corretta implementazione del quale il prodotto non sarebbe possibile.
Nel corso di diversi anni siamo riusciti a creare un sistema di monitoraggio multilivello, veloce, multipiattaforma e leggero. Questo è ciò che vogliamo condividere con la nostra rispettata comunità.
Formulazione del problema
Il sistema di monitoraggio fornisce metriche di due classi fondamentalmente diverse: metriche in tempo reale e tutte le altre. Il sistema di monitoraggio aveva solo i seguenti requisiti:
- Acquisizione sincrona ad alta frequenza di metriche in tempo reale e loro trasferimento senza ritardi al sistema di gestione della comunicazione.
L'alta frequenza e la sincronizzazione di parametri diversi non sono solo importanti, ma sono vitali per analizzare l'entropia dei canali di trasmissione dei dati. Se in un canale di trasmissione dati il ritardo medio è di 30 millisecondi, un errore di sincronizzazione tra i restanti parametri di appena un millisecondo porterà a un degrado della velocità del canale risultante di circa il 5%. Se sbagliamo i tempi di 1 millisecondo su 4 canali, la riduzione della velocità può facilmente scendere al 30%. Inoltre, l'entropia nei canali cambia molto rapidamente, quindi se la misuriamo meno di una volta ogni 0.5 millisecondi, sui canali veloci con un piccolo ritardo otterremo un degrado ad alta velocità. Naturalmente, tale precisione non è necessaria per tutti i parametri e non in tutte le condizioni. Quando il ritardo nel canale è di 500 millisecondi e lavoriamo con tale, l'errore di 1 millisecondo non sarà quasi evidente. Inoltre, per le metriche del sistema di supporto vitale, disponiamo di frequenze di polling e sincronizzazione sufficienti di 2 secondi, ma il sistema di monitoraggio stesso deve essere in grado di funzionare con velocità di polling ultra elevate e sincronizzazione ultra precisa delle metriche. - Consumo minimo di risorse e un unico stack.
Il dispositivo finale può essere un potente complesso di bordo in grado di analizzare la situazione sulla strada o effettuare registrazioni biometriche di persone, oppure un computer a scheda singola palmare che un soldato delle forze speciali indossa sotto l'armatura per trasmettere video in tempo reale in condizioni di scarsa comunicazione. Nonostante una tale varietà di architetture e potenza di calcolo, vorremmo avere lo stesso stack software. - Architettura dell'ombrello
Le metriche devono essere raccolte e aggregate sul dispositivo finale, archiviate localmente e visualizzate in tempo reale e retrospettivamente. Se è presente una connessione, trasferire i dati al sistema di monitoraggio centrale. Quando non c'è connessione, la coda di invio dovrebbe accumularsi e non consumare RAM. - API per l'integrazione nel sistema di monitoraggio del cliente, perché nessuno ha bisogno di tanti sistemi di monitoraggio. Il cliente deve raccogliere i dati da qualsiasi dispositivo e rete in un unico monitoraggio.
Quello che è successo
Per non appesantire la già impressionante lettura approfondita, non fornirò esempi e misurazioni di tutti i sistemi di monitoraggio. Questo porterà a un altro articolo. Dirò solo che non siamo riusciti a trovare un sistema di monitoraggio in grado di rilevare due parametri contemporaneamente con un errore inferiore a 1 millisecondo e che funzioni altrettanto efficacemente sia su architettura ARM con 64 MB di RAM che su architettura x86_64 con 32 GB di RAM. Pertanto, abbiamo deciso di scriverne uno nostro, che possa fare tutto questo. Ecco cosa abbiamo ottenuto:
Riepilogo del throughput di tre canali per diverse topologie di rete
Visualizzazione di alcune metriche chiave
Architettura
Utilizziamo Golang come linguaggio di programmazione principale, sia sul dispositivo che nel data center. Ha semplificato notevolmente la vita con l'implementazione del multitasking e la possibilità di ottenere un file binario eseguibile collegato staticamente per ciascun servizio. Di conseguenza, risparmiamo in modo significativo in risorse, metodi e traffico per l'implementazione del servizio sui dispositivi finali, tempi di sviluppo e debug del codice.
Il sistema è realizzato secondo il classico principio modulare e contiene diversi sottosistemi:
- Registrazione delle metriche.
Ogni metrica è servita dal proprio thread e sincronizzata su tutti i canali. Siamo stati in grado di raggiungere una precisione di sincronizzazione fino a 10 nanosecondi. - Archiviazione delle metriche
Stavamo scegliendo tra scrivere il nostro spazio di archiviazione per le serie temporali o utilizzare qualcosa che era già disponibile. Il database serve per dati retrospettivi soggetti a successiva visualizzazione, cioè non contiene dati su ritardi nel canale ogni 0.5 millisecondi o letture di errori nella rete di trasporto, ma c'è velocità su ogni interfaccia ogni 500 millisecondi. Oltre agli elevati requisiti di multipiattaforma e al basso consumo di risorse, per noi è estremamente importante essere in grado di elaborare. i dati sono dove sono archiviati. Ciò consente di risparmiare enormi risorse di calcolo. Utilizziamo il DBMS Tarantool in questo progetto dal 2016 e finora non vediamo un suo sostituto all'orizzonte. Flessibile, con un consumo ottimale delle risorse, supporto tecnico più che adeguato. Tarantool implementa anche un modulo GIS. Naturalmente non è potente come PostGIS, ma è sufficiente per il nostro compito di memorizzare alcuni parametri relativi alla posizione (rilevanti per i trasporti). - Visualizzazione delle metriche
Tutto è relativamente semplice qui. Prendiamo i dati dal magazzino e li visualizziamo in tempo reale o retrospettivamente. - Sincronizzazione dei dati con il sistema di monitoraggio centrale.
Il sistema di monitoraggio centrale riceve i dati da tutti i dispositivi, li archivia con una cronologia specifica e li invia al sistema di monitoraggio del Cliente tramite API. A differenza dei classici sistemi di monitoraggio, in cui la “testa” gira e raccoglie dati, noi abbiamo lo schema opposto. I dispositivi stessi inviano i dati quando c'è una connessione. Questo è un punto molto importante, poiché consente di ricevere dati dal dispositivo per quei periodi di tempo in cui non era disponibile e di non caricare canali e risorse mentre il dispositivo non è disponibile. Utilizziamo il server di monitoraggio dell'afflusso come sistema di monitoraggio centrale. A differenza dei suoi analoghi, può importare dati retrospettivi (cioè con un timestamp diverso dal momento in cui sono state ricevute le metriche), le metriche raccolte vengono visualizzate da Grafana, modificate con un file. Questo stack standard è stato scelto anche perché dispone di integrazioni API già pronte con quasi tutti i sistemi di monitoraggio dei clienti. - Sincronizzazione dei dati con un sistema di gestione centrale dei dispositivi.
Il sistema di gestione dei dispositivi implementa lo Zero Touch Provisioning (aggiornamento firmware, configurazione, ecc.) e, a differenza del sistema di monitoraggio, riceve solo i problemi per dispositivo. Si tratta di trigger per il funzionamento dei servizi di watchdog hardware integrati e di tutte le metriche dei sistemi di supporto vitale: temperatura della CPU e dell'SSD, carico della CPU, spazio libero e integrità SMART sui dischi. Anche il sottosistema di stoccaggio è basato su Tarantool. Ciò ci offre una notevole velocità nell'aggregazione di serie temporali su migliaia di dispositivi e risolve completamente anche il problema della sincronizzazione dei dati con questi dispositivi. Tarantool dispone di un eccellente sistema di gestione delle code e di consegna garantita. Abbiamo messo a punto questa importante funzionalità, fantastico!
Sistema di gestione della rete
Cosa c'è Next
Finora, il nostro anello più debole è il sistema di monitoraggio centrale. È implementato al 99.9% su uno stack standard e presenta una serie di svantaggi:
- InfluxDB perde i dati in caso di interruzione dell'alimentazione. Di norma, il Cliente raccoglie tempestivamente tutto ciò che proviene dai dispositivi e il database stesso non contiene dati più vecchi di 5 minuti, ma in futuro questo potrebbe diventare una seccatura.
- Grafana ha una serie di problemi con l'aggregazione dei dati e la sincronizzazione della sua visualizzazione. Il problema più comune si verifica quando il database contiene una serie temporale con un intervallo di 2 secondi a partire, ad esempio, dalle 00:00:00 e Grafana inizia a mostrare i dati in aggregazione da +1 secondo. Di conseguenza, l'utente vede un grafico danzante.
- Quantità eccessiva di codice per l'integrazione API con sistemi di monitoraggio di terze parti. Può essere reso molto più compatto e ovviamente riscritto in Go)
Penso che tutti voi abbiate visto perfettamente come appare Grafana e conoscete i suoi problemi senza di me, quindi non sovraccaricherò il post con le immagini.
conclusione
Volutamente non ho descritto i dettagli tecnici, ma ho descritto solo la struttura di base di questo sistema. Innanzitutto, per descrivere tecnicamente in modo completo il sistema, sarà necessario un altro articolo. In secondo luogo, non tutti saranno interessati a questo. Scrivi nei commenti quali dettagli tecnici vorresti conoscere.
Se qualcuno ha domande che esulano dallo scopo di questo articolo, può scrivermi a a.rodin @ qedr.com
Fonte: habr.com