Un annu fà avemu lanciatu una versione pilotu di un prughjettu promozionale per .
In principiu, u prughjettu era chjamatu Road-To-Barcelona, più tardi diventò Road-To-Berlin (da quì R2B in i screenshots), è à a fine si chjamava xRide.
L'idea principale di u prugettu era questu: invece di avè un serviziu di lucazione di vitture o scooters centralizati (parlemu di scooters aka motociclette elettriche, micca di kickscooters / scooters) avemu vulutu fà una piattaforma per un affittu decentralizatu. Circa e difficultà chì avemu scontru .
In principiu, u prughjettu fucalizza nantu à i vitture, ma per via di i termini, cumunicazioni estremamente longu cù i pruduttori è un gran numaru di restrizioni di sicurità, i scooters elettrici sò stati scelti per u pilotu.
L'utilizatore hà stallatu una applicazione iOS o Android in u telefunu, si avvicinava à u scooter chì li piacia, dopu chì u telefunu è u scooter hà stabilitu una cunnessione peer-to-peer, ETH hè statu scambiatu è l'utilizatore puderia inizià a corsa accendendu u scooter via. u telefonu. À a fine di u viaghju, era ancu pussibule di pagà per u viaghju cù Ethereu da a billetera di l'utilizatori in u telefunu.
In più di i scooters, l'utilizatore hà vistu "caricatori intelligenti" in l'applicazione, visitendu chì l'utilizatore puderia cambià a bateria attuale stessu s'ellu era bassu.
Questu hè in generale ciò chì pareva u nostru pilotu, lanciatu in settembre di l'annu passatu in duie cità tedesche: Bonn è Berlinu.
È tandu, un ghjornu, in Bonn, à prima matina, a nostra squadra di supportu (situata in situ per mantene i scooters in ordine) hè stata avvirtata : unu di i scooters era sparitu senza traccia.
Cumu truvà è rinvià?
In questu articulu vi parleraghju di questu, ma prima - di cumu avemu custruitu a nostra propria piattaforma IoT è cumu l'avemu monitoratu.
Chì è perchè monitorizà : scooters, infrastruttura, stazioni di ricarica ?
Allora, chì vulemu monitorà in u nostru prughjettu?
Prima di tuttu, questi sò i scooters stessi - i scooters elettrici stessi sò abbastanza caru, ùn pudete micca lancià un tali prughjettu senza esse abbastanza preparatu; se pussibule, vulete cullà quant'è più infurmazione pussibule nantu à i scooters: nantu à a so situazione, u livellu di carica. , etc.
Inoltre, mi piacerebbe monitorà u statu di a nostra propria infrastruttura IT - basa di dati, servizii è tuttu ciò chì anu bisognu di travaglià. Era ancu necessariu di vigilà l'estatus di i "caricatori intelligenti", in casu ch'elli si sguassate o sguassate di e batterie piene.
Scooters
Chì eranu i nostri scooters è chì vuliamu sapè di elli ?
U primu è più impurtante hè a coordenada GPS, postu chì grazia à elli pudemu capisce induve sò è induve si movenu.
In seguitu hè a carica di a bateria, grazia à quale pudemu stabilisce chì a carica di i scooters hè ghjunta à a fine è mandà un juicer o almenu avvistà l'utilizatore.
Di sicuru, hè ancu necessariu di verificà ciò chì succede cù i nostri cumpunenti Hardware:
- funziona bluetooth?
- U modulu GPS stessu funziona?
- Avemu avutu ancu un prublema cù u fattu chì u GPS puderia invià coordenate sbagliate è chjappà, è questu puderia esse determinatu solu da cuntrolli supplementari nantu à u scooter,
è avvisà u supportu u più prestu pussibule per risolve u prublema
- Avemu avutu ancu un prublema cù u fattu chì u GPS puderia invià coordenate sbagliate è chjappà, è questu puderia esse determinatu solu da cuntrolli supplementari nantu à u scooter,
È infine: cuntrolli di u software, cuminciendu cù u SO è u processatore, a rete è a carica di discu, finiscinu cù cuntrolli di i nostri moduli chì sò più specifichi per noi (, ).
Agriculture
Chì era a nostra parte di "ferru"?
In cunsiderà u più cortu tempu pussibule è a necessità di prototipu rapidu, avemu sceltu l'opzione più faciule per l'implementazione è a selezzione di cumpunenti - Raspberry Pi.
In più di u Rpi stessu, avemu avutu un bordu persunalizatu (chì avemu sviluppatu è urdinatu da a Cina per accelerà u prucessu di assemblea di a suluzione finale) è un set di cumpunenti - un relay (per accende / spegne u scooter), un lettore di carica di batteria, un modem, antenne. Tuttu chistu era imballatu compactly in una "xRide box" speciale.
Hè ancu esse nutatu chì tutta a scatula era alimentata da un bancu di putenza supplementu, chì à u turnu era alimentatu da a bateria principale di u scooter.
Questu hà permessu di usà u monitoraghju è accende u scooter ancu dopu à a fine di u viaghju, postu chì a bateria principale hè stata disattivata immediatamente dopu à vultà a chjave di ignizione à a pusizione "off".
Docker? Puru Linux? è implementazione
Riturnemu à u monitoraghju, cusì Raspberry - chì avemu?
Una di e prime cose chì vulemu aduprà per accelerà u prucessu di implementazione, aghjurnamentu è consegna di cumpunenti à i dispositi fisici era Docker.
Sfurtunatamente, hè diventatu prestu chjaru chì Docker in RPi, ancu s'ellu funziona, hà assai di sopra, in particulare in quantu à u cunsumu d'energia.
A sfarenza cù l'OS "nativu", ancu s'ellu ùn era micca cusì forte, era ancu abbastanza per noi per esse attenti à a pussibilità di perde a carica troppu rapidamente.
U sicondu mutivu era una di e nostre biblioteche partenarii nantu à Node.js (sic!) - l'unicu cumpunente di u sistema chì ùn era micca scrittu in Go/C/C++.
L'autori di a biblioteca ùn anu micca u tempu di furnisce una versione di travagliu in alcuna di e lingue "native".
Ùn hè micca solu u node stessu ùn hè micca a suluzione più elegante per i dispositi di bassa prestazione, ma a biblioteca stessu era assai affamata di risorse.
Avemu capitu chì, ancu s'ellu ci vulia, l'usu di Docker seria troppu sopratuttu per noi. A scelta hè stata fatta in favore di u SO nativu è travaglià direttamente sottu.
OS
In u risultatu, avemu, di novu, sceltu l'opzione più simplice cum'è u SO è utilizatu Raspbian (Debian build for Pi).
Scrivemu tuttu u nostru software in Go, cusì avemu ancu scrittu u modulu di l'agente hardware principale in u nostru sistema in Go.
Hè quellu chì hè rispunsevule per travaglià cù GPS, Bluetooth, leghje a carica, accende u scooter, etc.
Impulsà
A quistione hè ghjunta immediatamente nantu à a necessità di implementà un mecanismu per furnisce l'aghjurnamenti à i dispositi (OTA) - sia l'aghjurnamenti à u nostru agente / applicazione stessu, sia l'aghjurnamenti à u SO / u firmware stessu (perchè e novi versioni di l'agente puderianu bisognu di aghjurnamenti à u kernel). o cumpunenti di u sistema, biblioteche, etc.).
Dopu à una longa analisi di u mercatu, hè statu chì ci sò assai suluzioni per furnisce l'aghjurnamenti à u dispusitivu.
Da l'utilità relativamente simplice, per suprattuttu aghjurnà / dual-boot orientata cum'è swupd / SWUpdate / OSTree à piattaforme cum'è Mender è Balena.
Prima di tuttu, avemu decisu chì eramu interessatu in suluzioni end-to-end, cusì a scelta hè cascata immediatamente nantu à e plataforme.
Se stessa hè statu esclusu per u fattu chì in realtà usa u stessu Docker in u so balenaEngine.
Ma aghju nutatu chì malgradu questu, avemu finitu per aduprà constantemente u so pruduttu per u firmware flash nantu à e carte SD - una utilità simplice è estremamente convenientu per questu.
Dunque, à a fine, a scelta hè cascata . Mender hè una piattaforma cumpleta per assemblà, furnisce è installà firmware.
In generale, a piattaforma hè bella, ma ci hà pigliatu circa una settimana è mezza solu per custruisce a versione curretta di u nostru firmware cù u constructore di mender.
E più ci immersemu in l'intricacies di u so usu, più diventava chjaru chì per implementà cumplettamente avemu bisognu di più tempu di quellu chì aviamu.
Alas, i nostri termini stretti significavanu chì eramu furzati à abbandunà l'usu di Mender è sceglie un ancu più simplice.
Ansible
A suluzione più simplice in a nostra situazione era di utilizà Ansible. Un paru di playbooks era abbastanza per cumincià.
A so essenza era chì avemu simpliciamente cunnessu da l'ospitu (servitore CI) via ssh à i nostri rasberries è distribuite aghjurnamenti à elli.
À u principiu, tuttu era simplice - avete da esse in a listessa reta cù i dispositi, u pouring era fattu via Wi-Fi.
In l'uffiziu ci era solu una decina di lamponi di prova cunnessi à a listessa reta, ogni dispusitivu avia un indirizzu IP staticu ancu specificatu in Ansible Inventory.
Era Ansible chì hà furnitu u nostru agente di monitoraghju à i dispositi finali
3G / LTE
Sfortunatamente, stu casu d'usu per Ansible puderia solu travaglià in modu di sviluppu prima di avè avutu scooters attuali.
Perchè i scooters, cum'è avete capitu, ùn sò micca cunnessi à un router Wi-Fi, aspittendu constantemente l'aghjurnamenti nantu à a reta.
In rialità, i scooters ùn ponu micca avè alcuna cunnessione in tuttu altru ch'è u mobile 3G / LTE (è ancu allora micca sempre).
Questu impone immediatamente assai prublemi è limitazioni, cum'è a bassa velocità di cunnessione è a cumunicazione inestabile.
Ma u più impurtante hè chì in una reta 3G / LTE ùn pudemu micca solu confià in una IP statica assignata à a reta.
Questu hè parzialmente risoltu da alcuni fornitori di carte SIM; ci sò ancu carte SIM speciali pensate per i dispositi IoT cù indirizzi IP statici. Ma ùn avemu micca accessu à tali carte SIM è ùn pudemu micca aduprà l'indirizzi IP.
Di sicuru, ci era idee per fà un certu tipu di registrazione di l'indirizzi IP aka scuperta di serviziu in un locu cum'è Consul, ma avemu avutu a abbandunà tali idee, postu chì in i nostri testi l'indirizzu IP puderia cambià troppu spessu, chì hà purtatu à una grande inestabilità.
Per questa raghjone, l'usu più còmuda per a consegna di metriche ùn saria micca aduprà u mudellu di pull, induve andemu à i dispositi per i metrici necessarii, ma push, trasmette metriche da u dispusitivu direttamente à u servitore.
VPN
Comu suluzione à stu prublema, avemu sceltu VPN - in particulare .
Clienti (scooters) à l'iniziu di u sistema cunnessu à u servitore VPN è anu pussutu cunnette cù elli. Stu tunnellu hè stata utilizata per furnisce l'aghjurnamenti.
In teoria, u listessu tunelu puderia esse usatu per u monitoraghju, ma una tale cunnessione era più cumplicata è menu affidabile di una semplice spinta.
Risorse cloud
Infine, hè necessariu di monitorà i nostri servizii di nuvola è basa di dati, postu chì avemu usatu Kubernetes per elli, idealmente per chì implementà u monitoraghju in u cluster hè u più simplice pussibule. Ideale, usendu , postu chì per a implementazione, l'utilicemu in a maiò parte di i casi. E, sicuru, per monitorà u nuvulu, avete bisognu di utilizà e stesse suluzioni cum'è per i scooters stessi.
Datu
Phew, pare chì avemu risoltu a descrizzione, facemu una lista di ciò chì avemu bisognu à a fine:
- Una suluzione rapida, postu chì u monitoraghju hè necessariu digià durante u prucessu di sviluppu
- Volume / quantità - assai metrici necessarii
- A raccolta di log hè necessaria
- Affidabilità - i dati sò critichi per u successu di lancià
- Ùn pudete micca aduprà u mudellu pull - avete bisognu di spinta
- Avemu bisognu di un monitoraghju unificatu micca solu di hardware, ma ancu di nuvola
L'imaghjini finali pareva qualcosa cusì
Selezzione di stack
Dunque, avemu statu di fronte à a quistione di sceglie una pila di surviglianza.
Prima di tuttu, avemu cercatu a suluzione più cumpleta all-in-one chì copre simultaneamente tutte e nostre esigenze, ma à u stessu tempu esse abbastanza flexible per adattà u so usu à i nostri bisogni. Eppuru, avemu avutu parechje restrizioni imposte à noi da hardware, architettura è scadenze.
Ci hè una grande varietà di suluzioni di surviglianza, cuminciendu cù sistemi cumpletu cum'è , o è finisce cù suluzioni pronti per a gestione di Flotte.
Inizialmente, l'ultime pareva una soluzione ideale per noi, ma alcuni ùn anu micca un monitoraghju cumpletu, altri avianu capacità severamente limitate di e versioni libere, è altri simpricimenti ùn coprenu i nostri "vuluzioni" o ùn eranu micca abbastanza flessibili per adattà à i nostri scenarii. Certi sò simpricimenti obsoleti.
Dopu avè analizatu una quantità di suluzioni simili, avemu subitu à a cunclusione chì saria più faciule è più veloce di assemblea una pila simile. Iè, serà un pocu più cumplicatu chè implementà una piattaforma di gestione di Flotte cumplettamente pronta, ma ùn avemu micca da fà cumprumessi.
Quasi certamente, in tutta l'abbundanza enormosa di suluzioni, ci hè digià una pronta chì ci si cunvene cumplettamente, ma in u nostru casu era assai più veloce per assemble una certa pila per noi stessu è persunalizà "per noi" piuttostu cà. pruvà i prudutti pronti.
Cù tuttu questu, ùn avemu micca sforzatu di assemblà una piattaforma di surviglianza intera noi stessi, ma cercavamu i stacks "pronti" più funziunali, solu cù a capacità di cunfigurà in modu flexible.
(B) ELK?
A prima suluzione chì era veramente cunsiderata era a famosa pila ELK.
In fatti, deve esse chjamatu BELK, perchè tuttu principia cù Beats -
Di sicuru, ELK hè unu di i suluzioni più famosu è putenti in u campu di surviglianza, è ancu di più in cullizzioni è trasfurmazioni logs.
Avemu intesu chì ELK seria utilizatu per cullà i logs è ancu per u almacenamiento à longu andà di metriche ottenute da Prometheus.
Pudete aduprà Grafan per a visualizazione.
In fattu, a nova pila ELK pò cullà metriche indipindentamente (metricbeat), è Kibana pò ancu vede.
Ma ancu, ELK inizialmente hè cresciutu da logs è finu à avà a funziunalità di e metriche hà una quantità di svantaghji seri:
- Significativamente più lento di Prometheus
- Integra in assai menu posti di Prometheus
- Hè difficiuli di stallà alerti per elli
- A metrica occupanu assai spaziu
- L'installazione di dashboards cù metriche in Kiban hè assai più complicata chè in Grafan
In generale, e metriche in ELK sò pisanti è micca cusì cunvene cum'è in altre soluzioni, di quale ci sò avà assai più cà Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Di sicuru, mi piacerebbe veramente avè una soluzione all-in-one full-in-one subitu, ma in u casu di metricbeat ci era troppu cumprumessi.
È a pila ELK stessa hà una quantità di mumenti difficili:
- Hè pisanti, qualchì volta ancu assai pisanti s'è vo cullate una quantità abbastanza grande di dati
- Avete bisognu di "sapè a cucina" - avete bisognu di scala, ma questu ùn hè micca banale per fà.
- Versione libera spogliata - a versione libera ùn hà micca avvisu normale, è à u mumentu di a selezzione ùn ci era micca autentificazione
Devu dì chì pocu tempu l'ultimu puntu hè diventatu megliu è in più (cumpresa l'autentificazione) u mudellu di prezzu stessu hà cuminciatu à cambià.
Ma à l'epica quandu avemu da implementà sta suluzione, ùn ci era micca avvinte à tuttu.
Forsi avemu pussutu pruvà à custruisce qualcosa cù ElastAlert o altre suluzioni cumunità, ma avemu sempre decisu di cunsiderà altre alternative.
Loki - Grafana - Prometheus
À u mumentu, una bona suluzione puderia esse di custruisce una pila di monitoraghju basata solu nantu à Prometheus cum'è un fornitore di metrica, Loki per i logs, è per a visualizazione pudete aduprà a stessa Grafana.
Sfurtunatamente, à u mumentu di l'iniziu di u pilotu di vendita di u prughjettu (settembre-ottobre 19), Loki era sempre in versione beta 0.3-0.4, è à u mumentu di u principiu di u sviluppu ùn pudia esse cunsideratu cum'è una suluzione produtcion. per nunda.
Ùn aghju micca ancu sperienza in l'usu di Loki in prughjetti serii, ma possu dì chì Promtail (un agentu per a cullizzioni di logs) funziona bè per u bare-metal è pods in kubernetes.
TICCU
Forsi l'alternativa più degna (u solu?) full-featured à a pila ELK pò avà solu esse chjamata stack TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Descriveraghju tutti i cumpunenti sottu in più dettagliu, ma l'idea generale hè questu:
- Telegraf - agente per a cullizzioni di metriche
- InfluxDB - basa di dati di metrica
- Kapacitor - processore di metrica in tempu reale per l'alerta
- Chronograf - pannellu web per a visualizazione
Per InfluxDB, Kapacitor è Chronograf ci sò charts ufficiali di timone chì avemu usatu per implementà.
Hè da nutà chì in l'ultima versione di Influx 2.0 (beta), Kapacitor è Chronograf sò diventati parti di InfluxDB è ùn esistenu più separatamente.
Telegrafu
hè un agente assai ligeru per a cullizzioni di metriche nantu à una macchina statale.
Pò monitorà una quantità enorme di tuttu, da à
servitore .
Hà una quantità di vantaghji interessanti:
- Rapidu è ligeru (scrittu in Go)
- Manghja una quantità minima di risorse
- Push metrics per difettu
- Raccoglie tutte e metriche necessarie
- Metri di sistema senza paràmetri
- Metri di hardware cum'è l'infurmazioni da i sensori
- Hè assai faciule d'aghjunghje a vostra propria metrica
- Un saccu di plugins fora di a scatula
- Raccoglie logs
Siccomu i metrici di spinta eranu necessarii per noi, tutti l'altri vantaghji eranu più cà aghjunti piacevuli.
A cullizzioni di logs da l'agente stessu hè ancu assai còmuda, postu chì ùn ci hè micca bisognu di cunnette utilità supplementari per logs logs.
Influx offre l'esperienza più còmuda per travaglià cù logs se utilizate .
Telegraf hè in generale un grande agente per a cullizzioni di metriche, ancu s'ellu ùn utilizate micca u restu di a pila ICK.
Parechje persone l'attraversanu cù ELK è diverse altre basa di dati di serie temporale per comodità, postu chì pò scrive metriche quasi in ogni locu.
InfluxDB
InfluxDB hè u core principale di a pila TICK, vale à dì una basa di dati di serie temporale per metrica.
In più di metrica, Influx pò ancu almacenà logs, ancu s'è, in essenza, i logs per questu sò solu i stessi metrichi, solu invece di l'indicatori numerichi di solitu, a funzione principale hè realizata da una linea di testu di log.
InfluxDB hè ancu scrittu in Go è pare chì corre assai più veloce cumparatu cù ELK in u nostru cluster (micca u più putente).
Unu di i vantaghji interessanti di Influx include ancu una API assai còmuda è ricca per e dumande di dati, chì avemu usatu assai attivamente.
Svantaghji - $$$ o scala?
A pila TICK hà solu un inconveniente chì avemu scupertu - questu caru. Ancu di più.
Chì ci hè a versione pagata chì a versione libera ùn hà micca?
In quantu avemu pussutu capisce, l'unica diferenza trà a versione pagata di a pila TICK è quella libera hè a capacità di scala.
Vale à dì, pudete elevà un cluster cù alta dispunibilità solu in .
Se vulete HA cumpletu, avete bisognu di pagà o di utilizà qualchi crutches. Ci hè un coppiu di suluzioni cumunità - per esempiu s'assumiglia una suluzione cumpetente, ma hè scrittu chì ùn hè micca adattatu per a produzzione, è ancu
- una suluzione simplice cù u pumping di dati attraversu NATS (averà ancu esse scalatu, ma questu pò esse risoltu).
Hè un peccatu, ma tutti dui parenu esse abbandunati - ùn ci sò micca impegni freschi, suppone chì u prublema hè a liberazione prestu prevista di a nova versione di Influx 2.0, in quale parechje cose seranu diverse (ùn ci hè micca infurmazione nantu à scaling in it yet).
Ufficialmente ci hè una versione libera - in fattu, questu hè un HA primitivu, ma solu per equilibriu,
postu chì tutti i dati seranu scritti à tutti l'istanze InfluxDB daretu à u balancer di carica.
Ne hà alcuni cum'è prublemi potenziali cù i punti di sovrascrittura è a necessità di creà basi per metriche in anticipu
(chì succede automaticamente durante u travagliu normale cù InfluxDB).
Oltre , Questu significa sopratuttu supplementu per e metriche duplicate (sia u processu è u almacenamentu) chì ùn avete micca bisognu, ma ùn ci hè manera di separà.
Victoria Metrics?
In u risultatu, malgradu u fattu chì eramu cumplettamente soddisfatti di a pila di TICK in tuttu ciò chì ùn hè micca pagatu scala, avemu decisu di vede s'ellu ci era solu suluzioni gratuiti chì puderanu rimpiazzà a basa di dati InfluxDB, mentre abbanduneghja i cumpunenti T_CK restante.
Ci hè parechje basa di dati di serie di u tempu, ma a più promettente hè Victoria Metrics, hà una quantità di vantaghji:
- Rapidu è faciule, almenu secondu i risultati
- Ci hè una versione cluster, nantu à quale ci sò ancu boni critichi avà
- Ella pò frammentà
- Supporta u protocolu InfluxDB
Ùn avemu micca intenzione di custruisce una pila cumpletamente persunalizata basatu annantu à Victoria è a speranza principale era chì pudemu usà cum'è un rimpiazzamentu drop-in per InfluxDB.
Sfortunatamente, questu ùn hè micca pussibule, malgradu u fattu chì u protokollu InfluxDB hè supportatu, funziona solu per a registrazione di metriche - solu l'API Prometheus hè dispunibule "fora", chì significa chì ùn serà micca pussibule di mette Chronograf nantu à questu.
Inoltre, solu i valori numerichi sò supportati per e metriche (avemu utilizatu valori di stringa per metriche persunalizati - più nantu à questu in a sezione ).
Ovviamente, per a stessa ragione, a VM ùn pò micca almacenà logs cum'è Influx.
Inoltre, deve esse nutatu chì à u mumentu di a ricerca di a suluzione ottima, Victoria Metrics ùn era ancu cusì populari, a documentazione era assai più chjuca è a funziunalità era più debule.
(Ùn mi ricordu micca una descrizzione dettagliata di a versione di cluster è sharding).
Selezzione di basa
In u risultatu, hè statu decisu chì per u pilotu avemu sempre limitatu à un unicu node InfluxDB.
Ci era parechje motivi principali per sta scelta:
- Ci hè piaciutu assai tutta a funziunalità di a pila TICK
- Avemu digià riesciutu à implementà è hà travagliatu bè
- I termini s'eranu scappati è ùn ci era micca assai tempu per pruvà altre opzioni.
- Ùn avemu micca aspittatu una carica cusì pesante
Ùn avemu micca assai scooters per a prima fase di u pilotu, è e teste durante u sviluppu ùn anu revelatu nisun prublema di rendiment.
Dunque, avemu decisu chì per stu prughjettu un node Influx seria abbastanza per noi senza bisognu di scaling (vede cunclusioni à a fine).
Avemu decisu nantu à a pila è a basa - avà nantu à i cumpunenti rimanenti di a pila TICK.
Capacitor
Kapacitor face parte di a pila TICK, un serviziu chì pò monitorà e metriche chì entra in a basa di dati in tempu reale è eseguisce diverse azzioni basate nantu à e regule.
In generale, hè posizionatu cum'è un strumentu per u seguimentu di l'anomali potenziale è l'apprendimentu di machine (ùn sò micca sicuru chì queste funzioni sò in dumanda), ma u casu più populari di u so usu hè più cumuni - alerting.
Hè cusì chì l'avemu utilizatu per e notificazioni. Avemu stabilitu avvisi Slack quandu un scooter particulari hè andatu offline, è u listessu hè statu fattu per i caricatori intelligenti è i cumpunenti infrastrutturali impurtanti.
Questu hà permessu di risponde rapidamente à i prublemi, è ancu di riceve notificazioni chì tuttu era tornatu à u normale.
Un esempiu simplice: una batteria supplementu per alimentà a nostra "scatola" hè stata rotta o per qualchì mutivu hà scappatu di u putere; solu installendu una nova, dopu un pocu duvemu riceve una notificazione chì a funziunalità di u scooter hè stata restaurata.
In Influx 2.0 Kapacitor hè diventatu parte di DB
Cronografu
Aghju vistu parechje soluzioni UI diverse per u monitoraghju, ma possu dì chì in termini di funziunalità è UX, nunda si compara à Chronograf.
Avemu cuminciatu à aduprà a pila TICK, stranamente, cù Grafan cum'è una interfaccia web.
Ùn descriveraghju micca a so funziunalità; ognunu sapi e so larga pussibulità per stallà qualcosa.
Tuttavia, Grafana hè sempre un strumentu cumplettamente universale, mentri Chronograf hè principalmente pensatu per l'usu cù Influx.
E, sicuru, grazia à questu, Chronograf pò permette una funziunalità assai più intelligente o cunvene.
Forse a cunvenzione principale di travaglià cù Chronograf hè chì pudete vede l'internu di u vostru InfluxDB attraversu Esplora.
Sembra chì Grafana hà una funziunalità guasi identica, ma in realtà, a creazione di un dashboard in Chronograf pò esse fatta cù uni pochi di clicchi di u mouse (à u stessu tempu fighjendu a visualizazione quì), mentre chì in Grafana avete sempre prima o dopu avè. per edità a cunfigurazione JSON (di sicuru Chronograf permette di caricate i vostri dashas cunfigurati manualmente è edità cum'è JSON se ne necessariu - ma ùn aghju mai avutu toccu dopu avè creatu in l'UI).
Kibana hà capacità assai più ricche per creà dashboards è cuntrolli per elli, ma l'UX per tali operazioni hè assai cumplessu.
Ci hà da piglià una bona intelligenza per creà un dashboard convenientu. E ancu se a funziunalità di i dashboards Chronograf hè menu, fà è persunalizà elli hè assai più simplice.
I dashboards stessi, fora di u piacevule stile visuale, ùn sò in realtà micca diffirenti da i dashboards in Grafana o Kibana:
Eccu ciò chì pare a finestra di a dumanda:
Hè impurtante di nutà, frà altre cose, chì sapendu i tipi di campi in a basa di dati InfluxDB, u cronografu stessu pò volte automaticamente aiutà à scrive una Query o scegliendu a funzione di aggregazione curretta cum'è significa.
E, sicuru, Chronograf hè u più convenientu pussibule per vede logs. Sembra cusì:
Per automaticamente, i logs Influx sò adattati per utilizà syslog è per quessa anu un parametru impurtante - a gravità.
U graficu in cima hè soprattuttu utile; nantu à questu pudete vede l'errori chì accadenu è u culore mostra immediatamente chjaramente se a gravità hè più alta.
Un paru di volte avemu pigliatu bug impurtanti in questu modu, andendu à vede i logs per l'ultima settimana è videndu un spike rossu.
Di sicuru, l'ideale seria di stallà alerti per tali errori, postu chì avemu digià avutu tuttu per questu.
Avemu ancu attivatu questu per un certu tempu, ma in u prucessu di preparazione di u pilotu, hè statu fattu chì avemu avutu assai errori (cumpresu quelli di u sistema cum'è l'indisponibilità di a reta LTE), chì anu "spammatu" ancu u canali Slack. assai, senza pruvucà alcunu prublemi. gran benefiziu.
A suluzione curretta seria di trattà a maiò parte di sti tipi d'errori, aghjustà a gravità per elli, è solu dopu attivà l'alerta.
In questu modu, solu errori novi o impurtanti seranu publicati à Slack. Ùn ci era simplicemente micca abbastanza tempu per una tale stallazione datu i termini stretti.
Autenticazione
Hè vale a pena nutà chì Chronograf supporta OAuth è OIDC cum'è autentificazione.
Questu hè assai còmuda, postu chì vi permette di facilmente attaccà à u vostru servitore è creà SSO cumpletu.
In u nostru casu, u servitore era - hè stata utilizata per cunnette à u monitoraghju, ma u stessu servitore hè statu ancu usatu per autentificà i scooters è e dumande à u back-end.
"Admin"
L'ultimu cumpunente chì descriveraghju hè u nostru "pannellu di amministrazione" autoscritto in Vue.
In fondu hè solu un serviziu autònumu chì mostra l'infurmazioni di scooter da e nostre basa di dati, microservizi è dati di metrica da InfluxDB simultaneamente.
Inoltre, parechje funzioni amministrative sò state spustate quì, cum'è un reboot d'emergenza o l'apertura remota di una serratura per a squadra di supportu.
Ci era ancu carte. Aghju digià citatu chì avemu principiatu cù Grafana invece di Chronograf - perchè per i mape Grafana sò dispunibili in forma di plugins, nantu à quale pudemu vede e coordenate di scooters. Sfortunatamente, e capacità di i widgets di mappa per Grafana sò assai limitati, è in u risultatu, era assai più faciule per scrive a vostra propria applicazione web cù carte in pochi ghjorni, per ùn vede micca solu e coordenate in u mumentu, ma ancu vede. u percorsu pigliatu da u scooter, esse capaci di filtrà i dati nantu à a mappa, etc. (tutta quella funziunalità chì ùn pudemu micca cunfigurà in un dashboard simplice).
Unu di i vantaghji digià citati di Influx hè a capacità di creà facilmente e vostre metriche.
Questu permette di esse usatu per una grande varietà di scenarii.
Avemu pruvatu à registrà tutte l'infurmazioni utili quì: carica di a batteria, statutu di serratura, prestazioni di sensori, bluetooth, GPS è assai altri cuntrolli di salute.
Avemu mostratu tuttu questu nantu à u pannellu admin.
Di sicuru, u criteriu più impurtante per noi era a cundizione operativa di u scooter - in fattu, Influx verifica questu stessu è mostra cù "luci verdi" in a sezione Nodes.
Questu hè fattu da a funzione - l'avemu utilizatu per capisce u funziunamentu di a nostra scatula è mandà sti stessi avvisi à Slack.
In modu, avemu chjamatu i scooters dopu à i nomi di i caratteri di The Simpsons - era cusì cunvene per distinguelli l'una di l'altru.
È in generale era più divertente in questu modu. Frasi cum'è "Ragazzi, Smithers hè mortu!" Eranu sempre intesu.
Metri di stringa
Hè impurtante chì InfluxDB permette di almacenà micca solu i valori numerichi, cum'è u casu cù Victoria Metrics.
Sembra chì questu ùn hè micca cusì impurtante - dopu à tuttu, fora di i logs, ogni metrica pò esse guardatu in forma di numeri (solu aghjunghje mapping per i stati cunnisciuti - un tipu d'enum)?
In u nostru casu, ci era almenu un scenariu induve e metriche di stringa eranu assai utili.
Hè accadutu cusì chì u fornitore di i nostri "caricatori intelligenti" era un terzu, ùn avemu avutu micca cuntrollu di u prucessu di sviluppu è l'infurmazioni chì questi caricatori puderanu furnisce.
In u risultatu, l'API di carica era luntanu da l'ideale, ma u prublema principali era chì ùn pudemu micca sempre capisce u so statu.
Questu hè induve Influx hè ghjuntu in salvezza. Avemu simpliciamente scrittu u statutu di stringa chì hè ghjuntu à noi in u campu di a basa di dati InfluxDB senza cambiamenti.
Per qualchì tempu, solu i valori cum'è "in linea" è "offline" sò ghjunti quì, basatu nantu à quale infurmazione hè stata mostrata in u nostru pannellu di amministrazione, è e notificazioni sò state mandate à Slack. Tuttavia, à un certu puntu, i valori cum'è "disconnected" anu ancu cuminciatu à apparisce.
Cum'è turnò dopu, stu statutu hè statu mandatu una volta dopu una perdita di cunnessione, se u caricatore ùn pudia micca stabilisce una cunnessione cù u servitore dopu un certu numaru di tentativi.
Cusì, se avemu usatu solu un settore fissu di valori, ùn pudemu micca vede questi cambiamenti in u firmware à u mumentu propiu.
È in generale, e metriche di stringa furnisce assai più pussibulità per l'usu; pudete registrà quasi ogni infurmazione in elli. Ancu s'è, sicuru, avete ancu bisognu di utilizà stu strumentu cù cura.
In più di e metriche di solitu, avemu ancu registratu l'infurmazioni di locu GPS in InfluxDB. Questu era incredibbilmente utile per monitorizà a situazione di scooters in u nostru pannellu di amministrazione.
In fatti, avemu sempre saputu induve è quale scooter era in u mumentu chì avemu bisognu.
Questu hè statu assai utile per noi quandu avemu cercatu un scooter (vede cunclusioni à a fine).
Monitoraghju di l'infrastruttura
In più di i scooters stessi, avemu ancu bisognu di monitorà tutta a nostra infrastruttura (piuttostu estensiva).
Una architettura assai generale pareva qualcosa cusì:
Se mettemu in risaltu una pila di monitoraghju pura, pare cusì:
Ciò chì vulemu verificà in u nuvulu hè:
- Basi di dati
- chiavi
- Microservizi
Siccomu tutti i nostri servizii di nuvola sò situati in Kubernetes, saria bonu per cullà infurmazioni nantu à u so statu.
Fortunatamente, Telegraf fora di a scatula pò cullà un gran numaru di metriche nantu à u statu di u cluster Kubernetes, è Chronograf offre immediatamente belli dashboards per questu.
Avemu principarmenti monitoratu u rendiment di i pods è u cunsumu di memoria. In casu di caduta, avvisi in Slack.
Ci hè dui modi per seguità pods in Kubernetes: DaemonSet è Sidecar.
I dui metudi sò descritti in detail .
Avemu usatu Telegraf Sidecar è, in più di e metriche, raccolte pod logs.
In u nostru casu, avemu avutu a tinker with the logs. Malgradu u fattu chì Telegraf pò tirà logs da l'API Docker, vulemu avè una cullizzioni uniforme di logs cù i nostri dispositi finali è cunfigurati syslog per cuntenituri per questu. Forsi sta suluzione ùn era micca bella, ma ùn ci era micca lagnanza nantu à u so travagliu è i logs sò stati affissati bè in Chronograf.
Monitorà u monitoraghju ???
In fine, a questione vechja di i sistemi di surviglianza di u monitoraghju hè ghjunta, ma per furtuna, o sfurtunatamenti, ùn avemu micca abbastanza tempu per questu.
Ancu Telegraf pò facilmente mandà e so propria metrica o cullà metriche da a basa di dati InfluxDB per mandà à u stessu Influx o in un altru locu.
scuperti
Chì cunclusioni avemu tiratu da i risultati di u pilotu ?
Cumu pudete fà u monitoraghju?
Prima di tuttu, a pila di TICK hà cumplettamente cumplettamente e nostre aspettative è ci hà datu ancu più opportunità di ciò chì ci aspettavamu inizialmente.
Tutte e funziunalità chì avemu bisognu era presente. Tuttu ciò chì avemu fattu cun ellu hà travagliatu senza prublemi.
Produttività
U prublema principali cù a pila TICK in a versione libera hè a mancanza di capacità di scala. Questu ùn era micca un prublema per noi.
Ùn avemu micca recullatu dati / figure di carica esatta, ma avemu cullatu dati da circa 30 scooters à u tempu.
Ognunu di elli hà cullatu più di trè decine di metriche. À u listessu tempu, i logs da i dispositi sò stati cullati. A cullizzioni di dati è u mandatu hè accadutu ogni 10 seconde.
Hè impurtante à nutà chì dopu à una settimana è a mità di u pilotu, quandu a maiò parte di i "prublemi di a zitiddina" sò stati curretti è i prublemi più impurtanti eranu digià risolti, avemu avutu a riduzzione di a freccia di mandà dati à u servitore. 30 seconde. Questu hè diventatu necessariu perchè u trafficu nantu à e nostre carte SIM LTE hà cuminciatu à sparisce rapidamente.
A maiò parte di u trafficu hè stata cunsumata da i logs; i metrici stessi, ancu cù un intervallu di 10 seconde, praticamenti ùn anu micca persu.
In u risultatu, dopu qualchì tempu avemu disattivatu cumplettamente a cullizzioni di logs nantu à i dispositi, postu chì i prublemi specifichi eranu digià evidenti ancu senza cullizzioni constante.
In certi casi, se a visualizazione di i logs era sempre necessariu, avemu simpliciamente cunnessu via WireGuard via VPN.
Aghju aghjustatu ancu chì ogni ambiente separatu hè statu separatu l'una di l'altru, è a carica descritta sopra era pertinente solu per l'ambiente di produzzione.
In l'ambienti di sviluppu, avemu risuscitatu una istanza InfluxDB separata chì cuntinuava à cullà dati ogni 10 seconde è ùn avemu micca incuntratu in prublemi di rendiment.
TICK - ideale per prughjetti chjuchi à mediu
Basatu nantu à sta infurmazione, avissi da cuncludi chì a pila TICK hè ideale per prughjetti relativamente chjuchi o prughjetti chì definitivamente ùn aspetta micca HighLoad.
Se ùn avete micca millaie di pods o centinaie di macchine, ancu una istanza InfluxDB gestirà a carica bè.
In certi casi, pudete esse cuntentu di Influx Relay cum'è una soluzione primitiva d'Alta Disponibilità.
E, sicuru, nimu ùn vi impedisce micca di stabilisce a scala "verticale" è di semplicemente attribuisce diversi servitori per diversi tipi di metriche.
Se ùn site micca sicuru di a carica prevista nantu à i servizii di surviglianza, o sì garantitu d'avè / averà una architettura assai "pesante", ùn vi ricumanderaghju micca di utilizà a versione libera di a pila TICK.
Di sicuru, una suluzione simplice seria di cumprà - ma quì ùn possu micca cummentà in qualchì modu, postu chì ùn sò micca familiarizatu cù e suttilità. In più di u fattu chì hè assai caru è definitu micca adattatu per e piccule imprese.
In questu casu, oghje, vi cunsigliu di circà à cullà metriche attraversu Victoria Metrics è logs cù Loki.
True, aghju da novu fà una riservazione chì Loki / Grafana sò assai menu convenienti (per via di a so versatilità più grande) chì u TICK ready-made, ma sò liberi.
impurtanti: tutte l'infurmazioni descritte quì sò pertinenti per a versione Influx 1.8, in u mumentu Influx 2.0 hè per esse liberatu.
Mentre ùn aghju micca avutu l'uppurtunità di pruvà in cundizioni di cummattimentu è hè difficiule di piglià cunclusioni nantu à e migliure, l'interfaccia hè diventata definitivamente ancu megliu, l'architettura hè stata simplificata (senza kapacitor è chronograf),
i mudelli apparsu ("funzione killer" - ). Ma, sfurtunatamenti, in u mumentu, a versione 2 ùn hà micca a cosa chjave per quale avemu sceltu a prima versione - ùn ci hè micca una cullizzioni di log.
Sta funziunalità appariscerà ancu in Influx 2.0, ma ùn pudemu truvà nisuna scadenza, ancu apprussimata.
Cumu ùn fà micca e plataforme IoT (ora)
In fine, dopu avè lanciatu u pilotu, avemu assemblatu a nostra propria pila IoT cumpleta, in mancanza di una alternativa adatta à i nostri standard.
Tuttavia, recentemente hè dispunibule in versione Beta - hè una pena ch'ella ùn era micca quì quandu avemu cuminciatu à fà u prugettu.
Semu cumplettamente soddisfatti di u risultatu finale è di a piattaforma basata in Ansible + TICK + WireGuard chì avemu assemblatu noi stessi. Ma oghje, vi cunsigliu di piglià un ochju più attentu à Balena prima di pruvà à custruisce a vostra propria piattaforma IoT.
Perchè in fine pò fà a maiò parte di ciò chì avemu fattu, è OpenBalena hè liberu è open source.
Sapi digià cumu ùn solu mandà l'aghjurnamenti, ma ancu una VPN hè digià integrata è adattata per l'usu in un ambiente IoT.
È pocu tempu, anu ancu liberatu u so , chì cunnetta facilmente à u so ecosistema.
Ehi, chì ne di u scooter mancante ?
Allora u scooter, "Ralph", hè sparitu senza traccia.
Avemu subitu subitu à guardà a mappa in u nostru "pannellu di amministrazione", cù dati di metrica GPS da InfluxDB.
Grazie à i dati di monitoraghju, avemu facilmente determinatu chì u scooter abbandunò u parcheghju versu 21: 00 l'ultimu ghjornu, hà guidatu circa una meza ora in una certa zona è hè stata parcheggiata finu à 5 am vicinu à una casa tedesca.
Dopu à 5 a.m., ùn sò micca ricevuti dati di monitoraghju - questu significava chì a bateria supplementaria hè stata completamente scaricata, o l'attaccante hà finalmente capitu cumu caccià l'hardware intelligente da u scooter.
Malgradu questu, a polizia era sempre chjamata à l'indirizzu induve u scooter era situatu. U scooter ùn era micca quì.
In ogni casu, u pruprietariu di a casa hè statu ancu sorpresu da questu, postu ch'ellu hà veramente guidatu stu scooter in casa da l'uffiziu a notte passata.
Cum'è s'hè risultatu, unu di l'impiegati di supportu hè ghjuntu prima di a matina è hà pigliatu u scooter, videndu chì a so bateria supplementaria hè stata completamente scaricata è u pigliò (à pede) à u parking. È a bateria supplementu hà fallutu per via di l'umidità.
Avemu arrubbatu u scooter da noi stessi. Per via, ùn sò micca sapè cumu è quale hà risoltu u prublema cù u casu di a polizia, ma u monitoraghju hà travagliatu perfettamente...
Source: www.habr.com