Un anno fa abbiamo lanciato una versione pilota di un progetto promozionale per .
Inizialmente il progetto si chiamava Road-To-Barcelona, poi divenne Road-To-Berlin (da qui R2B negli screenshot), e alla fine si chiamava xRide.
L'idea principale del progetto era questa: invece di avere un servizio centralizzato di noleggio auto o scooter (stiamo parlando di scooter ovvero moto elettriche, non kickscooter/scooter) volevamo creare una piattaforma per il noleggio decentralizzato. Delle difficoltà che abbiamo incontrato .
Inizialmente, il progetto si concentrava sulle automobili, ma a causa delle scadenze, delle comunicazioni estremamente lunghe con i produttori e di un numero enorme di restrizioni di sicurezza, per il progetto pilota sono stati scelti gli scooter elettrici.
L'utente ha installato un'applicazione iOS o Android sul telefono, si è avvicinato allo scooter che gli piaceva, dopodiché il telefono e lo scooter hanno stabilito una connessione peer-to-peer, sono stati scambiati ETH e l'utente ha potuto iniziare la corsa accendendo lo scooter tramite il telefono. Alla fine del viaggio era anche possibile pagare il viaggio utilizzando Ethereum dal portafoglio dell’utente sul telefono.
Oltre agli scooter, l'utente ha visto nell'applicazione “caricabatterie intelligenti”, visitando i quali l'utente poteva cambiare lui stesso la batteria attuale se era scarica.
Questo è in generale l'aspetto del nostro progetto pilota, lanciato a settembre dello scorso anno in due città tedesche: Bonn e Berlino.
E poi, un giorno, a Bonn, la mattina presto, il nostro team di supporto (situato sul posto per mantenere gli scooter in condizioni di funzionamento) è stato allertato: uno degli scooter era scomparso senza lasciare traccia.
Come trovarlo e restituirlo?
In questo articolo parlerò di questo, ma prima di tutto di come abbiamo costruito la nostra piattaforma IoT e di come l'abbiamo monitorata.
Cosa e perché monitorare: monopattini, infrastrutture, colonnine di ricarica?
Allora, cosa volevamo monitorare nel nostro progetto?
Prima di tutto, questi sono gli scooter stessi: gli scooter elettrici stessi sono piuttosto costosi, non puoi lanciare un progetto del genere senza essere sufficientemente preparato; se possibile, vuoi raccogliere quante più informazioni possibili sugli scooter: sulla loro posizione, livello di carica , eccetera.
Inoltre, vorrei monitorare lo stato della nostra infrastruttura IT: database, servizi e tutto ciò di cui hanno bisogno per funzionare. Era inoltre necessario monitorare lo stato dei “caricabatterie intelligenti”, nel caso si rompessero o rimanessero scariche.
Scooter
Quali erano i nostri scooter e cosa volevamo sapere su di loro?
La prima e più importante cosa sono le coordinate GPS, poiché grazie ad esse possiamo capire dove si trovano e dove si stanno muovendo.
Poi c'è la carica della batteria, grazie alla quale possiamo constatare che la ricarica del monopattino sta per terminare e inviare uno spremiagrumi o almeno avvisare l'utente.
Naturalmente è anche necessario verificare cosa sta succedendo ai nostri componenti Hardware:
- il bluetooth funziona?
- funziona il modulo GPS stesso?
- Abbiamo anche avuto un problema con il fatto che il GPS poteva inviare coordinate errate e bloccarsi, e questo poteva essere determinato solo tramite ulteriori controlli sullo scooter,
e avvisare il supporto il più presto possibile per risolvere il problema
- Abbiamo anche avuto un problema con il fatto che il GPS poteva inviare coordinate errate e bloccarsi, e questo poteva essere determinato solo tramite ulteriori controlli sullo scooter,
E infine: controlli del software, a partire dal sistema operativo e dal processore, dal carico della rete e del disco, per finire con i controlli dei nostri moduli più specifici per noi (, ).
Hardware
Qual era la nostra parte “ferrea”?
Tenendo conto del tempo più breve possibile e della necessità di una prototipazione rapida, abbiamo scelto l'opzione più semplice per l'implementazione e la selezione dei componenti: Raspberry Pi.
Oltre all'Rpi stesso, avevamo una scheda personalizzata (che noi stessi abbiamo sviluppato e ordinato dalla Cina per accelerare il processo di assemblaggio della soluzione finale) e un set di componenti: un relè (per accendere/spegnere lo scooter), un lettore carica batteria, un modem, antenne. Tutto questo era confezionato in modo compatto in una speciale "scatola xRide".
Da notare inoltre che l'intero box era alimentato da un power bank aggiuntivo, che a sua volta era alimentato dalla batteria principale dello scooter.
Ciò ha permesso di utilizzare il monitoraggio e accendere lo scooter anche dopo la fine del viaggio, poiché la batteria principale è stata spenta immediatamente dopo aver girato la chiave di accensione in posizione “off”.
Docker? Linux semplice? e distribuzione
Torniamo al monitoraggio, quindi Raspberry: cosa abbiamo?
Una delle prime cose che volevamo utilizzare per accelerare il processo di distribuzione, aggiornamento e distribuzione dei componenti sui dispositivi fisici era Docker.
Sfortunatamente, è diventato subito chiaro che Docker su RPi, sebbene funzioni, ha molti costi, soprattutto in termini di consumo energetico.
La differenza utilizzando il sistema operativo “nativo”, anche se non così forte, è stata comunque sufficiente per diffidare della possibilità di perdere la carica troppo rapidamente.
Il secondo motivo è stata una delle nostre librerie partner su Node.js (sic!), l'unico componente del sistema che non è stato scritto in Go/C/C++.
Gli autori della biblioteca non hanno avuto il tempo di fornire una versione funzionante in nessuna delle lingue “native”.
Non solo il nodo in sé non è la soluzione più elegante per dispositivi a basse prestazioni, ma la libreria stessa era molto affamata di risorse.
Ci siamo resi conto che, anche se lo avessimo voluto, l'utilizzo di Docker sarebbe stato un sovraccarico per noi. La scelta è stata fatta a favore del sistema operativo nativo e ha lavorato direttamente sotto di esso.
OS
Di conseguenza, abbiamo scelto, ancora una volta, l'opzione più semplice come sistema operativo e abbiamo utilizzato Raspbian (build Debian per Pi).
Scriviamo tutto il nostro software in Go, quindi abbiamo scritto anche il modulo agente hardware principale nel nostro sistema in Go.
È lui che è responsabile del funzionamento con GPS, Bluetooth, lettura della carica, accensione dello scooter, ecc.
Distribuire
È sorta immediatamente la domanda sulla necessità di implementare un meccanismo per fornire aggiornamenti ai dispositivi (OTA): sia aggiornamenti al nostro agente/applicazione stessa, sia aggiornamenti al sistema operativo/firmware stesso (poiché le nuove versioni dell'agente potrebbero richiedere aggiornamenti al kernel o componenti di sistema, librerie, ecc.).
Dopo un'analisi piuttosto lunga del mercato, si è scoperto che esistono molte soluzioni per fornire aggiornamenti al dispositivo.
Da utilità relativamente semplici, per lo più orientate all'aggiornamento/dual-boot come swupd/SWUpdate/OSTree a piattaforme complete come Mender e Balena.
Innanzitutto abbiamo deciso che eravamo interessati a soluzioni end-to-end, quindi la scelta è ricaduta subito sulle piattaforme.
Stessa è stato escluso perché utilizza effettivamente lo stesso Docker all'interno del suo balenaEngine.
Ma noto che nonostante ciò, abbiamo finito per utilizzare costantemente il loro prodotto per firmware flash su schede SD: un'utilità semplice ed estremamente conveniente per questo.
Pertanto, alla fine, la scelta è caduta su . Mender è una piattaforma completa per l'assemblaggio, la fornitura e l'installazione del firmware.
Nel complesso la piattaforma sembra fantastica, ma ci è voluta circa una settimana e mezza solo per creare la versione corretta del nostro firmware utilizzando il mender builder.
E più ci immergevamo nella complessità del suo utilizzo, più diventava chiaro che per implementarlo completamente avremmo avuto bisogno di molto più tempo di quello che avevamo.
Purtroppo, le nostre scadenze ravvicinate ci hanno costretto ad abbandonare l'uso di Mender e sceglierne uno ancora più semplice.
ansible
La soluzione più semplice nella nostra situazione era utilizzare Ansible. Per iniziare sono bastati un paio di playbook.
La loro essenza era che ci connettevamo semplicemente dall'host (server CI) tramite ssh ai nostri rasberry e distribuivamo loro gli aggiornamenti.
All'inizio tutto era semplice: dovevi essere sulla stessa rete con i dispositivi, il versamento veniva effettuato tramite Wi-Fi.
In ufficio c'erano semplicemente una dozzina di lamponi di prova collegati alla stessa rete, ogni dispositivo aveva un indirizzo IP statico specificato anche in Ansible Inventory.
È stato Ansible a fornire il nostro agente di monitoraggio ai dispositivi finali
X
Sfortunatamente, questo caso d’uso per Ansible poteva funzionare solo in modalità sviluppo prima che avessimo gli scooter veri e propri.
Perché gli scooter, come capisci, non restano connessi a un router Wi-Fi, aspettando costantemente aggiornamenti sulla rete.
In realtà gli scooter non possono avere altra connessione che quella mobile 3G/LTE (e anche in questo caso non sempre).
Ciò impone immediatamente molti problemi e limitazioni, come una bassa velocità di connessione e una comunicazione instabile.
Ma la cosa più importante è che in una rete 3G/LTE non possiamo basarci semplicemente su un IP statico assegnato alla rete.
Alcuni fornitori di carte SIM risolvono parzialmente questo problema; esistono anche carte SIM speciali progettate per dispositivi IoT con indirizzi IP statici. Ma non avevamo accesso a tali carte SIM e non potevamo utilizzare gli indirizzi IP.
Naturalmente, c'erano idee per realizzare una sorta di registrazione degli indirizzi IP, ovvero il service discovery da qualche parte come Consul, ma abbiamo dovuto abbandonare tali idee, poiché nei nostri test l'indirizzo IP poteva cambiare troppo spesso, il che portava a una grande instabilità.
Per questo motivo, l'uso più conveniente per fornire le metriche non sarebbe utilizzare il modello pull, in cui andremmo ai dispositivi per le metriche necessarie, ma push, fornendo le metriche dal dispositivo direttamente al server
VPN
Come soluzione a questo problema, abbiamo scelto la VPN, in particolare .
I client (scooter) all'inizio del sistema si sono collegati al server VPN e sono riusciti a connettersi ad esso. Questo tunnel è stato utilizzato per fornire aggiornamenti.
In teoria, lo stesso tunnel potrebbe essere utilizzato per il monitoraggio, ma tale collegamento era più complicato e meno affidabile della semplice spinta.
Risorse cloud
Infine, è necessario monitorare i nostri servizi cloud e i nostri database, poiché per essi utilizziamo Kubernetes, idealmente in modo che l'implementazione del monitoraggio nel cluster sia il più semplice possibile. Idealmente, utilizzando , poiché per la distribuzione lo utilizziamo nella maggior parte dei casi. E, naturalmente, per monitorare il cloud è necessario utilizzare le stesse soluzioni degli scooter stessi.
Dano
Uff, sembra che abbiamo risolto la descrizione, facciamo un elenco di ciò di cui avevamo bisogno alla fine:
- Una soluzione rapida, poiché il monitoraggio è necessario già durante il processo di sviluppo
- Volume/quantità: sono necessari molti parametri
- La raccolta dei registri è obbligatoria
- Affidabilità: i dati sono fondamentali per il successo del lancio
- Non puoi usare il modello pull: hai bisogno di push
- Abbiamo bisogno di un monitoraggio unificato non solo dell’hardware, ma anche del cloud
L'immagine finale assomigliava a questa
Selezione della pila
Quindi, ci siamo trovati di fronte alla questione della scelta di uno stack di monitoraggio.
Innanzitutto cercavamo la soluzione all-in-one più completa che coprisse contemporaneamente tutte le nostre esigenze, ma allo stesso tempo fosse sufficientemente flessibile da adattarne l'utilizzo alle nostre esigenze. Tuttavia, avevamo molte restrizioni imposte dall'hardware, dall'architettura e dalle scadenze.
Esiste un'enorme varietà di soluzioni di monitoraggio, a partire da sistemi completi come , o e per finire con soluzioni già pronte per la gestione della flotta.
Inizialmente, quest’ultima ci sembrava una soluzione ideale, ma alcuni non avevano un monitoraggio completo, altri avevano le capacità fortemente limitate delle versioni gratuite e altri semplicemente non soddisfacevano i nostri “desideri” o non erano abbastanza flessibili per adattarsi ai nostri scenari. Alcuni sono semplicemente obsoleti.
Dopo aver analizzato una serie di soluzioni simili, siamo rapidamente giunti alla conclusione che sarebbe stato più semplice e veloce assemblare da soli uno stack simile. Sì, sarà un po’ più complicato che implementare una piattaforma di gestione della flotta completamente già pronta, ma non dovremo scendere a compromessi.
Quasi certamente, in tutta l'enorme abbondanza di soluzioni, ce n'è già una già pronta che farebbe al caso nostro, ma nel nostro caso è stato molto più veloce assemblare da soli un certo stack e personalizzarlo "per noi stessi" piuttosto che testare prodotti già pronti.
Con tutto ciò, non ci siamo sforzati di assemblare da soli un'intera piattaforma di monitoraggio, ma abbiamo cercato gli stack “già pronti” più funzionali, solo con la possibilità di configurarli in modo flessibile.
(B)ALCE?
La prima soluzione presa in considerazione è stata il noto stack ELK.
In effetti dovrebbe chiamarsi BELK, perché tutto inizia con Beats -
Naturalmente, ELK è una delle soluzioni più famose e potenti nel campo del monitoraggio, e ancor di più nella raccolta ed elaborazione dei log.
Volevamo che ELK venisse utilizzato per raccogliere log e per l'archiviazione a lungo termine dei parametri ottenuti da Prometheus.
Per la visualizzazione è possibile utilizzare Grafan.
Infatti, il nuovo stack ELK può raccogliere parametri in modo indipendente (metricbeat) e Kibana può anche visualizzarli.
Tuttavia, inizialmente ELK è nato dai log e finora la funzionalità delle metriche presenta una serie di gravi inconvenienti:
- Significativamente più lento di Prometeo
- Si integra in molti meno posti rispetto a Prometeo
- È difficile impostare avvisi per loro
- Le metriche occupano molto spazio
- L'impostazione di dashboard con metriche in Kiban è molto più complicata che in Grafan
In generale, le metriche in ELK sono pesanti e non ancora così convenienti come in altre soluzioni, di cui ora c'è molto più che solo Prometheus: TSDB, Victoria Metrics, Cortex, ecc., Ecc. Naturalmente mi piacerebbe davvero avere subito una soluzione all-in-one completa, ma nel caso di metricbeat ci sono stati troppi compromessi.
E lo stesso stack ELK presenta una serie di momenti difficili:
- È pesante, a volte anche molto pesante se si raccolgono una quantità di dati abbastanza grande
- Devi "sapere come cucinarlo", devi ridimensionarlo, ma non è banale
- Versione gratuita ridotta: la versione gratuita non dispone di avvisi normali e al momento della selezione non è stata effettuata alcuna autenticazione
Devo dire che recentemente l'ultimo punto è diventato migliore e in più (inclusa l'autenticazione) il modello di prezzo stesso ha iniziato a cambiare.
Ma nel momento in cui stavamo per implementare questa soluzione, non c’era alcun avviso.
Forse avremmo potuto provare a costruire qualcosa utilizzando ElastAlert o altre soluzioni della community, ma abbiamo comunque deciso di considerare altre alternative.
Loki - Grafana - Prometeo
Al momento, una buona soluzione potrebbe essere quella di creare uno stack di monitoraggio basato esclusivamente su Prometheus come fornitore di metriche, Loki per i log e per la visualizzazione è possibile utilizzare lo stesso Grafana.
Sfortunatamente, al momento dell'inizio delle vendite pilota del progetto (settembre-ottobre 19), Loki era ancora nella versione beta 0.3-0.4, e al momento dell'inizio dello sviluppo non poteva essere considerata una soluzione per la produzione. affatto.
Non ho ancora esperienza nell'utilizzo effettivo di Loki in progetti seri, ma posso dire che Promtail (un agente per la raccolta dei log) funziona benissimo sia per il bare metal che per i pod in Kubernetes.
TICK
Forse l'alternativa più degna (l'unica?) completa allo stack ELK ora può essere chiamata solo stack TICK: Telegraf, InfluxDB, Chronograf, Kapacitor.
Descriverò tutti i componenti di seguito in modo più dettagliato, ma l'idea generale è questa:
- Telegraf - agente per la raccolta di metriche
- InfluxDB: database delle metriche
- Kapacitor: processore di parametri in tempo reale per gli avvisi
- Chronograf - pannello web per la visualizzazione
Per InfluxDB, Kapacitor e Chronograf ci sono grafici ufficiali che abbiamo utilizzato per distribuirli.
Va notato che nell'ultima versione di Influx 2.0 (beta), Kapacitor e Chronograf sono entrati a far parte di InfluxDB e non esistono più separatamente
Telegrafo
è un agente molto leggero per la raccolta di parametri su una macchina a stati.
Può monitorare un'enorme quantità di tutto, da a
server .
Ha una serie di interessanti vantaggi:
- Veloce e leggero (scritto in Go)
- Mangia una quantità minima di risorse
- Push delle metriche per impostazione predefinita
- Raccoglie tutte le metriche necessarie
- Metriche di sistema senza alcuna impostazione
- Metriche hardware come informazioni provenienti dai sensori
- È molto semplice aggiungere le tue metriche
- Molti plugin pronti all'uso
- Raccoglie i log
Poiché per noi le metriche push erano necessarie, tutti gli altri vantaggi sono stati più che piacevoli aggiunte.
Anche la raccolta dei log da parte dell'agente stesso è molto comoda, poiché non è necessario collegare utilità aggiuntive per la registrazione dei log.
Influx offre l'esperienza più conveniente per lavorare con i log, se usi .
Telegraf è generalmente un ottimo agente per la raccolta di parametri, anche se non utilizzi il resto dello stack ICK.
Molte persone lo incrociano con ELK e vari altri database di serie temporali per comodità, poiché può scrivere parametri quasi ovunque.
InflussoDB
InfluxDB è il nucleo principale dello stack TICK, ovvero un database di serie temporali per le metriche.
Oltre alle metriche, Influx può anche memorizzare i log, sebbene, in sostanza, i log siano proprio le stesse metriche, solo che invece dei soliti indicatori numerici, la funzione principale è svolta da una riga di testo di log.
Anche InfluxDB è scritto in Go e sembra funzionare molto più velocemente rispetto a ELK sul nostro cluster (non il più potente).
Uno degli interessanti vantaggi di Influx includerebbe anche un'API molto comoda e ricca per le query di dati, che abbiamo utilizzato molto attivamente.
Svantaggi: $$$ o ridimensionamento?
Lo stack TICK ha un solo inconveniente che abbiamo scoperto: esso дорогой. Ancora di più.
Cosa ha la versione a pagamento che la versione gratuita non ha?
Per quanto siamo riusciti a capire, l'unica differenza tra la versione a pagamento dello stack TICK e quella gratuita sono le capacità di ridimensionamento.
Vale a dire, puoi creare un cluster con disponibilità elevata solo in .
Se desideri un'HA a tutti gli effetti, devi pagare o utilizzare alcune stampelle. Ci sono un paio di soluzioni comunitarie, ad esempio sembra una soluzione competente, ma è scritto che non è adatta alla produzione, inoltre
- una soluzione semplice con pompaggio dei dati tramite NATS (dovrà anche essere ridimensionata, ma questo può essere risolto).
È un peccato, ma entrambi sembrano essere stati abbandonati - non ci sono nuovi commit, presumo che il problema sia l'imminente rilascio della nuova versione di Influx 2.0, in cui molte cose saranno diverse (non ci sono informazioni su ridimensionandolo ancora).
Ufficialmente esiste una versione gratuita - in effetti, questo è un HA primitivo, ma solo attraverso il bilanciamento,
poiché tutti i dati verranno scritti su tutte le istanze InfluxDB dietro il sistema di bilanciamento del carico.
Ne ha alcuni come potenziali problemi con la sovrascrittura dei punti e la necessità di creare in anticipo basi per le metriche
(che avviene automaticamente durante il normale lavoro con InfluxDB).
Oltre , ciò comporta un sovraccarico aggiuntivo per i parametri duplicati (sia di elaborazione che di archiviazione) di cui potresti non aver bisogno, ma che non è possibile separarli.
Metriche di Victoria?
Di conseguenza, nonostante fossimo completamente soddisfatti dello stack TICK in tutto tranne che nel ridimensionamento a pagamento, abbiamo deciso di vedere se esistessero soluzioni gratuite che potessero sostituire il database InfluxDB, lasciando i restanti componenti T_CK.
Esistono molti database di serie temporali, ma il più promettente è Victoria Metrics, che presenta numerosi vantaggi:
- Facile e veloce, almeno stando ai risultati
- Esiste una versione cluster, sulla quale ora ci sono anche buone recensioni
- Può scheggiarsi
- Supporta il protocollo InfluxDB
Non avevamo intenzione di creare uno stack completamente personalizzato basato su Victoria e la speranza principale era che potessimo usarlo come sostituto immediato di InfluxDB.
Sfortunatamente, questo non è possibile, nonostante sia supportato il protocollo InfluxDB, funziona solo per la registrazione delle metriche: solo l'API Prometheus è disponibile “all'esterno”, il che significa che non sarà possibile impostare Chronograf su di essa.
Inoltre, per le metriche sono supportati solo valori numerici (abbiamo utilizzato valori stringa per le metriche personalizzate, maggiori informazioni nella sezione ).
Ovviamente, per lo stesso motivo, la VM non può archiviare i log come fa Influx.
Inoltre, va notato che al momento della ricerca della soluzione ottimale, Victoria Metrics non era ancora così popolare, la documentazione era molto più piccola e la funzionalità era più debole
(Non ricordo una descrizione dettagliata della versione del cluster e dello sharding).
Selezione di base
Di conseguenza, è stato deciso che per il progetto pilota ci saremmo comunque limitati a un singolo nodo InfluxDB.
Le ragioni principali di questa scelta sono state diverse:
- Ci è piaciuta molto l'intera funzionalità dello stack TICK
- Siamo già riusciti a implementarlo e ha funzionato benissimo
- Le scadenze stavano scadendo e non c’era molto tempo rimasto per testare altre opzioni.
- Non ci aspettavamo un carico così pesante
Non avevamo molti scooter per la prima fase del progetto pilota e i test durante lo sviluppo non hanno rivelato alcun problema di prestazioni.
Pertanto, abbiamo deciso che per questo progetto ci sarebbe bastato un nodo di afflusso senza necessità di ridimensionamento (vedi conclusioni alla fine).
Abbiamo deciso lo stack e la base, ora i restanti componenti dello stack TICK.
Condensatore
Kapacitor fa parte dello stack TICK, un servizio in grado di monitorare le metriche che entrano nel database in tempo reale ed eseguire varie azioni in base a regole.
In generale, è posizionato come uno strumento per il potenziale monitoraggio di anomalie e l'apprendimento automatico (non sono sicuro che queste funzioni siano richieste), ma il caso più popolare del suo utilizzo è più comune: gli avvisi.
È così che lo abbiamo utilizzato per le notifiche. Abbiamo impostato avvisi Slack quando un particolare scooter andava offline e lo stesso è stato fatto per caricabatterie intelligenti e importanti componenti dell'infrastruttura.
Ciò ha permesso di rispondere rapidamente ai problemi e di ricevere notifiche che tutto era tornato alla normalità.
Un semplice esempio: una batteria aggiuntiva per alimentare il nostro “box” si è rotta o per qualche motivo è scarica; semplicemente installandone una nuova, dopo poco dovremmo ricevere una notifica che la funzionalità del monopattino è stata ripristinata.
In Influx 2.0 Kapacitor è entrato a far parte di DB
Cronografo
Ho visto molte diverse soluzioni UI per il monitoraggio, ma posso dire che in termini di funzionalità e UX, niente è paragonabile a Chronograf.
Abbiamo iniziato a utilizzare lo stack TICK, stranamente, con Grafan come interfaccia web.
Non descriverò la sua funzionalità; tutti conoscono le sue ampie possibilità di impostare qualsiasi cosa.
Tuttavia, Grafana è ancora uno strumento completamente universale, mentre Chronograf è progettato principalmente per l'uso con Influx.
E naturalmente, grazie a questo, Chronograf può permettersi funzionalità molto più intelligenti e convenienti.
Forse la comodità principale di lavorare con Chronograf è che puoi visualizzare l'interno del tuo InfluxDB tramite Esplora.
Sembrerebbe che Grafana abbia funzionalità quasi identiche, ma in realtà la configurazione di una dashboard in Chronograf può essere eseguita con pochi clic del mouse (guardando allo stesso tempo la visualizzazione lì), mentre in Grafana prima o poi avrai comunque per modificare la configurazione JSON (ovviamente Chronograf consente di caricare i trattini configurati manualmente e di modificarli come JSON se necessario, ma non ho mai dovuto toccarli dopo averli creati sull'interfaccia utente).
Kibana ha funzionalità molto più ricche per la creazione di dashboard e controlli, ma la UX per tali operazioni è molto complessa.
Ci vorrà una buona comprensione per creare una comoda dashboard. E sebbene la funzionalità dei dashboard Chronograf sia inferiore, realizzarli e personalizzarli è molto più semplice.
I dashboard stessi, a parte il piacevole stile visivo, in realtà non sono diversi dai dashboard di Grafana o Kibana:
Ecco come appare la finestra di query:
È importante notare, tra le altre cose, che conoscendo i tipi di campi nel database InfluxDB, il cronografo stesso a volte può aiutarti automaticamente nella scrittura di una query o nella scelta della corretta funzione di aggregazione come media.
E, naturalmente, Chronograf è il più comodo possibile per visualizzare i registri. Sembra questo:
Per impostazione predefinita, i log di afflusso sono personalizzati per utilizzare syslog e pertanto hanno un parametro importante: la gravità.
Particolarmente utile è il grafico in alto, su di esso puoi vedere gli errori che si verificano e il colore mostra subito chiaramente se la gravità è maggiore.
Un paio di volte abbiamo rilevato bug importanti in questo modo, visualizzando i registri dell'ultima settimana e vedendo un picco rosso.
Naturalmente l'ideale sarebbe impostare avvisi per tali errori, dato che avevamo già tutto per questo.
L'abbiamo anche attivato per un po', ma durante il processo di preparazione del pilota, si è scoperto che ricevevamo parecchi errori (compresi quelli di sistema come l'indisponibilità della rete LTE), che "spammavano" il canale Slack troppo, senza causare alcun problema, grande beneficio.
La soluzione corretta sarebbe gestire la maggior parte di questi tipi di errori, adattarne la gravità e solo successivamente abilitare gli avvisi.
In questo modo, solo gli errori nuovi o importanti verrebbero pubblicati su Slack. Semplicemente non c’era abbastanza tempo per una simile impostazione date le scadenze ravvicinate.
autenticazione
Vale anche la pena ricordare che Chronograf supporta OAuth e OIDC come autenticazione.
Questo è molto comodo, poiché ti consente di collegarlo facilmente al tuo server e creare un SSO completo.
Nel nostro caso, il server era — veniva utilizzato per connettersi al monitoraggio, ma lo stesso server veniva utilizzato anche per autenticare scooter e richieste al back-end.
"Amministratore"
L'ultimo componente che descriverò è il nostro "pannello di amministrazione" da noi scritto in Vue.
Fondamentalmente è solo un servizio autonomo che visualizza contemporaneamente le informazioni sugli scooter dai nostri database, microservizi e dati metrici da InfluxDB.
Inoltre, molte funzioni amministrative sono state spostate lì, come il riavvio di emergenza o l’apertura remota di una serratura per il team di supporto.
C'erano anche delle mappe. Ho già detto che abbiamo iniziato con Grafana anziché con Chronograf, perché per Grafana sono disponibili mappe sotto forma di plugin, sui quali possiamo visualizzare le coordinate degli scooter. Sfortunatamente, le capacità dei widget delle mappe per Grafana sono molto limitate e, di conseguenza, è stato molto più semplice scrivere la propria applicazione web con le mappe in pochi giorni, in modo da non solo vedere le coordinate in questo momento, ma anche visualizzare il percorso effettuato dallo scooter, poter filtrare i dati su mappa, ecc. (tutta quella funzionalità che non potremmo configurare in una semplice dashboard).
Uno dei vantaggi già menzionati di Influx è la possibilità di creare facilmente le proprie metriche.
Ciò consente di utilizzarlo per una grande varietà di scenari.
Abbiamo provato a registrare lì tutte le informazioni utili: carica della batteria, stato di blocco, prestazioni del sensore, bluetooth, GPS e molti altri controlli di salute.
Abbiamo visualizzato tutto questo sul pannello di amministrazione.
Naturalmente, il criterio più importante per noi era lo stato operativo dello scooter - infatti, Influx lo controlla da solo e lo mostra con "luci verdi" nella sezione Nodi.
Questo viene fatto dalla funzione - l'abbiamo usato per comprendere le prestazioni del nostro box e inviare gli stessi avvisi a Slack.
A proposito, abbiamo chiamato gli scooter con i nomi dei personaggi dei Simpson: era così comodo distinguerli l'uno dall'altro
E in generale è stato più divertente così. Frasi come “Ragazzi, Smithers è morto!” si sentivano costantemente.
Metriche di stringa
È importante che InfluxDB consenta di memorizzare non solo valori numerici, come nel caso di Victoria Metrics.
Sembrerebbe che questo non sia così importante - dopotutto, oltre ai log, qualsiasi metrica può essere memorizzata sotto forma di numeri (basta aggiungere la mappatura per stati noti - una sorta di enumerazione)?
Nel nostro caso, c'era almeno uno scenario in cui le metriche delle stringhe erano molto utili.
È successo che il fornitore dei nostri “caricabatterie intelligenti” fosse una terza parte, non avevamo alcun controllo sul processo di sviluppo e sulle informazioni che questi caricabatterie potevano fornire.
Di conseguenza, le API di ricarica erano tutt'altro che ideali, ma il problema principale era che non sempre riuscivamo a capirne lo stato.
È qui che Influx è venuto in soccorso. Abbiamo semplicemente scritto lo stato della stringa che ci è arrivato nel campo del database InfluxDB senza modifiche.
Per qualche tempo sono arrivati solo valori come "online" e "offline", in base alle informazioni visualizzate nel nostro pannello di amministrazione e alle notifiche inviate a Slack. Tuttavia, ad un certo punto, anche lì hanno cominciato ad apparire valori come “disconnesso”.
Come si è scoperto in seguito, questo stato veniva inviato una volta dopo una perdita di connessione, se il caricabatterie non riusciva a stabilire una connessione con il server dopo un certo numero di tentativi.
Pertanto, se utilizzassimo solo un set fisso di valori, potremmo non vedere questi cambiamenti nel firmware al momento giusto.
E in generale, le metriche delle stringhe offrono molte più possibilità di utilizzo; puoi registrare praticamente qualsiasi informazione in esse contenuta. Anche se, ovviamente, devi anche usare questo strumento con attenzione.
Oltre alle solite metriche, abbiamo anche registrato le informazioni sulla posizione GPS in InfluxDB. Questo è stato incredibilmente utile per monitorare la posizione degli scooter nel nostro pannello di amministrazione.
Infatti sapevamo sempre dove e quale scooter era nel momento in cui avevamo bisogno.
Questo ci è stato molto utile quando cercavamo uno scooter (vedi conclusioni alla fine).
Monitoraggio delle infrastrutture
Oltre agli scooter stessi, dovevamo monitorare anche la nostra intera (piuttosto estesa) infrastruttura.
Un'architettura molto generale assomigliava a questa:
Se evidenziamo uno stack di monitoraggio puro, apparirà così:
Ciò che vorremmo controllare nel cloud è:
- Basi di dati
- Mantello delle chiavi
- Microservizi
Poiché tutti i nostri servizi cloud si trovano in Kubernetes, sarebbe bello raccogliere informazioni sul suo stato.
Fortunatamente, Telegraf può raccogliere immediatamente un numero enorme di metriche sullo stato del cluster Kubernetes e Chronograf offre immediatamente bellissime dashboard per questo.
Abbiamo monitorato principalmente le prestazioni dei pod e il consumo di memoria. In caso di caduta, avvisi in Slack.
Esistono due modi per tenere traccia dei pod in Kubernetes: DaemonSet e Sidecar.
Entrambi i metodi sono descritti in dettaglio .
Abbiamo utilizzato Telegraf Sidecar e, oltre alle metriche, abbiamo raccolto i log dei pod.
Nel nostro caso, abbiamo dovuto armeggiare con i registri. Nonostante Telegraf possa estrarre i log dall'API Docker, volevamo avere una raccolta uniforme di log con i nostri dispositivi finali e abbiamo configurato a questo scopo il syslog per i container. Forse questa soluzione non era bella, ma non ci sono state lamentele sul suo funzionamento e i registri venivano visualizzati bene in Chronograf.
Monitorare il monitoraggio???
Alla fine è sorta l'annosa questione del monitoraggio dei sistemi di monitoraggio, ma fortunatamente o sfortunatamente semplicemente non abbiamo avuto abbastanza tempo per questo.
Sebbene Telegraf possa facilmente inviare i propri parametri o raccogliere parametri dal database InfluxDB per inviarli allo stesso Influx o da qualche altra parte.
risultati
Quali conclusioni abbiamo tratto dai risultati del progetto pilota?
Come puoi effettuare il monitoraggio?
Innanzitutto lo stack TICK ha soddisfatto pienamente le nostre aspettative e ci ha dato ancora più opportunità di quanto ci aspettassimo inizialmente.
Tutte le funzionalità di cui avevamo bisogno erano presenti. Tutto ciò che abbiamo fatto con esso ha funzionato senza problemi.
Производительность
Il problema principale con lo stack TICK nella versione gratuita è la mancanza di funzionalità di ridimensionamento. Questo non è stato un problema per noi.
Non abbiamo raccolto dati/cifre esatti sul carico, ma abbiamo raccolto dati da circa 30 scooter alla volta.
Ognuno di loro ha raccolto più di tre dozzine di parametri. Allo stesso tempo sono stati raccolti i log dei dispositivi. La raccolta e l'invio dei dati avveniva ogni 10 secondi.
È importante notare che dopo una settimana e mezza del progetto pilota, quando la maggior parte dei "problemi infantili" sono stati corretti e i problemi più importanti erano già stati risolti, abbiamo dovuto ridurre la frequenza di invio dei dati al server per 30 secondi. Ciò si è reso necessario perché il traffico sulle nostre SIM LTE ha iniziato a scomparire rapidamente.
La maggior parte del traffico veniva consumata dai log; le metriche stesse, anche con un intervallo di 10 secondi, praticamente non lo sprecavano.
Di conseguenza, dopo un po' di tempo abbiamo disabilitato completamente la raccolta dei registri sui dispositivi, poiché problemi specifici erano già evidenti anche senza raccolta costante.
In alcuni casi, se la visualizzazione dei log fosse ancora necessaria, ci siamo semplicemente collegati tramite WireGuard tramite VPN.
Aggiungerò anche che ogni ambiente separato era separato l'uno dall'altro e il carico sopra descritto era rilevante solo per l'ambiente di produzione.
Nell'ambiente di sviluppo, abbiamo generato un'istanza InfluxDB separata che continuava a raccogliere dati ogni 10 secondi e non abbiamo riscontrato alcun problema di prestazioni.
TICK - ideale per progetti medio-piccoli
Sulla base di queste informazioni concludo che lo stack TICK è ideale per progetti relativamente piccoli o progetti che sicuramente non prevedono alcun HighLoad.
Se non disponi di migliaia di pod o centinaia di macchine, anche una sola istanza di InfluxDB gestirà correttamente il carico.
In alcuni casi, potresti essere soddisfatto di Influx Relay come soluzione primitiva ad alta disponibilità.
E, naturalmente, nessuno ti impedisce di impostare il ridimensionamento “verticale” e semplicemente di allocare server diversi per diversi tipi di parametri.
Se non sei sicuro del carico previsto sui servizi di monitoraggio, o hai la certezza di avere/avrai un'architettura molto “pesante”, non consiglierei di utilizzare la versione gratuita dello stack TICK.
Naturalmente, una soluzione semplice sarebbe l'acquisto - ma qui non posso commentare in qualche modo, poiché io stesso non ho familiarità con le sottigliezze. Oltre al fatto che è molto costoso e sicuramente non adatto alle piccole aziende.
In questo caso, oggi, consiglierei di cercare di raccogliere parametri tramite Victoria Metrics e log utilizzando Loki.
È vero, farò ancora una prenotazione sul fatto che Loki/Grafana sono molto meno convenienti (a causa della loro maggiore versatilità) rispetto ai TICK già pronti, ma sono gratuiti.
È importante: tutte le informazioni qui descritte sono relative alla versione Influx 1.8, al momento sta per essere rilasciata Influx 2.0.
Anche se non ho avuto la possibilità di provarlo in condizioni di combattimento ed è difficile trarre conclusioni sui miglioramenti, l'interfaccia è sicuramente migliorata ancora, l'architettura è stata semplificata (senza condensatore e cronografo),
sono comparsi i modelli ("killer feature" - ). Ma sfortunatamente, al momento, la versione 2 non ha la cosa fondamentale per cui abbiamo scelto la prima versione: non esiste una raccolta di registri.
Questa funzionalità apparirà anche in Influx 2.0, ma non siamo riusciti a trovare alcuna scadenza, nemmeno approssimativa.
Come non realizzare piattaforme IoT (ora)
Alla fine, dopo aver lanciato il progetto pilota, noi stessi abbiamo assemblato il nostro stack IoT completo, in assenza di un'alternativa adatta ai nostri standard.
Tuttavia, recentemente è disponibile in versione Beta — è un peccato che non fosse presente quando abbiamo iniziato a realizzare il progetto.
Siamo completamente soddisfatti del risultato finale e della piattaforma basata su Ansible + TICK + WireGuard che abbiamo assemblato noi stessi. Ma oggi consiglierei di dare un'occhiata più da vicino a Balena prima di provare a costruire tu stesso la tua piattaforma IoT.
Perché alla fine può fare la maggior parte di quello che abbiamo fatto noi, e OpenBalena è gratuito e open source.
Sa già non solo come inviare aggiornamenti, ma anche una VPN è già integrata e personalizzata per l'uso in un ambiente IoT.
E proprio di recente hanno persino rilasciato il loro , che si collega facilmente al loro ecosistema.
Ehi, che mi dici dello scooter scomparso?
Così lo scooter "Ralph" è scomparso senza lasciare traccia.
Siamo subito corsi a guardare la mappa nel nostro “pannello di amministrazione”, con i dati delle metriche GPS provenienti da InfluxDB.
Grazie ai dati di monitoraggio, abbiamo facilmente stabilito che lo scooter ha lasciato il parcheggio intorno alle 21:00 del giorno scorso, ha guidato per circa mezz'ora in una zona ed è rimasto parcheggiato fino alle 5 del mattino accanto a una casa tedesca.
Dopo le 5 del mattino non sono stati ricevuti dati di monitoraggio: ciò significava che la batteria aggiuntiva era completamente scarica oppure che l'aggressore era finalmente riuscito a rimuovere l'hardware intelligente dallo scooter.
Nonostante ciò, la polizia è stata comunque chiamata all'indirizzo dove si trovava lo scooter. Lo scooter non c'era.
Ma anche il proprietario della casa ne è rimasto sorpreso, dato che ieri sera è tornato a casa dall'ufficio con questo scooter.
Come si è scoperto, uno degli addetti all'assistenza è arrivato la mattina presto, ha preso lo scooter, vedendo che la batteria supplementare era completamente scarica e lo ha portato (a piedi) al parcheggio. E la batteria aggiuntiva si è guastata a causa dell'umidità.
Ci siamo rubati lo scooter. A proposito, non so come e chi abbia poi risolto il problema con il caso della polizia, ma il monitoraggio ha funzionato perfettamente...
Fonte: habr.com