16 modem, 4 operatori mobili = Velocità di uscita 933,45 Mbit/s
Introduzione
Ciao! Questo è un articolo su come abbiamo creato un nuovo sistema di monitoraggio per noi stessi. Si differenzia dagli esistenti per la possibilità di ricevere metriche sincronizzate ad alta frequenza e per il suo bassissimo consumo di risorse. La frequenza di polling può raggiungere 0,1 millisecondi con una precisione di sincronizzazione tra le metriche di 10 nanosecondi. Tutti i file binari occupano 6 megabyte.
Informazioni sul progetto
Abbiamo un prodotto piuttosto specifico. Produciamo una soluzione integrata per la somma della larghezza di banda e la resilienza dei canali di trasmissione dei dati. Questo avviene quando ci sono più canali, ad esempio Operatore1 (40 Mbit/s) + Operatore2 (30 Mbit/s) + Qualcos'altro (5 Mbit/s), con il risultato di ottenere un singolo 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, nelle dirette radiofoniche e televisive, in qualsiasi località remota dove gli operatori sono solo rappresentanti delle grandi quattro e la velocità su un modem/canale non è adeguata.
Per ciascuna di queste aree, produciamo una linea separata di dispositivi, tuttavia la loro parte software è quasi identica e un sistema di monitoraggio di alta qualità è uno dei suoi principali moduli, senza il quale il prodotto non sarebbe possibile.
Negli ultimi anni, siamo riusciti a creare un sistema di monitoraggio multi-livello, veloce, multipiattaforma e leggero. Vorremmo condividere questo con la rispettabile comunità.
Definizione del compito
Il sistema di monitoraggio fornisce metriche di due classi fondamentalmente diverse: metriche in tempo reale e tutte le altre. I requisiti per il sistema di monitoraggio erano i seguenti:
- Acquisizione sincrona ad alta frequenza delle metriche in tempo reale e trasmissione a un sistema di gestione delle comunicazioni senza ritardi.
L'alta frequenza e la sincronizzazione di metriche diverse non sono solo importanti, sono essenziali per l'analisi dell'entropia nei canali di trasmissione dati. Se in un canale di trasmissione la latenza media è di 30 millisecondi, un errore di sincronizzazione tra le altre metriche di soli un millisecondo porterà a una degradazione della velocità del canale risultante di circa il 5%. Se commettiamo un errore di sincronizzazione di 1 millisecondo in 4 canali, la degradazione della velocità può facilmente scendere fino 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 bassa latenza otterremo una significativa degradazione della velocità. Naturalmente, tale precisione non è necessaria per tutte le metriche e non in tutte le condizioni. Quando la latenza nel canale è di 500 millisecondi, e stiamo lavorando anche con tali canali, un errore di 1 millisecondo sarà quasi impercettibile. Inoltre, per le metriche dei sistemi di vita, una frequenza di campionamento e sincronizzazione di 2 secondi è sufficiente, ma il sistema di monitoraggio stesso deve sapere come operare con frequenze di campionamento estremamente elevate e con sincronizzazione delle metriche estremamente precisa. - Minimo consumo di risorse e stack unificato.
Il dispositivo finale può essere un potente sistema di bordo in grado di analizzare la situazione sulla strada o di registrare biometricamente le persone, oppure un computer a scheda singola delle dimensioni di un palmo, portato sotto un giubbotto antiproiettile da un operatore delle forze speciali per trasmettere video in tempo reale in condizioni di scarsa connessione. Nonostante questa varietà di architetture e potenze di calcolo, desideriamo avere uno stack software omogeneo. - Architettura ombrello
Le metriche devono essere raccolte e aggregate sul dispositivo finale, avere un sistema di archiviazione locale e visualizzazione in tempo reale e retrospettivamente. In caso di connessione disponibile, i dati devono essere trasferiti al sistema di monitoraggio centrale. Quando la connessione non è disponibile, la coda per l'invio deve accumularsi senza consumare memoria RAM. - API per l'integrazione nel sistema di monitoraggio del cliente, poiché nessuno ha bisogno di molti sistemi di monitoraggio. Il cliente deve raccogliere dati da qualsiasi dispositivo e rete in un'unica interfaccia di monitoraggio.
Cosa abbiamo ottenuto
Per non appesantire ulteriormente un già corposo long-form, non citerò esempi e misurazioni di tutti i sistemi di monitoraggio. Questo richiederebbe un altro articolo. Diremo semplicemente che non siamo riusciti a trovare un sistema di monitoraggio capace di acquisire due metriche contemporaneamente con un margine di 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 svilupparne uno nostro che possa fare tutto ciò. Ecco cosa abbiamo realizzato:
Somma della banda disponibile di tre canali per diverse topologie di rete
Visualizzazione di alcune metriche chiave
Architettura
Come linguaggio di programmazione principale, sia sui dispositivi che presso il data center, utilizziamo Golang. Ha semplificato notevolmente la nostra vita grazie alla sua implementazione della multithreading e alla possibilità di ottenere un singolo file binario eseguibile staticamente linkato per ogni servizio. Di conseguenza, risparmiamo notevolmente su risorse, modalità e traffico di deployment del servizio sui dispositivi finali, oltre al tempo di sviluppo e debugging del codice.
Il sistema è implementato secondo il classico principio modulare e comprende diverse sottosistemi:
- Registrazione delle metriche.
Ogni metrica è gestita da un proprio thread e sincronizzata tramite canali. Siamo riusciti a raggiungere un'accuratezza di sincronizzazione fino a 10 nanosecondi. - Archiviazione delle metriche
Abbiamo valutato se creare il nostro sistema di archiviazione per le serie temporali o utilizzare qualcosa di già esistente. Il database è necessario per i dati storici che saranno successivamente visualizzati. Cioè, non ci sono dati sui ritardi nel canale ogni 0,5 millisecondi o sulle letture degli errori nella rete di trasporto, ma ci sono le velocità su ciascuna interfaccia ogni 500 millisecondi. Oltre alle elevate esigenze di interoperabilità e al basso consumo di risorse, è fondamentale per noi poter elaborare i dati là dove vengono archiviati. Questo consente di risparmiare enormemente sulle risorse computazionali. Dal 2016 utilizziamo il DBMS Tarantool per questo progetto e al momento non vediamo alternative all'orizzonte. Flessibile, con un consumo di risorse ottimale e un supporto tecnico più che adeguato. Inoltre, in Tarantool è implementato un modulo GIS. Certamente non è potente come PostGIS, ma è sufficiente per le nostre esigenze di archiviazione di alcune metriche associate alla posizione (importante per i trasporti). - Visualizzazione delle metriche
Qui è tutto relativamente semplice. Prendiamo i dati dall'archivio e li mostriamo in tempo reale o 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 li trasferisce tramite API al sistema di monitoraggio del Cliente. A differenza dei sistemi di monitoraggio tradizionali, in cui la 'testa' si sposta per raccogliere i dati, noi abbiamo uno schema inverso. I dispositivi inviano autonomamente i dati quando c'è connessione. Questo è un aspetto molto importante, in quanto consente di ottenere dati dai dispositivi anche nei momenti in cui non erano disponibili, evitando di sovraccaricare i canali e le risorse quando il dispositivo non è accessibile. Come sistema centrale di monitoraggio utilizziamo il server di monitoraggio Influx. A differenza dei concorrenti, è in grado di importare dati retrospettivi (cioè con un timestamp diverso dal momento di ricezione della metrico). Le metriche raccolte vengono visualizzate tramite una Grafana ottimizzata. Questo stack standard è stato scelto anche perché dispone di API integrate pronte per praticamente 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 monitoraggio hardware e tutte le metriche dei sistemi di supporto vitale: temperatura della CPU e SSD, carico della CPU, spazio libero e salute S.M.A.R.T dei dischi. Lo storage della sottosistema è basato anche su Tarantool. Ciò ci consente una notevole velocità nell'aggregazione di serie temporali su migliaia di dispositivi e risolve completamente la questione della sincronizzazione dei dati con questi dispositivi. Tarantool incorpora un'ottima sistema di code e consegna garantita. Questa importante funzionalità è stata fornita di serie, fantastico!
Sistema di gestione della rete
Cosa succede dopo
Attualmente, il nostro punto più debole è il sistema centrale di monitoraggio. È realizzato per il 99,9% su stack standard e presenta una serie di svantaggi:
- InfluxDB perde dati in caso di mancanza di corrente. Di solito, il cliente recupera rapidamente tutto ciò che arriva dai dispositivi e nel database non ci sono dati più vecchi di 5 minuti, tuttavia in futuro questo potrebbe diventare un problema.
- Grafana presenta diversi problemi con l'aggregazione dei dati e la sincronizzazione della loro visualizzazione. Il problema più comune è quando nella base dati esiste 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 con un'aggregazione a partire da +1 secondo. Di conseguenza, l'utente vede un grafico ballerino.
- Eccesso di codice per l'integrazione dell'API con sistemi di monitoraggio esterni. Si potrebbe rendere tutto molto più compatto e ovviamente riscriverlo in Go.)
Immagino che tutti voi abbiate già visto com'è Grafana e conosciate i suoi problemi, quindi non appesantirò il post con immagini.
Conclusione
Ho scelto deliberatamente di non descrivere i dettagli tecnici, ma di illustrare solo il design di base di questo sistema. In primo luogo, per descrivere tecnicamente il sistema sarebbero necessarie ulteriori articoli. In secondo luogo, non tutti potrebbero essere interessati a questo. Scrivete nei commenti quali dettagli tecnici vi piacerebbe conoscere.
Se qualcuno ha domande oltre a questo articolo, può scrivermi all'indirizzo a.rodin @ qedr.com
Fonte: habr.com
