Een jaar geleden lanceerden we een pilotversie van een promotieproject voor .
Aanvankelijk heette het project Road-To-Barcelona, later werd het Road-To-Berlin (vandaar R2B in de screenshots), en uiteindelijk heette het xRide.
Het hoofdidee van het project was dit: in plaats van een gecentraliseerde auto- of scooterverhuurservice (we hebben het over scooters oftewel elektrische motorfietsen, niet over kickscooters/scooters) wilden we een platform maken voor gedecentraliseerde verhuur. Over de moeilijkheden die we tegenkwamen .
Aanvankelijk concentreerde het project zich op auto's, maar vanwege deadlines, extreem lange communicatie met fabrikanten en een groot aantal veiligheidsbeperkingen werd voor de pilot gekozen voor elektrische scooters.
De gebruiker installeerde een iOS of Android applicatie op de telefoon, benaderde de scooter die hij leuk vond, waarna de telefoon en de scooter een peer-to-peer verbinding tot stand brachten, ETH werd uitgewisseld en de gebruiker de rit kon starten door de scooter aan te zetten via de telefoon. Aan het einde van de reis was het ook mogelijk om de reis te betalen met Ethereum vanuit de portemonnee van de gebruiker aan de telefoon.
Naast scooters zag de gebruiker in de applicatie ‘slimme laders’, waarmee de gebruiker zelf de huidige accu kon vervangen als deze bijna leeg was.
Zo zag onze pilot er in grote lijnen uit, die in september vorig jaar werd gelanceerd in twee Duitse steden: Bonn en Berlijn.
En toen, op een dag, in Bonn, vroeg in de ochtend, werd ons ondersteuningsteam (ter plaatse om de scooters in goede staat te houden) gewaarschuwd: een van de scooters was spoorloos verdwenen.
Hoe kan ik het vinden en retourneren?
In dit artikel zal ik hierover praten, maar eerst over hoe we ons eigen IoT-platform hebben gebouwd en hoe we dit hebben gemonitord.
Wat en waarom monitoren: scooters, infrastructuur, laadpalen?
Wat wilden we in ons project monitoren?
Allereerst zijn dit de scooters zelf - elektrische scooters zelf zijn vrij duur, je kunt een dergelijk project niet lanceren zonder voldoende voorbereid te zijn; indien mogelijk wil je zoveel mogelijk informatie verzamelen over de scooters: over hun locatie, laadniveau , enz.
Daarnaast wil ik graag de staat van onze eigen IT-infrastructuur monitoren: databases, services en alles wat ze nodig hebben om te werken. Het was ook nodig om de status van de ‘slimme laders’ te monitoren, voor het geval deze kapot zouden gaan of zonder volle batterijen zouden komen te zitten.
Scooters
Wat waren onze scooters en wat wilden we ervan weten?
Het eerste en belangrijkste zijn GPS-coördinaten, omdat we dankzij hen kunnen begrijpen waar ze zijn en waar ze naartoe bewegen.
Het volgende is het opladen van de batterij, waardoor we kunnen vaststellen dat het opladen van de scooters ten einde loopt en een sapcentrifuge kunnen sturen of op zijn minst de gebruiker kunnen waarschuwen.
Natuurlijk is het ook noodzakelijk om te controleren wat er gebeurt met onze hardwarecomponenten:
- werkt bluetooth?
- werkt de GPS-module zelf?
- We hadden ook een probleem met het feit dat de GPS onjuiste coördinaten kon verzenden en vast kon komen te zitten, en dit kon alleen worden vastgesteld door extra controles op de scooter,
en breng de ondersteuning zo snel mogelijk op de hoogte om het probleem op te lossen
- We hadden ook een probleem met het feit dat de GPS onjuiste coördinaten kon verzenden en vast kon komen te zitten, en dit kon alleen worden vastgesteld door extra controles op de scooter,
En tot slot: controles van de software, beginnend met het besturingssysteem en de processor, netwerk- en schijfbelasting, eindigend met controles van onze eigen modules die specifieker voor ons zijn (, ).
Hardware
Wat was ons ‘ijzeren’ deel?
Rekening houdend met het kortst mogelijke tijdsbestek en de behoefte aan snelle prototyping, kozen we voor de gemakkelijkste optie voor implementatie en selectie van componenten: Raspberry Pi.
Naast de Rpi zelf hadden we een op maat gemaakt bord (dat we zelf hadden ontwikkeld en besteld in China om het assemblageproces van de uiteindelijke oplossing te versnellen) en een set componenten - een relais (om de scooter aan/uit te zetten), een batterijlaadlezer, een modem, antennes. Dit alles werd compact verpakt in een speciale “xRide box”.
Er moet ook worden opgemerkt dat de hele doos werd aangedreven door een extra powerbank, die op zijn beurt werd aangedreven door de hoofdbatterij van de scooter.
Dit maakte het mogelijk om monitoring te gebruiken en de scooter zelfs na het einde van de rit in te schakelen, aangezien de hoofdaccu onmiddellijk werd uitgeschakeld nadat de contactsleutel in de “uit”-stand was gezet.
Dokwerker? Gewoon Linux? en inzet
Laten we terugkeren naar monitoring, dus Raspberry - wat hebben we?
Een van de eerste dingen die we wilden gebruiken om het proces van het implementeren, updaten en leveren van componenten op fysieke apparaten te versnellen, was Docker.
Helaas werd al snel duidelijk dat Docker op RPi, hoewel het werkt, veel overhead met zich meebrengt, vooral op het gebied van energieverbruik.
Het verschil met het “native” besturingssysteem, hoewel niet zo groot, was nog steeds voldoende om op onze hoede te zijn voor de mogelijkheid om te snel de lading te verliezen.
De tweede reden was een van onze partnerbibliotheken op Node.js (sic!) - het enige onderdeel van het systeem dat niet in Go/C/C++ is geschreven.
De auteurs van de bibliotheek hadden geen tijd om een werkende versie in een van de ‘moedertalen’ aan te bieden.
Niet alleen is het knooppunt zelf niet de meest elegante oplossing voor apparaten met lage prestaties, maar de bibliotheek zelf had ook veel middelen nodig.
We realiseerden ons dat, zelfs als we dat zouden willen, het gebruik van Docker een te grote overhead voor ons zou zijn. Er werd gekozen voor het native besturingssysteem en er direct onder werken.
OS
Als gevolg daarvan kozen we opnieuw voor de eenvoudigste optie als besturingssysteem en gebruikten we Raspbian (Debian build voor Pi).
We schrijven al onze software in Go, dus schreven we ook de belangrijkste hardware-agentmodule in ons systeem in Go.
Hij is degene die verantwoordelijk is voor het werken met GPS, Bluetooth, het uitlezen van de lading, het inschakelen van de scooter, enz.
Aanwenden
De vraag rees onmiddellijk over de noodzaak om een mechanisme te implementeren voor het leveren van updates aan apparaten (OTA) - zowel updates voor onze agent/applicatie zelf, als updates voor het besturingssysteem/de firmware zelf (aangezien nieuwe versies van de agent mogelijk updates van de kernel vereisen). of systeemcomponenten, bibliotheken, enz.).
Na een behoorlijk lange analyse van de markt bleek dat er behoorlijk wat oplossingen zijn om updates voor het apparaat te leveren.
Van relatief eenvoudige, veelal update/dual-boot georiënteerde hulpprogramma's zoals swupd/SWUpdate/OSTree tot volwaardige platforms zoals Mender en Balena.
Allereerst besloten we dat we geïnteresseerd waren in end-to-end-oplossingen, dus de keuze viel meteen op platforms.
Zelf werd uitgesloten vanwege het feit dat het feitelijk dezelfde Docker gebruikt in zijn balenaEngine.
Maar ik merk op dat we desondanks hun product voortdurend hebben gebruikt voor flash-firmware op SD-kaarten - een eenvoudig en uiterst handig hulpprogramma hiervoor.
Daarom viel de keuze uiteindelijk op . Mender is een compleet platform voor het assembleren, leveren en installeren van firmware.
Over het algemeen ziet het platform er geweldig uit, maar het kostte ons ongeveer anderhalve week om de juiste versie van onze firmware te bouwen met behulp van de menderbuilder.
En hoe meer we ons verdiepten in de complexiteit van het gebruik ervan, hoe duidelijker het werd dat we, om het volledig in te zetten, veel meer tijd nodig zouden hebben dan we hadden.
Helaas zorgden onze strakke deadlines ervoor dat we gedwongen waren het gebruik van Mender op te geven en een nog eenvoudiger systeem te kiezen.
Ansible
De eenvoudigste oplossing in onze situatie was om Ansible te gebruiken. Een paar draaiboeken waren voldoende om aan de slag te gaan.
Hun essentie was dat we eenvoudigweg vanaf de host (CI-server) via ssh verbinding maakten met onze rasberries en updates naar hen verspreidden.
Helemaal aan het begin was alles eenvoudig: je moest met de apparaten op hetzelfde netwerk zitten, het gieten gebeurde via Wi-Fi.
Op kantoor waren er eenvoudigweg een tiental testframbozen verbonden met hetzelfde netwerk, elk apparaat had een statisch IP-adres dat ook werd gespecificeerd in Ansible Inventory.
Het was Ansible die onze monitoringagent aan de eindapparaten leverde
3G / LTE
Helaas kon deze use case voor Ansible alleen in de ontwikkelingsmodus werken voordat we echte scooters hadden.
Omdat scooters, zoals u begrijpt, niet verbonden zijn met één Wi-Fi-router en voortdurend wachten op updates via het netwerk.
In werkelijkheid kunnen scooters helemaal geen andere verbinding hebben dan mobiele 3G/LTE (en dan nog niet altijd).
Dit brengt meteen veel problemen en beperkingen met zich mee, zoals een lage verbindingssnelheid en onstabiele communicatie.
Maar het belangrijkste is dat we in een 3G/LTE-netwerk niet simpelweg kunnen vertrouwen op een statisch IP-adres dat aan het netwerk is toegewezen.
Dit wordt door sommige simkaartaanbieders gedeeltelijk opgelost; er zijn zelfs speciale simkaarten ontworpen voor IoT-apparaten met statische IP-adressen. Maar we hadden geen toegang tot dergelijke simkaarten en konden geen IP-adressen gebruiken.
Natuurlijk waren er ideeën om een soort registratie van IP-adressen uit te voeren, oftewel service-ontdekking ergens zoals Consul, maar we moesten dergelijke ideeën laten varen, omdat bij onze tests het IP-adres te vaak kon veranderen, wat tot grote instabiliteit leidde.
Om deze reden zou het handigste gebruik voor het leveren van statistieken niet het gebruik van het pull-model zijn, waarbij we naar apparaten zouden gaan voor de benodigde statistieken, maar pushen, waarbij de statistieken rechtstreeks van het apparaat naar de server worden geleverd.
VPN
Als oplossing voor dit probleem hebben we specifiek voor VPN gekozen .
Cliënten (scooters) aan het begin van het systeem maakten verbinding met de VPN-server en konden daar verbinding mee maken. Deze tunnel werd gebruikt om updates te leveren.
In theorie zou dezelfde tunnel gebruikt kunnen worden voor monitoring, maar een dergelijke verbinding was ingewikkelder en minder betrouwbaar dan een simpele push.
Cloudbronnen
Ten slotte is het noodzakelijk om onze clouddiensten en databases te monitoren, omdat we daarvoor Kubernetes gebruiken, idealiter zodat het inzetten van monitoring in het cluster zo eenvoudig mogelijk is. Idealiter gebruiken , omdat we het voor implementatie in de meeste gevallen gebruiken. En om de cloud te monitoren moet je natuurlijk dezelfde oplossingen gebruiken als voor de scooters zelf.
Gegeven
Oef, het lijkt erop dat we de beschrijving hebben uitgezocht, laten we uiteindelijk een lijst maken van wat we nodig hadden:
- Een snelle oplossing, omdat monitoring al tijdens het ontwikkelproces nodig is
- Volume/hoeveelheid – veel statistieken nodig
- Het verzamelen van logboeken is vereist
- Betrouwbaarheid - gegevens zijn van cruciaal belang voor het succes van de lancering
- Je kunt het pull-model niet gebruiken; je hebt push nodig
- We hebben niet alleen uniforme monitoring nodig van hardware, maar ook van de cloud
Het uiteindelijke beeld zag er ongeveer zo uit
Stapelselectie
We werden dus geconfronteerd met de vraag hoe we een monitoringstack moesten kiezen.
Allereerst waren we op zoek naar de meest complete alles-in-één oplossing die tegelijkertijd aan al onze eisen zou voldoen, maar tegelijkertijd flexibel genoeg zou zijn om het gebruik ervan af te stemmen op onze behoeften. Toch kregen we veel beperkingen opgelegd door hardware, architectuur en deadlines.
Er is een grote verscheidenheid aan monitoringoplossingen, te beginnen met volwaardige systemen zoals , of en eindigend met kant-en-klare oplossingen voor wagenparkbeheer.
Aanvankelijk leek dit laatste een ideale oplossing voor ons, maar sommige hadden geen volledige monitoring, andere hadden zeer beperkte mogelijkheden van de gratis versies, en weer andere voldeden simpelweg niet aan onze “wensen” of waren niet flexibel genoeg om in onze scenario’s te passen. Sommige zijn gewoon achterhaald.
Na analyse van een aantal vergelijkbare oplossingen kwamen we al snel tot de conclusie dat het makkelijker en sneller zou zijn om zelf een soortgelijke stapel samen te stellen. Ja, het zal iets ingewikkelder zijn dan het inzetten van een volledig kant-en-klaar fleetmanagementplatform, maar we hoeven geen compromissen te sluiten.
Vrijwel zeker is er, ondanks de enorme overvloed aan oplossingen, al een kant-en-klaar oplossing die helemaal bij ons zou passen, maar in ons geval was het veel sneller om zelf een bepaalde stapel samen te stellen en deze ‘voor onszelf’ aan te passen in plaats van kant-en-klare producten testen.
Bij dit alles streefden we er niet naar om zelf een heel monitoringplatform in elkaar te zetten, maar zochten we naar de meest functionele ‘kant-en-klare’ stacks, alleen met de mogelijkheid om deze flexibel te configureren.
(B) ELK?
De eerste oplossing die daadwerkelijk werd overwogen was de bekende ELK-stack.
Eigenlijk zou het BELK moeten heten, want het begint allemaal met Beats -
ELK is natuurlijk een van de bekendste en krachtigste oplossingen op het gebied van monitoring, en nog meer op het gebied van het verzamelen en verwerken van logs.
Het was onze bedoeling dat ELK zou worden gebruikt voor het verzamelen van logboeken en voor de langetermijnopslag van statistieken verkregen van Prometheus.
Voor visualisatie kunt u Grafan gebruiken.
In feite kan de nieuwe ELK-stack zelfstandig statistieken verzamelen (metricbeat), en Kibana kan deze ook weergeven.
Maar toch is ELK aanvankelijk uit logs gegroeid en tot nu toe heeft de functionaliteit van de statistieken een aantal ernstige nadelen:
- Aanzienlijk langzamer dan Prometheus
- Integreert op veel minder plaatsen dan Prometheus
- Het is moeilijk om waarschuwingen voor hen in te stellen
- Metrieken nemen veel ruimte in beslag
- Het opzetten van dashboards met statistieken is in Kiban veel ingewikkelder dan in Grafan
Over het algemeen zijn de statistieken in ELK zwaar en nog niet zo handig als in andere oplossingen, waarvan er nu veel meer zijn dan alleen Prometheus: TSDB, Victoria Metrics, Cortex, enz., enz. Natuurlijk zou ik heel graag meteen een volwaardige alles-in-één oplossing willen hebben, maar in het geval van metricbeat waren er te veel compromissen.
En de ELK-stack zelf kent een aantal moeilijke momenten:
- Het is zwaar, soms zelfs heel zwaar als je vrij veel data verzamelt
- Je moet het "weten hoe je het moet koken" - je moet het opschalen, maar dit is niet triviaal om te doen
- Uitgeklede gratis versie - de gratis versie heeft geen normale waarschuwingen en op het moment van selectie was er geen authenticatie
Ik moet zeggen dat het laatste punt de laatste tijd beter en bovendien is geworden (inclusief authenticatie) begon het prijsmodel zelf te veranderen.
Maar op het moment dat wij deze oplossing gingen inzetten, was er helemaal geen sprake van alarmering.
Misschien hadden we kunnen proberen iets te bouwen met ElastAlert of andere gemeenschapsoplossingen, maar we hebben toch besloten andere alternatieven te overwegen.
Loki-Grafana-Prometheus
Op dit moment zou een goede oplossing kunnen zijn om een monitoringstack te bouwen, puur gebaseerd op Prometheus als metrics-provider, Loki voor logs, en voor visualisatie kun je dezelfde Grafana gebruiken.
Helaas bevond Loki zich ten tijde van de start van de verkooppilot van het project (september-oktober 19) nog in bètaversie 0.3-0.4, en ten tijde van de start van de ontwikkeling kon het niet als een productieoplossing worden beschouwd helemaal niet.
Ik heb nog geen ervaring met het daadwerkelijk gebruiken van Loki in serieuze projecten, maar ik kan wel zeggen dat Promtail (een agent voor het verzamelen van boomstammen) uitstekend werkt voor zowel bare-metal als kubernetes-pods.
TIK
Misschien wel het meest waardige (het enige?) volwaardige alternatief voor de ELK-stack kan nu alleen de TICK-stack worden genoemd: Telegraf, InfluxDB, Chronograf, Kapacitor.
Ik zal alle onderstaande componenten in meer detail beschrijven, maar het algemene idee is dit:
- Telegraf - agent voor het verzamelen van statistieken
- InfluxDB - metrische database
- Kapacitor - realtime metrische processor voor waarschuwingen
- Chronograf - webpaneel voor visualisatie
Voor InfluxDB, Kapacitor en Chronograf zijn er officiële roerkaarten die we hebben gebruikt om ze in te zetten.
Opgemerkt moet worden dat Kapacitor en Chronograf in de nieuwste versie van Influx 2.0 (bèta) onderdeel zijn geworden van InfluxDB en niet langer afzonderlijk bestaan
Telegraaf
is een zeer lichtgewicht agent voor het verzamelen van statistieken op een statusmachine.
Hij kan een enorme hoeveelheid van alles in de gaten houden naar
server .
Het heeft een aantal leuke voordelen:
- Snel en lichtgewicht (geschreven in Go)
- Eet een minimale hoeveelheid grondstoffen
- Standaard pushstatistieken
- Verzamelt alle benodigde statistieken
- Systeemstatistieken zonder enige instellingen
- Hardwarestatistieken zoals informatie van sensoren
- Het is heel eenvoudig om uw eigen statistieken toe te voegen
- Veel plug-ins uit de doos
- Verzamelt logboeken
Omdat push metrics voor ons noodzakelijk waren, waren alle andere voordelen meer dan prettige toevoegingen.
Het verzamelen van logbestanden door de agent zelf is ook erg handig, omdat het niet nodig is om extra hulpprogramma's aan te sluiten voor het loggen van logbestanden.
Influx biedt de handigste ervaring voor het werken met logbestanden als u deze gebruikt .
Telegraf is over het algemeen een prima middel voor het verzamelen van statistieken, zelfs als u de rest van de ICK-stapel niet gebruikt.
Veel mensen kruisen het voor het gemak met ELK en diverse andere tijdreeksdatabases, omdat het vrijwel overal statistieken kan schrijven.
InstroomDB
InfluxDB is de belangrijkste kern van de TICK-stack, namelijk een tijdreeksdatabase voor statistieken.
Naast statistieken kan Influx ook logs opslaan, hoewel de logs ervoor in essentie precies dezelfde statistieken zijn, alleen in plaats van de gebruikelijke numerieke indicatoren wordt de hoofdfunctie uitgevoerd door een regel logtekst.
InfluxDB is ook geschreven in Go en lijkt veel sneller te draaien vergeleken met ELK op ons (niet het krachtigste) cluster.
Een van de coole voordelen van Influx zou ook een zeer handige en rijke API voor dataquery's zijn, die we zeer actief hebben gebruikt.
Nadelen - $$$ of schaalvergroting?
De TICK-stack heeft slechts één nadeel dat we hebben ontdekt: het дорогой. Nog meer.
Wat heeft de betaalde versie dat de gratis versie niet heeft?
Voor zover we hebben kunnen begrijpen, zijn het enige verschil tussen de betaalde versie van de TICK-stack en de gratis versie de schaalmogelijkheden.
U kunt namelijk alleen een cluster met hoge beschikbaarheid verhogen .
Als je volwaardige HA wilt, moet je betalen of wat krukken gebruiken. Er zijn bijvoorbeeld een aantal gemeenschapsoplossingen lijkt een competente oplossing, maar er staat geschreven dat deze ook niet geschikt is voor productie
- een eenvoudige oplossing waarbij gegevens via NATS worden gepompt (het zal ook moeten worden geschaald, maar dit kan worden opgelost).
Het is jammer, maar ze lijken allebei verlaten te zijn - er zijn geen nieuwe commits, ik neem aan dat het probleem de binnenkort verwachte release is van de nieuwe versie van Influx 2.0, waarin veel dingen anders zullen zijn (er is geen informatie over er nog niet in schalen).
Officieel is er een gratis versie - in feite is dit een primitieve HA, maar alleen door balanceren,
omdat alle gegevens naar alle InfluxDB-instanties achter de load balancer worden geschreven.
Hij heeft er een paar zoals potentiële problemen met het overschrijven van punten en de noodzaak om vooraf bases voor metrieken te creëren
(wat automatisch gebeurt tijdens normaal werk met InfluxDB).
Bovendien , betekent dit extra overhead voor dubbele statistieken (zowel verwerking als opslag) die u misschien niet nodig heeft, maar er is geen manier om ze te scheiden.
Victoria-statistieken?
Als gevolg hiervan besloten we, ondanks het feit dat we volledig tevreden waren met de TICK-stack in alles behalve betaalde schaling, om te kijken of er gratis oplossingen waren die de InfluxDB-database konden vervangen, terwijl we de resterende T_CK-componenten lieten staan.
Er zijn veel tijdreeksdatabases, maar de meest veelbelovende is Victoria Metrics, het heeft een aantal voordelen:
- Snel en gemakkelijk, althans volgens de resultaten
- Er is een clusterversie, waar inmiddels zelfs goede recensies over zijn
- Ze kan scheuren
- Ondersteunt het InfluxDB-protocol
Het was niet onze bedoeling om een volledig op maat gemaakte stack te bouwen op basis van Victoria en de voornaamste hoop was dat we deze konden gebruiken als drop-in vervanging voor InfluxDB.
Helaas is dit niet mogelijk, ondanks het feit dat het InfluxDB-protocol wordt ondersteund, werkt het alleen voor het vastleggen van statistieken - alleen de Prometheus API is “buiten” beschikbaar, wat betekent dat het niet mogelijk zal zijn om Chronograf erop in te stellen.
Bovendien worden alleen numerieke waarden ondersteund voor statistieken (we gebruikten tekenreekswaarden voor aangepaste statistieken - daarover meer in de sectie ).
Het is duidelijk dat de VM om dezelfde reden geen logboeken kan opslaan zoals Influx dat doet.
Ook moet worden opgemerkt dat Victoria Metrics op het moment van zoeken naar de optimale oplossing nog niet zo populair was, de documentatie veel kleiner was en de functionaliteit zwakker was
(Ik kan me geen gedetailleerde beschrijving van de clusterversie en sharding herinneren).
Basisselectie
Als gevolg hiervan werd besloten dat we ons voor de pilot nog steeds zouden beperken tot één InfluxDB-knooppunt.
Er waren verschillende belangrijke redenen voor deze keuze:
- We waren erg tevreden over de volledige functionaliteit van de TICK-stack
- We zijn er al in geslaagd om het in te zetten en het werkte prima
- De deadlines liepen op en er was niet veel tijd meer om andere opties te testen.
- Zo'n zware lading hadden we niet verwacht
We hadden niet veel scooters voor de eerste fase van de pilot, en testen tijdens de ontwikkeling brachten geen prestatieproblemen aan het licht.
Daarom hebben we besloten dat voor dit project één Influx-knooppunt voldoende voor ons zou zijn zonder dat er hoeft te worden geschaald (zie de conclusies aan het einde).
We hebben besloten over de stapel en de basis - nu over de resterende componenten van de TICK-stapel.
Kapacitor
Kapacitor maakt deel uit van de TICK-stack, een service die statistieken die de database binnenkomen in realtime kan monitoren en verschillende acties kan uitvoeren op basis van regels.
Over het algemeen wordt het gepositioneerd als een hulpmiddel voor het volgen van potentiële afwijkingen en machinaal leren (ik weet niet zeker of er veel vraag naar deze functies is), maar het meest populaire gebruik ervan is algemener: waarschuwingen.
Dat is hoe we het gebruikten voor meldingen. We hebben Slack-waarschuwingen ingesteld wanneer een bepaalde scooter offline ging, en hetzelfde werd gedaan voor slimme laders en belangrijke infrastructuurcomponenten.
Hierdoor was het mogelijk om snel op problemen te reageren en meldingen te ontvangen dat alles weer normaal was.
Een eenvoudig voorbeeld: een extra batterij om onze “box” van stroom te voorzien is kapot gegaan of is om de een of andere reden leeg; simpelweg door een nieuwe te installeren, zouden we na een tijdje een melding moeten ontvangen dat de functionaliteit van de scooter is hersteld.
In Influx 2.0 werd Kapacitor onderdeel van DB
chronograaf
Ik heb veel verschillende UI-oplossingen voor monitoring gezien, maar ik kan zeggen dat er qua functionaliteit en UX niets te vergelijken is met Chronograf.
We zijn vreemd genoeg begonnen met het gebruik van de TICK-stack, met Grafan als webinterface.
Ik zal de functionaliteit ervan niet beschrijven; iedereen kent de ruime mogelijkheden om van alles in te stellen.
Grafana is echter nog steeds een volledig universeel instrument, terwijl Chronograf vooral is ontworpen voor gebruik met Influx.
En dankzij dit kan Chronograf zich natuurlijk veel slimmere en handigere functionaliteit veroorloven.
Misschien wel het belangrijkste gemak van het werken met Chronograf is dat u via Explore de binnenkant van uw InfluxDB kunt bekijken.
Het lijkt erop dat Grafana vrijwel dezelfde functionaliteit heeft, maar in werkelijkheid kan het opzetten van een dashboard in Chronograf met een paar muisklikken (terwijl je daar de visualisatie bekijkt), terwijl je in Grafana vroeg of laat toch om de JSON-configuratie te bewerken (Chrongraf staat natuurlijk toe om je met de hand geconfigureerde dasha's te uploaden en ze indien nodig als JSON te bewerken - maar ik hoefde ze nooit aan te raken nadat ik ze in de gebruikersinterface had gemaakt).
Kibana heeft veel rijkere mogelijkheden voor het maken van dashboards en bedieningselementen, maar de UX voor dergelijke bewerkingen is erg complex.
Er is wat goed inzicht voor nodig om een handig dashboard te maken. En hoewel de functionaliteit van Chronograf-dashboards minder is, is het maken en aanpassen ervan veel eenvoudiger.
De dashboards zelf verschillen, afgezien van de prettige visuele stijl, eigenlijk niet van de dashboards in Grafana of Kibana:
Zo ziet het queryvenster eruit:
Het is onder andere belangrijk op te merken dat als u de typen velden in de InfluxDB-database kent, de chronograaf zelf u soms automatisch kan helpen bij het schrijven van een query of het kiezen van de juiste aggregatiefunctie zoals mean.
En natuurlijk is Chronograf zo handig mogelijk voor het bekijken van logs. Het ziet er zo uit:
Standaard zijn Influx-logboeken afgestemd op het gebruik van syslog en daarom hebben ze een belangrijke parameter: ernst.
Vooral handig is de grafiek bovenaan; daarop zie je de fouten die optreden en de kleur laat meteen duidelijk zien of de ernst hoger is.
Een paar keer hebben we op deze manier belangrijke bugs ontdekt, waarbij we de logs van de afgelopen week bekeken en een rode piek zagen.
Idealiter zou het natuurlijk zijn om waarschuwingen voor dergelijke fouten in te stellen, aangezien we hiervoor al alles hadden.
We hebben dit zelfs een tijdje ingeschakeld, maar tijdens het voorbereiden van de pilot bleek dat we behoorlijk wat fouten kregen (waaronder systeemfouten zoals de onbeschikbaarheid van het LTE-netwerk), die ook het Slack-kanaal 'spamden' veel, zonder problemen te veroorzaken, groot voordeel.
De juiste oplossing zou zijn om de meeste van dit soort fouten af te handelen, de ernst ervan aan te passen en pas daarna waarschuwingen in te schakelen.
Op deze manier zouden alleen nieuwe of belangrijke fouten op Slack worden gepost. Gezien de krappe deadlines was er simpelweg niet genoeg tijd voor een dergelijke opzet.
authenticatie
Het is ook vermeldenswaard dat Chronograf OAuth en OIDC als authenticatie ondersteunt.
Dit is erg handig, omdat u het eenvoudig aan uw server kunt koppelen en een volwaardige SSO kunt creëren.
In ons geval was de server dat wel — het werd gebruikt om verbinding te maken met monitoring, maar dezelfde server werd ook gebruikt om scooters en verzoeken aan de back-end te authenticeren.
"Beheerder"
Het laatste onderdeel dat ik zal beschrijven is ons zelfgeschreven “adminpanel” in Vue.
In feite is het gewoon een op zichzelf staande service die scooterinformatie uit onze eigen databases, microservices en metrische gegevens van InfluxDB tegelijkertijd weergeeft.
Daarnaast zijn veel administratieve functies daar naartoe verplaatst, zoals een noodherstart of het op afstand openen van een slot voor het supportteam.
Er waren ook kaarten. Ik zei al dat we met Grafana zijn begonnen in plaats van Chronograf - omdat voor Grafana kaarten beschikbaar zijn in de vorm van plug-ins, waarop we de coördinaten van scooters konden bekijken. Helaas zijn de mogelijkheden van kaartwidgets voor Grafana zeer beperkt, en als gevolg daarvan was het veel gemakkelijker om binnen een paar dagen uw eigen webapplicatie met kaarten te schrijven, om op dit moment niet alleen de coördinaten te zien, maar ook weer te geven de route die de scooter aflegt, de gegevens op de kaart kunnen filteren, enz. (al die functionaliteit die we niet in een eenvoudig dashboard konden configureren).
Een van de reeds genoemde voordelen van Influx is de mogelijkheid om eenvoudig uw eigen statistieken te creëren.
Hierdoor kan het voor een grote verscheidenheid aan scenario's worden gebruikt.
We hebben geprobeerd daar alle nuttige informatie vast te leggen: batterijlading, slotstatus, sensorprestaties, bluetooth, GPS en vele andere gezondheidscontroles.
We hebben dit allemaal weergegeven in het beheerderspaneel.
Het belangrijkste criterium voor ons was natuurlijk de bedrijfstoestand van de scooter - sterker nog, Influx controleert dit zelf en geeft dit aan met "groene lichten" in de sectie Knooppunten.
Dit wordt gedaan door de functie - we gebruikten het om de prestaties van onze box te begrijpen en diezelfde waarschuwingen naar Slack te sturen.
We hebben de scooters trouwens vernoemd naar de namen van personages uit The Simpsons - het was zo handig om ze van elkaar te onderscheiden
En over het algemeen was het op deze manier leuker. Zinnen als “Jongens, Smithers is dood!” waren voortdurend te horen.
Tekenreeksstatistieken
Het is belangrijk dat u met InfluxDB niet alleen numerieke waarden kunt opslaan, zoals het geval is bij Victoria Metrics.
Het lijkt erop dat dit niet zo belangrijk is - afgezien van logs kunnen immers alle statistieken worden opgeslagen in de vorm van getallen (voeg gewoon mapping toe voor bekende toestanden - een soort enum)?
In ons geval was er minstens één scenario waarin stringstatistieken erg nuttig waren.
Toevallig was de leverancier van onze ‘slimme laders’ een derde partij, wij hadden geen controle over het ontwikkelingsproces en de informatie die deze laders konden leveren.
Als gevolg hiervan was de oplaad-API verre van ideaal, maar het grootste probleem was dat we hun toestand niet altijd konden begrijpen.
Dit is waar Influx te hulp kwam. We hebben eenvoudigweg de stringstatus die bij ons binnenkwam, zonder wijzigingen in het InfluxDB-databaseveld geschreven.
Een tijdlang waren er alleen waarden als 'online' en 'offline', op basis van welke informatie werd weergegeven in ons beheerderspaneel en er werden meldingen naar Slack gestuurd. Op een gegeven moment begonnen daar echter ook waarden als ‘losgekoppeld’ te verschijnen.
Deze status werd, zo bleek later, eenmalig verzonden na het wegvallen van de verbinding, als de lader na een bepaald aantal pogingen geen verbinding met de server tot stand kon brengen.
Als we dus alleen een vaste reeks waarden zouden gebruiken, zouden we deze veranderingen mogelijk niet op het juiste moment in de firmware zien.
En over het algemeen bieden stringmetrics veel meer gebruiksmogelijkheden; je kunt er vrijwel alle informatie in vastleggen. Hoewel je deze tool natuurlijk ook zorgvuldig moet gebruiken.
Naast de gebruikelijke statistieken hebben we ook GPS-locatie-informatie vastgelegd in InfluxDB. Dit was ongelooflijk handig voor het monitoren van de locatie van scooters in ons beheerderspaneel.
Sterker nog, we wisten altijd waar en welke scooter zich bevond op het moment dat we nodig hadden.
Dit was voor ons erg handig toen we op zoek waren naar een scooter (zie conclusies aan het einde).
Bewaking van de infrastructuur
Naast de scooters zelf moesten we ook onze gehele (vrij uitgebreide) infrastructuur monitoren.
Een zeer algemene architectuur zag er ongeveer zo uit:
Als we een pure monitoringstack benadrukken, ziet deze er als volgt uit:
Wat we graag willen controleren in de cloud is:
- Databank
- Sleutelmantel
- Microdiensten
Omdat al onze clouddiensten zich in Kubernetes bevinden, zou het leuk zijn om informatie over de staat ervan te verzamelen.
Gelukkig kan Telegraf out of the box enorm veel metrics verzamelen over de staat van het Kubernetes-cluster, en Chronograf biedt hiervoor direct prachtige dashboards aan.
We hielden vooral de prestaties van de pods en het geheugengebruik in de gaten. Bij een val waarschuwingen in Slack.
Er zijn twee manieren om pods te volgen in Kubernetes: DaemonSet en Sidecar.
Beide methoden worden gedetailleerd beschreven .
We gebruikten Telegraf Sidecar en verzamelden, naast statistieken, podlogboeken.
In ons geval moesten we aan de boomstammen sleutelen. Ondanks dat Telegraf logs uit de Docker API kan halen, wilden we een uniforme verzameling logs hebben met onze eindapparaten en hebben we hiervoor syslog voor containers geconfigureerd. Misschien was deze oplossing niet mooi, maar er waren geen klachten over het werk ervan en de logs werden goed weergegeven in Chronograf.
Toezicht houden???
Uiteindelijk rees de eeuwenoude kwestie van het monitoren van monitoringsystemen, maar gelukkig, of helaas, hadden we daar simpelweg niet genoeg tijd voor.
Hoewel Telegraf eenvoudig zijn eigen statistieken kan verzenden of statistieken uit de InfluxDB-database kan verzamelen om deze naar dezelfde Influx of ergens anders te verzenden.
Bevindingen
Welke conclusies hebben we getrokken uit de resultaten van de pilot?
Hoe kun je aan monitoring doen?
Allereerst voldeed de TICK-stack volledig aan onze verwachtingen en gaf ons nog meer kansen dan we aanvankelijk hadden verwacht.
Alle functionaliteit die we nodig hadden was aanwezig. Alles wat we ermee deden, werkte zonder problemen.
Производительность
Het grootste probleem met de TICK-stack in de gratis versie is het gebrek aan schaalmogelijkheden. Dit was voor ons geen probleem.
We hebben geen exacte beladingsgegevens/cijfers verzameld, maar we hebben gegevens verzameld van ongeveer 30 scooters tegelijk.
Elk van hen verzamelde meer dan drie dozijn statistieken. Tegelijkertijd werden logs van de apparaten verzameld. Het verzamelen en verzenden van gegevens vond elke 10 seconden plaats.
Het is belangrijk op te merken dat na anderhalve week van de pilot, toen het grootste deel van de ‘kinderproblemen’ was gecorrigeerd en de belangrijkste problemen al waren opgelost, we de frequentie van het verzenden van gegevens naar de server moesten verminderen om 30 seconden. Dit werd nodig omdat het verkeer op onze LTE-simkaarten snel begon te verdwijnen.
Het grootste deel van het verkeer werd verbruikt door logs; de statistieken zelf, zelfs met een interval van 10 seconden, verspilden het praktisch niet.
Als gevolg hiervan hebben we na enige tijd het verzamelen van logbestanden op apparaten volledig uitgeschakeld, omdat specifieke problemen al duidelijk waren, zelfs zonder constante verzameling.
In sommige gevallen, als het bekijken van de logs nog steeds nodig was, hebben we eenvoudigweg verbinding gemaakt via WireGuard via VPN.
Ik zal er ook aan toevoegen dat elke afzonderlijke omgeving van elkaar gescheiden was en dat de hierboven beschreven belasting alleen relevant was voor de productieomgeving.
In de ontwikkelomgeving hebben we een aparte InfluxDB-instantie opgezet die elke 10 seconden gegevens bleef verzamelen en we kwamen geen prestatieproblemen tegen.
TICK - ideaal voor kleine tot middelgrote projecten
Op basis van deze informatie zou ik concluderen dat de TICK-stack ideaal is voor relatief kleine projecten of projecten die absoluut geen HighLoad verwachten.
Als je niet over duizenden pods of honderden machines beschikt, kan zelfs één InfluxDB-instantie de belasting prima aan.
In sommige gevallen bent u wellicht tevreden met Influx Relay als primitieve High Availability-oplossing.
En uiteraard houdt niemand u tegen om ‘verticale’ schaling in te stellen en eenvoudigweg verschillende servers toe te wijzen voor verschillende soorten statistieken.
Als u niet zeker bent van de verwachte belasting van de monitoringdiensten, of als u gegarandeerd een zeer “zware” architectuur heeft/zullen hebben, zou ik niet aanraden om de gratis versie van de TICK-stack te gebruiken.
Een eenvoudige oplossing zou natuurlijk zijn om te kopen - maar hier kan ik op de een of andere manier geen commentaar op geven, omdat ik zelf niet bekend ben met de subtiliteiten. Naast dat het erg duur is en zeker niet geschikt voor kleine bedrijven.
In dit geval zou ik vandaag aanraden om te kijken naar het verzamelen van statistieken via Victoria Metrics en logs met behulp van Loki.
Het is waar dat ik opnieuw zal reserveren dat Loki/Grafana veel minder handig zijn (vanwege hun grotere veelzijdigheid) dan de kant-en-klare TICK, maar ze zijn gratis.
Het is belangrijk: alle hier beschreven informatie is relevant voor versie Influx 1.8, op dit moment staat Influx 2.0 op het punt te verschijnen.
Hoewel ik nog geen kans heb gehad om het in gevechtsomstandigheden te proberen en het moeilijk is om conclusies te trekken over verbeteringen, is de interface zeker nog beter geworden, is de architectuur vereenvoudigd (zonder condensator en chronograaf),
sjablonen verschenen (“killer feature” - ). Maar helaas heeft versie 2 op dit moment niet het belangrijkste waarvoor we de eerste versie hebben gekozen: er is geen logverzameling.
Deze functionaliteit zal ook verschijnen in Influx 2.0, maar we konden geen deadlines vinden, zelfs niet bij benadering.
Hoe je geen IoT-platforms maakt (nu)
Uiteindelijk hebben we, nadat we de pilot hadden gelanceerd, zelf onze eigen volwaardige IoT-stack samengesteld, bij gebrek aan een alternatief dat geschikt was voor onze normen.
Sinds kort is het echter beschikbaar in de bètaversie – het is jammer dat ze er niet was toen we aan het project begonnen.
Wij zijn helemaal tevreden met het eindresultaat en het platform op basis van Ansible + TICK + WireGuard dat we zelf in elkaar hebben gezet. Maar vandaag zou ik aanraden om Balena eens nader te bekijken voordat je zelf je eigen IoT-platform gaat bouwen.
Omdat het uiteindelijk het meeste kan doen van wat wij deden, en OpenBalena gratis en open source is.
Het weet al hoe het niet alleen updates moet verzenden, maar ook een VPN is al ingebouwd en afgestemd op gebruik in een IoT-omgeving.
En onlangs hebben ze zelfs hun , die gemakkelijk verbinding maakt met hun ecosysteem.
Hé, hoe zit het met de vermiste scooter?
Dus de scooter, "Ralph", verdween spoorloos.
We renden meteen naar de kaart in ons “beheerderspaneel”, met GPS-metrische gegevens van InfluxDB.
Dankzij monitoringgegevens konden we gemakkelijk vaststellen dat de scooter de afgelopen dag rond 21 uur de parkeerplaats verliet, ongeveer een half uur naar een bepaald gebied reed en tot 00 uur naast een Duits huis geparkeerd stond.
Na 5 uur werden er geen monitoringgegevens ontvangen. Dit betekende dat de extra batterij volledig leeg was, of dat de aanvaller er eindelijk achter kwam hoe hij de slimme hardware van de scooter kon verwijderen.
Desondanks werd toch de politie gebeld naar het adres waar de scooter stond. De scootmobiel was er niet.
Maar ook de eigenaar van de woning was hierdoor verrast, aangezien hij gisteravond daadwerkelijk met deze scooter vanaf kantoor naar huis reed.
Het bleek dat een van de ondersteuningsmedewerkers 's morgens vroeg arriveerde, de scooter ophaalde, zag dat de extra batterij volledig leeg was, en hem (te voet) naar de parkeerplaats bracht. En de extra batterij viel uit vanwege vocht.
We hebben de scooter van onszelf gestolen. Ik weet overigens niet hoe en wie de kwestie vervolgens met de politiezaak heeft opgelost, maar de monitoring werkte perfect...
Bron: www.habr.com