Fa un any vam llançar una versió pilot d'un projecte promocional per a .
Inicialment, el projecte es va anomenar Road-To-Barcelona, després es va convertir en Road-To-Berlin (d'aquí R2B a les captures de pantalla), i al final es va anomenar xRide.
La idea principal del projecte era aquesta: en comptes de tenir un servei de lloguer de cotxes o patinets centralitzat (estem parlant de patinets també coneguts com motos elèctriques, no de kickscooters/scooters) volíem fer una plataforma de lloguer descentralitzat. Sobre les dificultats que hem trobat .
Inicialment, el projecte es va centrar en els cotxes, però a causa dels terminis, les comunicacions extremadament llargues amb els fabricants i un gran nombre de restriccions de seguretat, es van triar patinets elèctrics per al pilot.
L'usuari va instal·lar una aplicació iOS o Android al telèfon, es va apropar al patinet que li agradava, després de la qual cosa el telèfon i el patinet van establir una connexió peer-to-peer, es va intercanviar ETH i l'usuari podia començar el viatge engegant el patinet mitjançant el telèfon. Al final del viatge, també era possible pagar el viatge mitjançant Ethereum des de la cartera de l'usuari al telèfon.
A més dels patinets, l'usuari va veure "carregadors intel·ligents" a l'aplicació, visitant els quals l'usuari podia canviar ell mateix la bateria actual si estava baixa.
En general, aquest és el que semblava el nostre pilot, llançat el setembre de l'any passat a dues ciutats alemanyes: Bonn i Berlín.
I aleshores, un dia, a Bonn, a primera hora del matí, el nostre equip de suport (ubicat in situ per mantenir els patinets en bon funcionament) va ser alertat: un dels patinets havia desaparegut sense deixar rastre.
Com trobar-lo i tornar-lo?
En aquest article parlaré d'això, però primer, de com vam construir la nostra pròpia plataforma IoT i com la vam supervisar.
Què i per què controlar: patinets, infraestructures, estacions de recàrrega?
Aleshores, què volíem controlar en el nostre projecte?
En primer lloc, aquests són els patinets mateixos: els patinets elèctrics són bastant cars, no podeu llançar un projecte d'aquest tipus sense estar prou preparat; si és possible, voleu recollir la màxima informació possible sobre els patinets: sobre la seva ubicació, nivell de càrrega , etc.
A més, m'agradaria controlar l'estat de la nostra pròpia infraestructura informàtica: bases de dades, serveis i tot el que necessiten per funcionar. També calia controlar l'estat dels "carregadors intel·ligents", en cas que s'avaria o es quedaven sense bateries plenes.
Scooters
Quins eren els nostres patinets i què volíem saber d'ells?
El primer i més important són les coordenades GPS, ja que gràcies a elles podem entendre on són i on es mouen.
El següent és la càrrega de la bateria, gràcies a la qual podem determinar que la càrrega dels patinets s'està acabant i enviar un espremedor o almenys avisar l'usuari.
Per descomptat, també cal comprovar què està passant amb els nostres components de maquinari:
- funciona el bluetooth?
- funciona el mòdul GPS en si?
- També vam tenir un problema amb el fet que el GPS podia enviar coordenades incorrectes i quedar-se encallat, i això només es va poder determinar mitjançant comprovacions addicionals al patinet,
i aviseu al servei d'assistència tan aviat com sigui possible per resoldre el problema
- També vam tenir un problema amb el fet que el GPS podia enviar coordenades incorrectes i quedar-se encallat, i això només es va poder determinar mitjançant comprovacions addicionals al patinet,
I per últim: comprovacions del programari, començant pel SO i el processador, la càrrega de la xarxa i del disc, acabant amb les comprovacions dels nostres mòduls que són més específics per a nosaltres (, ).
Maquinari
Quina era la nostra part de "ferro"?
Tenint en compte el període de temps més curt possible i la necessitat d'un prototipat ràpid, vam triar l'opció més senzilla per a la implementació i selecció de components: Raspberry Pi.
A més del propi Rpi, teníem un tauler personalitzat (que nosaltres mateixos vam desenvolupar i encarregar a la Xina per accelerar el procés de muntatge de la solució final) i un conjunt de components: un relé (per encendre/apagar el scooter), un lector de càrrega de bateries, un mòdem, antenes. Tot això es va empaquetar de manera compacta en una "caixa xRide" especial.
També cal tenir en compte que tota la caixa estava alimentada per un banc d'energia addicional, que al seu torn funcionava amb la bateria principal del scooter.
Això va permetre utilitzar el monitoratge i encendre el scooter fins i tot després del final del viatge, ja que la bateria principal es va apagar immediatament després de girar la clau d'encesa a la posició "apagada".
Docker? Linux senzill? i desplegament
Tornem al monitoratge, doncs Raspberry, què tenim?
Una de les primeres coses que volíem utilitzar per accelerar el procés de desplegament, actualització i lliurament de components als dispositius físics va ser Docker.
Malauradament, ràpidament es va fer evident que Docker a RPi, tot i que funciona, té moltes despeses generals, sobretot pel que fa al consum d'energia.
La diferència amb l'ús del sistema operatiu "natiu", encara que no tan forta, encara va ser suficient per tenir cura de la possibilitat de perdre càrrega massa ràpidament.
La segona raó va ser una de les nostres biblioteques associades a Node.js (sic!), l'únic component del sistema que no estava escrit en Go/C/C++.
Els autors de la biblioteca no van tenir temps de proporcionar una versió de treball en cap dels idiomes “nadius”.
No només el node en si no és la solució més elegant per a dispositius de baix rendiment, sinó que la biblioteca en si mateixa necessitava molt de recursos.
Ens vam adonar que, fins i tot si volguéssim, utilitzar Docker seria una sobrecàrrega massa per a nosaltres. L'elecció es va fer a favor del sistema operatiu natiu i treballar directament sota ell.
OS
Com a resultat, vam triar, de nou, l'opció més senzilla com a sistema operatiu i vam utilitzar Raspbian (build de Debian per a Pi).
Escrivim tot el nostre programari a Go, de manera que també vam escriure el mòdul d'agent de maquinari principal al nostre sistema a Go.
És ell qui s'encarrega de treballar amb GPS, Bluetooth, llegir la càrrega, encendre el patinet, etc.
Desplega
Immediatament va sorgir la pregunta sobre la necessitat d'implementar un mecanisme per lliurar actualitzacions als dispositius (OTA), tant les actualitzacions del nostre agent/aplicació com les del propi sistema operatiu/firmware (ja que les noves versions de l'agent podrien requerir actualitzacions del nucli). o components del sistema, biblioteques, etc.).
Després d'una llarga anàlisi del mercat, va resultar que hi ha moltes solucions per oferir actualitzacions al dispositiu.
Des d'utilitats relativament senzilles, principalment orientades a l'actualització/arrencada dual com swupd/SWUpdate/OSTree fins a plataformes completes com Mender i Balena.
En primer lloc, vam decidir que ens interessaven solucions d'extrem a extrem, de manera que l'elecció va caure immediatament en plataformes.
Ell mateix va ser exclòs pel fet que en realitat utilitza el mateix Docker dins del seu balenaEngine.
Però observo que malgrat això, vam acabar utilitzant constantment el seu producte per al firmware flash a les targetes SD: una utilitat senzilla i extremadament convenient per a això.
Per tant, al final l'elecció va caure . Mender és una plataforma completa per muntar, lliurar i instal·lar firmware.
En general, la plataforma té un aspecte fantàstic, però vam trigar aproximadament una setmana i mitja a crear la versió correcta del nostre microprogramari mitjançant el creador de reparadors.
I com més ens submergíem en les complexitats del seu ús, més era evident que per desplegar-lo completament necessitaríem molt més temps del que teníem.
Per desgràcia, els nostres terminis ajustats van fer que ens vam veure obligats a abandonar l'ús de Mender i triar-ne un de més senzill.
Ansible
La solució més senzilla en la nostra situació era utilitzar Ansible. Un parell de llibres de joc van ser suficients per començar.
La seva essència era que simplement ens vam connectar des de l'amfitrió (servidor CI) mitjançant ssh als nostres gerds i els vam distribuir actualitzacions.
Al principi, tot era senzill: calia estar a la mateixa xarxa amb els dispositius, l'abocament es feia mitjançant Wi-Fi.
A l'oficina només hi havia una dotzena de gerds de prova connectats a la mateixa xarxa, cada dispositiu tenia una adreça IP estàtica també especificada a Ansible Inventory.
Va ser Ansible qui va lliurar el nostre agent de supervisió als dispositius finals
3G / LTE
Malauradament, aquest cas d'ús d'Ansible només podia funcionar en mode de desenvolupament abans que tinguéssim patinets reals.
Perquè els patinets, com enteneu, no estan connectats a un encaminador Wi-Fi, esperant constantment actualitzacions a la xarxa.
En realitat, els patinets no poden tenir cap connexió que no sigui 3G/LTE mòbil (i fins i tot no tot el temps).
Això imposa immediatament molts problemes i limitacions, com ara la baixa velocitat de connexió i la comunicació inestable.
Però el més important és que en una xarxa 3G/LTE no podem confiar simplement en una IP estàtica assignada a la xarxa.
Això ho solucionen parcialment alguns proveïdors de targetes SIM; fins i tot hi ha targetes SIM especials dissenyades per a dispositius IoT amb adreces IP estàtiques. Però no teníem accés a aquestes targetes SIM i no podíem utilitzar adreces IP.
Per descomptat, hi havia idees per fer algun tipus de registre d'adreces IP, també conegut com descobriment de serveis en algun lloc com Consul, però vam haver d'abandonar aquestes idees, ja que en les nostres proves l'adreça IP podia canviar massa sovint, cosa que va provocar una gran inestabilitat.
Per aquest motiu, l'ús més convenient per lliurar mètriques no seria utilitzar el model d'extracció, on aniríem als dispositius per obtenir les mètriques necessàries, sinó push, lliurant mètriques des del dispositiu directament al servidor.
VPN
Com a solució a aquest problema, vam triar VPN, concretament .
Els clients (scooters) a l'inici del sistema es van connectar al servidor VPN i es van poder connectar a ells. Aquest túnel es va utilitzar per oferir actualitzacions.
En teoria, es podria utilitzar el mateix túnel per a la supervisió, però aquesta connexió era més complicada i menys fiable que una simple empenta.
Recursos al núvol
Finalment, cal fer un seguiment dels nostres serveis i bases de dades al núvol, ja que per a ells utilitzem Kubernetes, idealment perquè desplegar el monitoratge al clúster sigui el més senzill possible. Idealment, utilitzant , ja que per al desplegament, l'utilitzem en la majoria dels casos. I, per descomptat, per controlar el núvol cal utilitzar les mateixes solucions que per als propis patinets.
Donat
Uf, sembla que hem resolt la descripció, al final fem una llista del que necessitàvem:
- Una solució ràpida, ja que el seguiment és necessari ja durant el procés de desenvolupament
- Volum/quantitat: es necessiten moltes mètriques
- La recollida de registres és necessària
- Fiabilitat: les dades són fonamentals per a l'èxit del llançament
- No podeu utilitzar el model d'estirament: necessiteu empenta
- Necessitem un seguiment unificat no només del maquinari, sinó també del núvol
La imatge final semblava així
Selecció de pila
Així doncs, ens vam enfrontar a la qüestió de triar una pila de seguiment.
En primer lloc, estàvem buscant la solució tot en un més completa que cobrissin simultàniament tots els nostres requisits, però que alhora fos prou flexible per adaptar-ne l'ús a les nostres necessitats. Tot i així, teníem moltes restriccions imposades per maquinari, arquitectura i terminis.
Hi ha una gran varietat de solucions de monitorització, començant per sistemes complets com , o i acabant amb solucions ja fetes per a la gestió de flotes.
Inicialment, aquesta darrera ens semblava una solució ideal, però alguns no tenien un seguiment complet, d'altres tenien capacitats molt limitades de les versions gratuïtes i d'altres simplement no cobrien els nostres "desitjos" o no eren prou flexibles per adaptar-se als nostres escenaris. Alguns simplement estan obsolets.
Després d'analitzar una sèrie de solucions similars, ràpidament vam arribar a la conclusió que seria més fàcil i ràpid muntar una pila similar nosaltres mateixos. Sí, serà una mica més complicat que desplegar una plataforma de gestió de flotes completament preparada, però no haurem de fer compromisos.
Gairebé segurament, en tota l'enorme abundància de solucions, ja n'hi ha una de feta que ens convindria completament, però en el nostre cas va ser molt més ràpid muntar una determinada pila pel nostre compte i personalitzar-la "per a nosaltres mateixos" en lloc de provant productes ja fets.
Amb tot això, no ens vam esforçar per muntar nosaltres mateixos una plataforma de monitoratge sencera, sinó que buscàvem les piles "a punt" més funcionals, només amb la possibilitat de configurar-les de manera flexible.
(B)ELK?
La primera solució que es va considerar realment va ser la coneguda pila ELK.
De fet, s'hauria de dir BELK, perquè tot comença amb Beats -
Per descomptat, ELK és una de les solucions més famoses i potents en l'àmbit del monitoratge, i encara més en la recollida i processament de registres.
Teníem la intenció que ELK s'utilitzi per recollir registres i emmagatzemar a llarg termini les mètriques obtingudes de Prometheus.
Per a la visualització podeu utilitzar Grafan.
De fet, la nova pila ELK pot recollir mètriques de manera independent (metricbeat) i Kibana també pot mostrar-les.
Tot i així, ELK va sorgir inicialment dels registres i fins ara la funcionalitat de les mètriques té diversos inconvenients greus:
- Significativament més lent que Prometeu
- S'integra en molts menys llocs que Prometeu
- És difícil configurar alertes per a ells
- Les mètriques ocupen molt d'espai
- Configurar taulers amb mètriques a Kiban és molt més complicat que a Grafan
En general, les mètriques a ELK són pesades i encara no són tan convenients com en altres solucions, de les quals ara hi ha molt més que Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Per descomptat, m'agradaria molt tenir una solució tot en un de seguida, però en el cas de metricbeat hi havia massa compromisos.
I la pila ELK en si té una sèrie de moments difícils:
- És pesat, de vegades fins i tot molt pesat si recopileu una quantitat força gran de dades
- Heu de "saber cuinar-lo", cal escalar-lo, però això no és trivial.
- Versió gratuïta reduïda: la versió gratuïta no té una alerta normal i en el moment de la selecció no hi havia autenticació
He de dir que recentment l'últim punt ha millorat i a més (inclosa l'autenticació) el model de preus en si va començar a canviar.
Però en el moment en què anàvem a desplegar aquesta solució, no hi havia cap alerta.
Potser podríem haver intentat crear alguna cosa amb ElastAlert o altres solucions de la comunitat, però tot i així vam decidir considerar altres alternatives.
Loki - Grafana - Prometeu
De moment, una bona solució podria ser construir una pila de monitorització basada exclusivament en Prometheus com a proveïdor de mètriques, Loki per als registres, i per a la visualització podeu utilitzar el mateix Grafana.
Malauradament, en el moment de l'inici del pilot de vendes del projecte (setembre-octubre de 19), Loki encara es trobava en la versió beta 0.3-0.4, i en el moment de l'inici del desenvolupament no es podia considerar com una solució de producció. en absolut.
Encara no tinc experiència en utilitzar Loki en projectes seriosos, però puc dir que Promtail (un agent per a la recollida de registres) funciona molt bé tant per a bare-metal com per a beines a kubernetes.
TIC
Potser l'alternativa amb totes les funcions més digne (l'única?) a la pila ELK ara només es pot anomenar pila TICK: Telegraf, InfluxDB, Chronograf, Kapacitor.
Descriuré tots els components a continuació amb més detall, però la idea general és la següent:
- Telegraf - agent per a la recollida de mètriques
- InfluxDB - base de dades de mètriques
- Kapacitor: processador de mètriques en temps real per alertar
- Chronograf - panell web per a la visualització
Per a InfluxDB, Kapacitor i Chronograf hi ha gràfics oficials de timó que hem utilitzat per desplegar-los.
Cal tenir en compte que a l'última versió d'Influx 2.0 (beta), Kapacitor i Chronograf van passar a formar part d'InfluxDB i ja no existeixen per separat.
Telègraf
és un agent molt lleuger per recopilar mètriques en una màquina d'estat.
Pot controlar una gran quantitat de tot, des de до
servidor .
Té una sèrie d'avantatges interessants:
- Ràpid i lleuger (escrit a Go)
- Menja una quantitat mínima de recursos
- Push mètriques de manera predeterminada
- Recull totes les mètriques necessàries
- Mètriques del sistema sense cap configuració
- Mètriques de maquinari, com ara informació dels sensors
- És molt fàcil afegir les vostres pròpies mètriques
- Molts connectors fora de la caixa
- Recull registres
Com que les mètriques push eren necessàries per a nosaltres, tots els altres avantatges eren més que addicions agradables.
La recollida de registres per part del propi agent també és molt convenient, ja que no cal connectar utilitats addicionals per registrar registres.
Influx ofereix l'experiència més convenient per treballar amb registres si ho feu servir .
Telegraf és generalment un gran agent per recopilar mètriques, fins i tot si no feu servir la resta de la pila ICK.
Moltes persones el creuen amb ELK i altres bases de dades de sèries temporals per comoditat, ja que pot escriure mètriques gairebé a qualsevol lloc.
InfluxDB
InfluxDB és el nucli principal de la pila TICK, és a dir, una base de dades de sèries temporals per a mètriques.
A més de les mètriques, Influx també pot emmagatzemar registres, tot i que, en essència, els registres són només les mateixes mètriques, només que en lloc dels indicadors numèrics habituals, la funció principal es realitza mitjançant una línia de text de registre.
InfluxDB també està escrit a Go i sembla que funciona molt més ràpid en comparació amb ELK al nostre clúster (no el més potent).
Un dels avantatges interessants d'Influx també inclouria una API molt còmoda i rica per a consultes de dades, que vam utilitzar de manera molt activa.
Desavantatges - $$$ o escalar?
La pila TICK només té un inconvenient que vam descobrir: això estimat. Encara més.
Què té la versió de pagament que la versió gratuïta no?
Pel que hem pogut entendre, l'única diferència entre la versió de pagament de la pila TICK i la gratuïta són les capacitats d'escalat.
És a dir, només podeu crear un clúster amb Alta disponibilitat a .
Si voleu un HA complet, heu de pagar o utilitzar unes crosses. Hi ha un parell de solucions comunitàries, per exemple sembla una solució competent, però està escrit que no és apta per a la producció, així com
- una solució senzilla amb bombeig de dades a través de NATS (també s'haurà d'escalar, però això es pot resoldre).
És una llàstima, però tots dos semblen abandonats: no hi ha noves commits, suposo que el problema és el llançament aviat esperat de la nova versió d'Influx 2.0, en què moltes coses seran diferents (no hi ha informació sobre escalant-hi encara).
Oficialment hi ha una versió gratuïta - de fet, aquest és un HA primitiu, però només mitjançant l'equilibri,
ja que totes les dades s'escriuran a totes les instàncies d'InfluxDB darrere de l'equilibrador de càrrega.
En té alguns com els possibles problemes amb la sobreescriptura de punts i la necessitat de crear bases per a mètriques amb antelació
(cosa que passa automàticament durant el treball normal amb InfluxDB).
A més , això significa una sobrecàrrega addicional per a mètriques duplicades (tant de processament com d'emmagatzematge) que potser no necessiteu, però no hi ha manera de separar-les.
Victoria Metrics?
Com a resultat, malgrat que estàvem completament satisfets amb la pila TICK en tot allò que no sigui l'escala de pagament, vam decidir veure si hi havia alguna solució gratuïta que pogués substituir la base de dades InfluxDB, deixant els components T_CK restants.
Hi ha moltes bases de dades de sèries temporals, però la més prometedora és Victoria Metrics, té una sèrie d'avantatges:
- Ràpid i fàcil, almenys segons els resultats
- Hi ha una versió de clúster, sobre la qual fins i tot hi ha bones crítiques ara
- Ella pot esquinçar
- Admet el protocol InfluxDB
No teníem la intenció de construir una pila completament personalitzada basada en Victoria i l'esperança principal era que podríem utilitzar-la com a reemplaçament d'InfluxDB.
Malauradament, això no és possible, malgrat que el protocol InfluxDB és compatible, només funciona per enregistrar mètriques: només l'API de Prometheus està disponible "fora", el que significa que no serà possible configurar-hi Chronograf.
A més, només s'admeten valors numèrics per a mètriques (hem utilitzat valors de cadena per a mètriques personalitzades; més informació a la secció ).
Òbviament, pel mateix motiu, la màquina virtual no pot emmagatzemar registres com ho fa Influx.
A més, cal tenir en compte que en el moment de cercar la solució òptima, Victoria Metrics encara no era tan popular, la documentació era molt més petita i la funcionalitat era més feble.
(No recordo una descripció detallada de la versió del clúster i la fragmentació).
Selecció base
Com a resultat, es va decidir que per al pilot encara ens limitaríem a un sol node InfluxDB.
Hi havia diversos motius principals per a aquesta elecció:
- Ens va agradar molt tota la funcionalitat de la pila TICK
- Ja hem aconseguit desplegar-lo i ha funcionat molt bé
- Els terminis s'acabaven i no quedava gaire temps per provar altres opcions.
- No ens esperàvem una càrrega tan pesada
No teníem molts patinets per a la primera fase del pilot, i les proves durant el desenvolupament no van revelar cap problema de rendiment.
Per tant, vam decidir que per a aquest projecte un node Influx seria suficient per a nosaltres sense necessitat d'escalar (vegeu les conclusions al final).
Hem decidit la pila i la base, ara sobre els components restants de la pila TICK.
Kapacitor
Kapacitor forma part de la pila TICK, un servei que pot controlar les mètriques que entren a la base de dades en temps real i realitzar diverses accions basades en regles.
En general, es posiciona com una eina per al seguiment d'anomalies potencials i l'aprenentatge automàtic (no estic segur que aquestes funcions siguin demanades), però el cas més popular del seu ús és més habitual: l'alerta.
Així és com l'hem utilitzat per a les notificacions. Vam configurar alertes de Slack quan un patinet concret es desconnectava, i el mateix es va fer amb els carregadors intel·ligents i els components importants de la infraestructura.
Això va permetre respondre ràpidament als problemes, així com rebre notificacions que tot tornava a la normalitat.
Un exemple senzill: una bateria addicional per alimentar la nostra "caixa" s'ha avariat o per algun motiu s'ha quedat sense energia; simplement instal·lant-ne una de nova, al cap d'un temps hauríem de rebre una notificació que la funcionalitat del patinet s'ha restablert.
A Influx 2.0, Kapacitor va passar a formar part de DB
Cronograf
He vist moltes solucions d'IU diferents per a la supervisió, però puc dir que en termes de funcionalitat i UX, res es compara amb Chronograf.
Vam començar a utilitzar la pila TICK, curiosament, amb Grafan com a interfície web.
No descriuré la seva funcionalitat; tothom coneix les seves àmplies possibilitats per configurar qualsevol cosa.
Tanmateix, Grafana segueix sent un instrument completament universal, mentre que Chronograf està dissenyat principalment per utilitzar-lo amb Influx.
I, per descomptat, gràcies a això, Chronograf es pot permetre una funcionalitat molt més intel·ligent o convenient.
Potser la principal comoditat de treballar amb Chronograf és que podeu veure l'interior del vostre InfluxDB mitjançant Explore.
Sembla que Grafana té una funcionalitat gairebé idèntica, però en realitat, la configuració d'un tauler a Chronograf es pot fer amb uns quants clics del ratolí (al mateix temps mirant la visualització que hi ha), mentre que a Grafana encara tindreu tard o d'hora. per editar la configuració JSON (per descomptat, Chronograf permet pujar els vostres dashas configurats a mà i editar-los com a JSON si cal, però mai no els he hagut de tocar després de crear-los a la interfície d'usuari).
Kibana té capacitats molt més riques per crear taulers i controls per a ells, però la UX per a aquestes operacions és molt complexa.
Es necessitarà una bona comprensió per crear un tauler de control convenient. I encara que la funcionalitat dels taulers de control de Chronograf és menor, fer-los i personalitzar-los és molt més senzill.
Els quadres de comandament en si, a part de l'estil visual agradable, en realitat no són diferents dels quadres de comandament de Grafana o Kibana:
Aquest és el aspecte de la finestra de consulta:
És important tenir en compte, entre altres coses, que coneixent els tipus de camps de la base de dades InfluxDB, el propi cronògraf de vegades us pot ajudar automàticament a escriure una consulta o a triar la funció d'agregació correcta com la mitjana.
I, per descomptat, Chronograf és el més convenient possible per veure els registres. Es veu així:
De manera predeterminada, els registres d'Influx estan dissenyats per utilitzar syslog i, per tant, tenen un paràmetre important: la gravetat.
El gràfic de la part superior és especialment útil; en ell es poden veure els errors que es produeixen i el color immediatament mostra clarament si la gravetat és més alta.
Un parell de vegades vam detectar errors importants d'aquesta manera, anant a veure els registres de l'última setmana i veure una punta vermella.
Per descomptat, l'ideal seria configurar alertes per aquest tipus d'errors, ja que ja teníem tot per a això.
Fins i tot ho vam activar durant un temps, però en el procés de preparar el pilot va resultar que teníem molts errors (inclosos els de sistema com la indisponibilitat de la xarxa LTE), que també van "enviar correu brossa" al canal Slack. molt, sense causar cap problema, gran benefici.
La solució correcta seria gestionar la majoria d'aquests tipus d'errors, ajustar-ne la gravetat i només aleshores habilitar l'alerta.
D'aquesta manera, només es publicaran a Slack els errors nous o importants. Simplement no hi havia prou temps per a una configuració d'aquest tipus donats els terminis ajustats.
Autenticació
També val la pena esmentar que Chronograf admet OAuth i OIDC com a autenticació.
Això és molt convenient, ja que us permet connectar-lo fàcilment al vostre servidor i crear un SSO complet.
En el nostre cas, el servidor era — es va utilitzar per connectar-se a la supervisió, però també es va utilitzar el mateix servidor per autenticar patinets i sol·licituds al back-end.
"Administrador"
L'últim component que descriuré és el nostre "tauler d'administració" escrit a Vue.
Bàsicament, és només un servei autònom que mostra informació de scooter de les nostres pròpies bases de dades, microserveis i dades de mètriques d'InfluxDB simultàniament.
A més, s'hi van traslladar moltes funcions administratives, com ara un reinici d'emergència o l'obertura remota d'un pany per a l'equip de suport.
També hi havia mapes. Ja he comentat que vam començar amb Grafana en comptes de Chronograf, perquè els mapes de Grafana estan disponibles en forma de connectors, on podríem veure les coordenades dels patinets. Malauradament, les capacitats dels ginys de mapes per a Grafana són molt limitades i, com a resultat, va ser molt més fàcil escriure la vostra pròpia aplicació web amb mapes en pocs dies, per no només veure les coordenades en aquest moment, sinó també mostrar-les. el recorregut fet pel patinet, poder filtrar les dades al mapa, etc. (tota aquesta funcionalitat que no podríem configurar en un simple tauler).
Un dels avantatges ja esmentats d'Influx és la possibilitat de crear fàcilment les vostres pròpies mètriques.
Això permet que s'utilitzi per a una gran varietat d'escenaris.
Vam intentar registrar tota la informació útil allà: càrrega de la bateria, estat del bloqueig, rendiment del sensor, bluetooth, GPS i molts altres controls de salut.
Tot això ho vam mostrar al tauler d'administració.
Per descomptat, el criteri més important per a nosaltres va ser l'estat de funcionament del patinet; de fet, Influx ho comprova i ho mostra amb "llums verdes" a la secció Nodes.
Això ho fa la funció — l'hem utilitzat per entendre el rendiment de la nostra caixa i enviar aquestes mateixes alertes a Slack.
Per cert, vam anomenar els scooters amb els noms dels personatges dels Simpson; era molt convenient distingir-los els uns dels altres.
I en general va ser més divertit d'aquesta manera. Contínuament s'escoltaven frases com "Guys, Smithers is dead!".
Mètriques de cadena
És important que InfluxDB us permeti emmagatzemar no només valors numèrics, com és el cas de Victoria Metrics.
Sembla que això no és tan important; després de tot, a part dels registres, qualsevol mètrica es pot emmagatzemar en forma de números (només cal afegir mapeig per als estats coneguts, una mena d'enum)?
En el nostre cas, hi havia almenys un escenari on les mètriques de cadena eren molt útils.
Va passar que el proveïdor dels nostres "carregadors intel·ligents" era un tercer, no teníem control sobre el procés de desenvolupament i la informació que podien subministrar aquests carregadors.
Com a resultat, l'API de càrrega estava lluny de ser ideal, però el principal problema era que no sempre podíem entendre el seu estat.
Aquí és on Influx va venir al rescat. Simplement vam escriure l'estat de la cadena que ens va arribar al camp de la base de dades InfluxDB sense canvis.
Durant un temps, només hi van arribar valors com "en línia" i "fora de línia", en funció de la informació que es mostrava al nostre tauler d'administració i s'enviaven notificacions a Slack. Tanmateix, en algun moment, també van començar a aparèixer allà valors com "desconnectat".
Com va resultar més tard, aquest estat es va enviar una vegada després d'una pèrdua de connexió, si el carregador no podia establir una connexió amb el servidor després d'un cert nombre d'intents.
Per tant, si només utilitzem un conjunt fix de valors, és possible que no veiem aquests canvis al microprogramari en el moment adequat.
I en general, les mètriques de cadena ofereixen moltes més possibilitats d'ús; podeu registrar pràcticament qualsevol informació en elles. Encara que, per descomptat, també cal utilitzar aquesta eina amb cura.
A més de les mètriques habituals, també vam registrar la informació d'ubicació GPS a InfluxDB. Això va ser increïblement útil per controlar la ubicació dels patinets al nostre tauler d'administració.
De fet, sempre sabíem on i quin patinet era en el moment que necessitàvem.
Això ens va ser molt útil quan buscàvem un patinet (veure conclusions al final).
Seguiment d'infraestructures
A més dels patinets en si, també havíem de controlar tota la nostra infraestructura (bastant extensa).
Una arquitectura molt general semblava a això:
Si destaquem una pila de monitorització pura, es veurà així:
El que ens agradaria comprovar al núvol és:
- Bases de dades
- mantell de claus
- Microserveis
Com que tots els nostres serveis al núvol es troben a Kubernetes, seria bo recollir informació sobre el seu estat.
Afortunadament, Telegraf fora de la caixa pot recollir un gran nombre de mètriques sobre l'estat del clúster Kubernetes i Chronograf ofereix immediatament bells taulers de control per a això.
Vam controlar principalment el rendiment dels pods i el consum de memòria. En cas de caiguda, alertes a Slack.
Hi ha dues maneres de fer el seguiment dels pods a Kubernetes: DaemonSet i Sidecar.
Tots dos mètodes es descriuen en detall .
Hem utilitzat Telegraf Sidecar i, a més de mètriques, hem recollit els registres de pods.
En el nostre cas, vam haver de jugar amb els troncs. Tot i que Telegraf pot extreure registres de l'API de Docker, volíem tenir una col·lecció uniforme de registres amb els nostres dispositius finals i el syslog configurat per als contenidors per a això. Potser aquesta solució no era bonica, però no hi va haver queixes sobre el seu treball i els registres es mostraven bé a Chronograf.
Monitorització de seguiment???
Al final, va sorgir la vella qüestió del seguiment dels sistemes de monitorització, però, afortunadament, o per desgràcia, simplement no teníem temps suficient per a això.
Tot i que Telegraf pot enviar fàcilment les seves pròpies mètriques o recopilar mètriques de la base de dades InfluxDB per enviar-les al mateix Influx o a un altre lloc.
Troballes
Quines conclusions hem extret dels resultats del pilot?
Com es pot fer un seguiment?
En primer lloc, la pila TICK va complir completament les nostres expectatives i ens va oferir encara més oportunitats de les que esperàvem inicialment.
Tota la funcionalitat que necessitàvem estava present. Tot el que vam fer amb ell va funcionar sense problemes.
Productivitat
El principal problema de la pila TICK a la versió gratuïta és la manca de capacitats d'escalat. Això no va ser un problema per a nosaltres.
No vam recopilar dades/xifres de càrrega exactes, però vam recopilar dades d'uns 30 patinets alhora.
Cadascun d'ells va recollir més de tres dotzenes de mètriques. Al mateix temps, es van recollir registres dels dispositius. La recollida i l'enviament de dades es van produir cada 10 segons.
És important tenir en compte que després d'una setmana i mitja del pilot, quan es van corregir el gruix dels "problemes de la infància" i ja s'havien resolt els problemes més importants, vam haver de reduir la freqüència d'enviament de dades al servidor per 30 segons. Això es va fer necessari perquè el trànsit de les nostres targetes SIM LTE va començar a desaparèixer ràpidament.
La major part del trànsit el van consumir els registres; les mètriques en si, fins i tot amb un interval de 10 segons, pràcticament no el van malgastar.
Com a resultat, després d'un temps vam desactivar completament la recollida de registres als dispositius, ja que els problemes específics ja eren evidents fins i tot sense la recollida constant.
En alguns casos, si encara era necessari veure els registres, simplement ens vam connectar mitjançant WireGuard mitjançant VPN.
També afegiré que cada entorn separat estava separat l'un de l'altre i la càrrega descrita anteriorment només era rellevant per a l'entorn de producció.
A l'entorn de desenvolupament, vam plantejar una instància independent d'InfluxDB que va continuar recopilant dades cada 10 segons i no vam tenir cap problema de rendiment.
TICK - ideal per a projectes petits i mitjans
A partir d'aquesta informació, conclouria que la pila TICK és ideal per a projectes relativament petits o projectes que definitivament no esperen cap càrrega alta.
Si no teniu milers de pods o centenars de màquines, fins i tot una instància d'InfluxDB gestionarà bé la càrrega.
En alguns casos, és possible que estigueu satisfet amb Influx Relay com a solució primitiva d'alta disponibilitat.
I, per descomptat, ningú no us impedeix configurar l'escala "vertical" i simplement assignar diferents servidors per a diferents tipus de mètriques.
Si no esteu segurs de la càrrega esperada dels serveis de monitorització, o teniu la garantia de tenir/tindreu una arquitectura molt "pesada", no recomanaria utilitzar la versió gratuïta de la pila TICK.
Per descomptat, una solució senzilla seria comprar - però aquí no puc comentar d'alguna manera, ja que jo mateix desconec les subtileses. A més del fet que és molt car i definitivament no apte per a petites empreses.
En aquest cas, avui, recomanaria mirar cap a la recollida de mètriques mitjançant Victoria Metrics i registres amb Loki.
És cert que tornaré a fer una reserva que els Loki/Grafana són molt menys convenients (per la seva major versatilitat) que els TICK ja fets, però són gratuïts.
És important: tota la informació aquí descrita és rellevant per a la versió Influx 1.8, en aquests moments Influx 2.0 està a punt de ser llançat.
Tot i que no he tingut l'oportunitat de provar-ho en condicions de combat i és difícil treure conclusions sobre les millores, definitivament la interfície ha millorat encara, l'arquitectura s'ha simplificat (sense kapacitor i cronògraf),
van aparèixer plantilles ("funció assassina" - ). Però, malauradament, de moment, la versió 2 no té la clau per a la qual vam triar la primera versió: no hi ha cap col·lecció de registres.
Aquesta funcionalitat també apareixerà a Influx 2.0, però no hem trobat cap termini, ni tan sols aproximat.
Com no fer plataformes IoT (ara)
Al final, després d'haver llançat el pilot, nosaltres mateixos vam muntar la nostra pròpia pila d'IoT completa, a falta d'una alternativa adequada als nostres estàndards.
No obstant això, recentment està disponible en versió Beta — És una llàstima que no hi fos quan vam començar a fer el projecte.
Estem completament satisfets amb el resultat final i la plataforma basada en Ansible + TICK + WireGuard que vam muntar nosaltres mateixos. Però avui us recomanaria fer una ullada més de prop a Balena abans d'intentar crear la vostra pròpia plataforma IoT.
Perquè, en última instància, pot fer la major part del que vam fer, i OpenBalena és gratuït i de codi obert.
Ja sap no només enviar actualitzacions, sinó que també hi ha una VPN integrada i adaptada per utilitzar-la en un entorn IoT.
I fa poc, fins i tot van llançar el seu , que es connecta fàcilment al seu ecosistema.
Ei, què passa amb el patinet que falta?
Així que el patinet, "Ralph", va desaparèixer sense deixar rastre.
Immediatament vam córrer a mirar el mapa al nostre "tauler d'administració", amb dades de mètriques GPS d'InfluxDB.
Gràcies a les dades de seguiment, vam determinar fàcilment que el patinet va sortir de l'aparcament al voltant de les 21:00 del dia passat, va conduir aproximadament mitja hora cap a alguna zona i va estar aparcat fins a les 5 del matí al costat d'alguna casa alemanya.
Després de les 5 a.m., no es van rebre dades de supervisió, això significava que la bateria addicional estava completament descarregada o que l'atacant finalment va descobrir com treure el maquinari intel·ligent del scooter.
Malgrat això, la policia encara va ser trucada a l'adreça on es trobava el patinet. El patinet no hi era.
Tanmateix, el propietari de la casa també es va sorprendre per això, ja que ahir a la nit va anar a casa amb aquest patinet des de l'oficina.
Segons va resultar, un dels empleats de suport va arribar a primera hora del matí i va recollir el patinet, en veure que la seva bateria addicional estava completament descarregada i el va portar (a peu) fins a l'aparcament. I la bateria addicional va fallar a causa de la humitat.
Ens vam robar el patinet. Per cert, no sé com i qui després va resoldre el problema amb el cas policial, però el seguiment va funcionar perfectament...
Font: www.habr.com