For et år siden lancerede vi en pilotversion af et salgsfremmende projekt for .
Oprindeligt hed projektet Road-To-Barcelona, senere blev det Road-To-Berlin (derfor R2B i skærmbillederne), og til sidst hed det xRide.
Hovedidéen med projektet var denne: i stedet for at have en centraliseret bil- eller scooterudlejningsservice (vi taler om scootere aka elektriske motorcykler, ikke sparkescootere/scootere) ønskede vi at lave en platform for decentral udlejning. Om de vanskeligheder, vi stødte på .
I første omgang fokuserede projektet på biler, men på grund af deadlines, ekstrem lang kommunikation med producenter og et stort antal sikkerhedsrestriktioner blev el-scootere valgt til piloten.
Brugeren installerede en iOS eller Android applikation på telefonen, henvendte sig til den scooter han kunne lide, hvorefter telefonen og løbehjulet etablerede en peer-to-peer forbindelse, ETH blev udskiftet og brugeren kunne starte turen ved at tænde for scooteren via telefonen. Ved rejsens afslutning var det også muligt at betale for rejsen med Ethereum fra brugerens pung på telefonen.
Ud over løbehjul så brugeren "smarte opladere" i applikationen, ved at besøge, hvor brugeren selv kunne skifte det nuværende batteri, hvis det var lavt.
Sådan så vores pilot generelt ud, som blev lanceret i september sidste år i to tyske byer: Bonn og Berlin.
Og så, en dag i Bonn, tidligt om morgenen, blev vores supportteam (placeret på stedet for at holde scootere i funktionsdygtig stand) advaret: en af scooterne var sporløst forsvundet.
Hvordan finder man den og returnerer den?
I denne artikel vil jeg tale om dette, men først - om hvordan vi byggede vores egen IoT-platform og hvordan vi overvågede den.
Hvad og hvorfor skal man overvåge: scootere, infrastruktur, ladestandere?
Så hvad ønskede vi at overvåge i vores projekt?
Først og fremmest er dette scooterne selv - elektriske scootere i sig selv er ret dyre, du kan ikke starte et sådant projekt uden at være tilstrækkeligt forberedt; hvis det er muligt, vil du indsamle så meget information som muligt om scooterne: om deres placering, opladningsniveau , etc.
Derudover vil jeg gerne overvåge tilstanden af vores egen it-infrastruktur – databaser, services og alt hvad de skal bruge for at fungere. Det var også nødvendigt at overvåge status for "smart opladere", i tilfælde af at de gik i stykker eller løb tør for fulde batterier.
Løbehjul
Hvad var vores scootere, og hvad ville vi gerne vide om dem?
Den første og vigtigste ting er GPS-koordinater, da vi takket være dem kan forstå, hvor de er, og hvor de bevæger sig.
Dernæst er batteriopladningen, takket være hvilken vi kan fastslå, at opladningen af løbehjulene er ved at være slut og sende en juicer eller i det mindste advare brugeren.
Det er selvfølgelig også nødvendigt at tjekke, hvad der sker med vores hardwarekomponenter:
- virker bluetooth?
- virker selve GPS-modulet?
- Vi havde også et problem med, at GPS'en kunne sende forkerte koordinater og sætte sig fast, og det kunne kun konstateres ved yderligere kontrol på scooteren,
og underret support så hurtigt som muligt for at løse problemet
- Vi havde også et problem med, at GPS'en kunne sende forkerte koordinater og sætte sig fast, og det kunne kun konstateres ved yderligere kontrol på scooteren,
Og til sidst: kontrol af softwaren, startende med OS og processor, netværk og diskbelastning, slutter med kontrol af vores egne moduler, der er mere specifikke for os (, ).
Hardware
Hvad var vores "jern" del?
Under hensyntagen til den kortest mulige tidsramme og behovet for hurtig prototyping, valgte vi den nemmeste mulighed for implementering og valg af komponenter - Raspberry Pi.
Ud over selve Rpi'en havde vi et specialkort (som vi selv udviklede og bestilte fra Kina for at fremskynde samlingsprocessen af den endelige løsning) og et sæt komponenter - et relæ (til at tænde/slukke for scooteren), en batteriopladningslæser, et modem, antenner. Alt dette var kompakt pakket i en speciel "xRide-boks".
Det skal også bemærkes, at hele kassen blev drevet af en ekstra powerbank, som igen blev drevet af scooterens hovedbatteri.
Dette gjorde det muligt at bruge overvågning og tænde for scooteren selv efter turens afslutning, da hovedbatteriet blev slukket umiddelbart efter at have drejet tændingsnøglen til "off"-positionen.
Docker? Almindelig Linux? og indsættelse
Lad os vende tilbage til overvågningen, så Raspberry - hvad har vi?
En af de første ting, vi ønskede at bruge til at fremskynde processen med at implementere, opdatere og levere komponenter til fysiske enheder, var Docker.
Desværre blev det hurtigt klart, at Docker på RPi, selvom det virker, har en masse overhead, især med hensyn til strømforbrug.
Forskellen ved at bruge det "native" OS, selvom det ikke var så stærkt, var stadig tilstrækkeligt til, at vi var på vagt over for muligheden for at miste ladningen for hurtigt.
Den anden grund var et af vores partnerbiblioteker på Node.js (sic!) - den eneste komponent i systemet, der ikke var skrevet i Go/C/C++.
Bibliotekets forfattere havde ikke tid til at levere en fungerende version på nogen af de "indfødte" sprog.
Ikke alene er selve noden ikke den mest elegante løsning til enheder med lav ydeevne, men selve biblioteket var meget ressourcekrævende.
Vi indså, at selvom vi ville, ville det være for meget af en overhead for os at bruge Docker. Valget blev truffet til fordel for det oprindelige OS og arbejde direkte under det.
OS
Som et resultat valgte vi igen den enkleste mulighed som OS og brugte Raspbian (Debian build til Pi).
Vi skriver al vores software i Go, så vi skrev også hovedhardwareagentmodulet i vores system i Go.
Det er ham, der har ansvaret for at arbejde med GPS, Bluetooth, aflæse ladningen, tænde for scooteren mv.
Indsætte
Spørgsmålet opstod straks om behovet for at implementere en mekanisme til levering af opdateringer til enheder (OTA) - både opdateringer til vores agent/applikation selv og opdateringer til selve OS/firmwaren (da nye versioner af agenten kunne kræve opdateringer til kernen eller systemkomponenter, biblioteker osv.).
Efter en ganske lang analyse af markedet viste det sig, at der findes en del løsninger til at levere opdateringer til enheden.
Fra relativt enkle, for det meste opdaterings-/dual-boot-orienterede værktøjer som swupd/SWUpdate/OSTree til fuldgyldige platforme som Mender og Balena.
Først og fremmest besluttede vi, at vi var interesserede i end-to-end løsninger, så valget faldt straks på platforme.
Det hele blev udelukket på grund af det faktum, at den faktisk bruger den samme Docker inde i sin balenaEngine.
Men jeg bemærker, at på trods af dette, endte vi med konstant at bruge deres produkt til flash-firmware på SD-kort - et simpelt og ekstremt praktisk værktøj til dette.
Derfor faldt valget i sidste ende på . Mender er en komplet platform til montering, levering og installation af firmware.
Alt i alt ser platformen godt ud, men det tog os omkring halvanden uge bare at bygge den korrekte version af vores firmware ved hjælp af mender-builderen.
Og jo mere vi fordybede os i forviklingerne ved brugen af det, jo mere blev det klart, at for at implementere det fuldt ud ville vi bruge meget mere tid, end vi havde.
Ak, vores stramme deadlines betød, at vi var tvunget til at opgive brugen af Mender og vælge en endnu enklere.
Ansible
Den enkleste løsning i vores situation var at bruge Ansible. Et par spillebøger var nok til at komme i gang.
Deres essens var, at vi simpelthen oprettede forbindelse fra værten (CI-serveren) via ssh til vores rasberries og distribuerede opdateringer til dem.
I begyndelsen var alt enkelt - du skulle være på det samme netværk med enhederne, hældning foregik via Wi-Fi.
På kontoret var der simpelthen et dusin test-hindbær forbundet til det samme netværk, hver enhed havde en statisk IP-adresse, også angivet i Ansible Inventory.
Det var Ansible, der leverede vores overvågningsagent til slutenhederne
3G / LTE
Desværre kunne denne use case for Ansible kun fungere i udviklingstilstand, før vi havde egentlige scootere.
Fordi scootere, som du forstår, ikke sidder forbundet til én Wi-Fi-router og venter konstant på opdateringer over netværket.
I virkeligheden kan scootere slet ikke have nogen anden forbindelse end mobil 3G/LTE (og selv da ikke hele tiden).
Dette medfører umiddelbart mange problemer og begrænsninger, såsom lav forbindelseshastighed og ustabil kommunikation.
Men det vigtigste er, at vi i et 3G/LTE-netværk ikke bare kan stole på en statisk IP, der er tildelt netværket.
Dette er delvist løst af nogle SIM-kortudbydere; der er endda specielle SIM-kort designet til IoT-enheder med statiske IP-adresser. Men vi havde ikke adgang til sådanne SIM-kort og kunne ikke bruge IP-adresser.
Selvfølgelig var der ideer til at lave en form for registrering af IP-adresser aka service discovery et sted som Consul, men vi var nødt til at opgive sådanne ideer, da IP-adressen i vores test kunne ændre sig for ofte, hvilket førte til stor ustabilitet.
Af denne grund ville den mest bekvemme brug til levering af metrics ikke være at bruge pull-modellen, hvor vi ville gå til enheder for de nødvendige metrics, men push, levere metrics fra enheden direkte til serveren
VPN
Som en løsning på dette problem valgte vi VPN – specifikt .
Klienter (scootere) i starten af systemet tilsluttede sig VPN-serveren og var i stand til at oprette forbindelse til dem. Denne tunnel blev brugt til at levere opdateringer.
I teorien kunne den samme tunnel bruges til overvågning, men en sådan forbindelse var mere kompliceret og mindre pålidelig end simpel push.
Cloud ressourcer
Endelig er det nødvendigt at overvåge vores cloud-tjenester og databaser, da vi bruger Kubernetes til dem, ideelt for at implementeringen af overvågning i klyngen er så enkel som muligt. Ideelt set bruger , da vi i de fleste tilfælde bruger det til implementering. Og for at overvåge skyen skal du selvfølgelig bruge de samme løsninger som til selve løbehjulene.
Givet
Pyh, vi ser ud til at have ordnet beskrivelsen, lad os lave en liste over, hvad vi havde brug for til sidst:
- En hurtig løsning, da overvågning er nødvendig allerede under udviklingsprocessen
- Mængde/mængde – mange målinger er nødvendige
- Logindsamling er påkrævet
- Pålidelighed – data er afgørende for at lancere succes
- Du kan ikke bruge pull-modellen - du har brug for push
- Vi har brug for samlet overvågning af ikke kun hardware, men også cloud
Det endelige billede så nogenlunde sådan her ud
Stakvalg
Så vi stod over for spørgsmålet om at vælge en overvågningsstack.
Først og fremmest ledte vi efter den mest komplette alt-i-én-løsning, der samtidig ville dække alle vores krav, men samtidig være fleksibel nok til at skræddersy brugen til vores behov. Alligevel havde vi mange restriktioner pålagt os af hardware, arkitektur og deadlines.
Der er et stort udvalg af overvågningsløsninger, startende med fuldgyldige systemer som , eller og afsluttes med færdige løsninger til flådestyring.
I starten virkede sidstnævnte som en ideel løsning for os, men nogle havde ikke fuld overvågning, andre havde stærkt begrænsede muligheder for de gratis versioner, og andre dækkede simpelthen ikke vores "ønsker" eller var ikke fleksible nok til at passe til vores scenarier. Nogle er simpelthen forældede.
Efter at have analyseret en række lignende løsninger, kom vi hurtigt frem til, at det ville være nemmere og hurtigere selv at samle en lignende stak. Ja, det vil være lidt mere kompliceret end at implementere en fuldstændig færdiglavet flådestyringsplatform, men vi behøver ikke at gå på kompromis.
Næsten helt sikkert, i al den enorme overflod af løsninger, er der allerede en færdiglavet en, der ville passe helt til os, men i vores tilfælde var det meget hurtigere at samle en bestemt stak på egen hånd og tilpasse den "til os selv" i stedet for test af færdige produkter.
Med alt dette stræbte vi ikke efter selv at samle en hel overvågningsplatform, men ledte efter de mest funktionelle "færdige" stakke, kun med muligheden for at konfigurere dem fleksibelt.
(B)ELK?
Den første løsning, der rent faktisk blev overvejet, var den velkendte ELK-stak.
Faktisk burde den hedde BELK, for det hele starter med Beats —
Selvfølgelig er ELK en af de mest kendte og kraftfulde løsninger inden for overvågning, og endnu mere inden for indsamling og behandling af logfiler.
Vi havde til hensigt, at ELK skulle bruges til at indsamle logfiler og samt langtidsopbevaring af metrik opnået fra Prometheus.
Til visualisering kan du bruge Grafan.
Faktisk kan den nye ELK-stack indsamle metrics uafhængigt (metricbeat), og Kibana kan også vise dem.
Men alligevel voksede ELK oprindeligt ud af logfiler, og indtil videre har metrikkernes funktionalitet en række alvorlige ulemper:
- Betydeligt langsommere end Prometheus
- Integreres langt færre steder end Prometheus
- Det er svært at konfigurere underretninger for dem
- Metrikker fylder meget
- Opsætning af dashboards med metrics i Kiban er meget mere kompliceret end i Grafan
Generelt er metrikken i ELK tunge og endnu ikke så bekvemme som i andre løsninger, som der nu er meget mere af end blot Prometheus: TSDB, Victoria Metrics, Cortex osv. osv. Selvfølgelig ville jeg rigtig gerne have en fuldgyldig alt-i-en løsning med det samme, men i tilfælde af metricbeat var der for mange kompromiser.
Og selve ELK-stakken har en række svære øjeblikke:
- Det er tungt, nogle gange endda meget tungt, hvis man indsamler en ret stor mængde data
- Du skal "vide hvordan man laver mad" det - du skal skalere det, men det er ikke trivielt at gøre
- Strippet gratis version - den gratis version har ikke normal advarsel, og på tidspunktet for valg var der ingen godkendelse
Jeg må sige, at det sidste punkt for nylig er blevet bedre og derudover (inklusive autentificering) begyndte selve prismodellen at ændre sig.
Men på det tidspunkt, hvor vi skulle implementere denne løsning, var der ingen advarsel overhovedet.
Måske kunne vi have forsøgt at bygge noget ved hjælp af ElastAlert eller andre fællesskabsløsninger, men vi besluttede alligevel at overveje andre alternativer.
Loke - Grafana - Prometheus
I øjeblikket kan en god løsning være at bygge en overvågningsstack udelukkende baseret på Prometheus som metrics-leverandør, Loki til logs, og til visualisering kan du bruge den samme Grafana.
På tidspunktet for starten af salgspiloten af projektet (september-oktober 19) var Loki desværre stadig i betaversion 0.3-0.4, og på tidspunktet for starten af udviklingen kunne den ikke betragtes som en produktionsløsning overhovedet.
Jeg har endnu ikke erfaring med rent faktisk at bruge Loki i seriøse projekter, men jeg kan sige, at Promtail (en agent til indsamling af træstammer) fungerer fantastisk til både bare-metal og pods i kubernetes.
FLETTE
Måske det mest værdige (det eneste?) fuldt udstyrede alternativ til ELK-stakken kan nu kun kaldes TICK-stakken - Telegraf, InfluxDB, Chronograf, Kapacitor.
Jeg vil beskrive alle komponenterne nedenfor mere detaljeret, men den generelle idé er denne:
- Telegraf - agent til indsamling af metrics
- InfluxDB - metrics database
- Kapacitor - real-time metrics processor til alarmering
- Chronograf - webpanel til visualisering
For InfluxDB, Kapacitor og Chronograf er der officielle styrdiagrammer, som vi brugte til at implementere dem.
Det skal bemærkes, at i den seneste version af Influx 2.0 (beta) blev Kapacitor og Chronograf en del af InfluxDB og eksisterer ikke længere separat.
telegraf
er et meget letvægtsmiddel til at indsamle metrikker på en statsmaskine.
Han kan overvåge en enorm mængde af alt, fra til
server .
Det har en række fede fordele:
- Hurtig og let (skrevet i Go)
- Spiser et minimum af ressourcer
- Push-metrics som standard
- Samler alle nødvendige metrics
- Systemmålinger uden nogen indstillinger
- Hardwaremålinger såsom information fra sensorer
- Det er meget nemt at tilføje dine egne metrics
- Masser af plugins ud af kassen
- Samler logs
Da push-metrics var nødvendige for os, var alle andre fordele mere end behagelige tilføjelser.
Indsamling af logfiler af agenten selv er også meget praktisk, da der ikke er behov for at forbinde yderligere værktøjer til logning af logfiler.
Influx tilbyder den mest bekvemme oplevelse for at arbejde med logfiler, hvis du bruger .
Telegraf er generelt en fantastisk agent til at indsamle metrics, selvom du ikke bruger resten af ICK-stakken.
Mange mennesker krydser det med ELK og forskellige andre tidsseriedatabaser for nemheds skyld, da det kan skrive metrics næsten overalt.
TilstrømningDB
InfluxDB er hovedkernen i TICK-stakken, nemlig en tidsseriedatabase for metrics.
Ud over metrikker kan Influx også gemme logfiler, selvom logfiler i det væsentlige kun er de samme metrikker, men i stedet for de sædvanlige numeriske indikatorer udføres hovedfunktionen af en linje med logtekst.
InfluxDB er også skrevet i Go og ser ud til at køre meget hurtigere sammenlignet med ELK på vores (ikke den mest kraftfulde) klynge.
En af de fede fordele ved Influx ville også omfatte en meget praktisk og rig API til dataforespørgsler, som vi brugte meget aktivt.
Ulemper - $$$ eller skalering?
TICK-stakken har kun én ulempe, som vi opdagede - den kære. Endnu mere.
Hvad har den betalte version, som den gratis version ikke har?
Så vidt vi var i stand til at forstå, er den eneste forskel mellem den betalte version af TICK-stakken og den gratis skaleringsmulighederne.
Du kan nemlig rejse en klynge med høj tilgængelighed kun i .
Hvis du vil have fuldgyldig HA, skal du enten betale eller bruge nogle krykker. Der er et par fællesskabsløsninger – f.eks ligner en kompetent løsning, men det er skrevet, at den ikke egner sig til produktion, samt
- en simpel løsning med datapumpning gennem NATS (det skal også skaleres, men det kan løses).
Det er ærgerligt, men begge ser ud til at være forladt - der er ingen nye commits, jeg antager, at problemet er den snart forventede udgivelse af den nye version af Influx 2.0, hvor mange ting vil være anderledes (der er ingen information om skalering i det endnu).
Officielt er der en gratis version - faktisk er dette en primitiv HA, men kun gennem balancering,
da alle data vil blive skrevet til alle InfluxDB-instanser bag load balanceren.
Han har nogle som potentielle problemer med at overskrive punkter og behovet for at skabe baser for metrics på forhånd
(hvilket sker automatisk under normalt arbejde med InfluxDB).
Derudover , betyder det yderligere overhead for duplikerede metrics (både behandling og lagring), som du måske ikke har brug for, men der er ingen måde at adskille dem.
Victoria Metrics?
Som et resultat, på trods af at vi var fuldstændig tilfredse med TICK-stakken i alt andet end betalt skalering, besluttede vi os for at se, om der var nogen gratis løsninger, der kunne erstatte InfluxDB-databasen, mens vi forlod de resterende T_CK-komponenter.
Der er mange tidsseriedatabaser, men den mest lovende er Victoria Metrics, den har en række fordele:
- Hurtigt og nemt, i hvert fald ifølge resultaterne
- Der er en klyngeversion, som der endda er gode anmeldelser om nu
- Hun kan sønderdele
- Understøtter InfluxDB protokol
Vi havde ikke til hensigt at bygge en helt tilpasset stack baseret på Victoria, og det vigtigste håb var, at vi kunne bruge det som en drop-in erstatning for InfluxDB.
Desværre er dette ikke muligt, på trods af at InfluxDB-protokollen er understøttet, virker den kun til optagelse af metrikker - kun Prometheus API er tilgængelig "udenfor", hvilket betyder, at det ikke vil være muligt at sætte Chronograf på den.
Desuden understøttes kun numeriske værdier for metrics (vi brugte strengværdier til brugerdefinerede metrics - mere om det i afsnittet ).
Naturligvis kan VM'en af samme grund ikke gemme logfiler, som Influx gør.
Det skal også bemærkes, at på tidspunktet for søgningen efter den optimale løsning var Victoria Metrics endnu ikke så populær, dokumentationen var meget mindre, og funktionaliteten var svagere
(Jeg kan ikke huske en detaljeret beskrivelse af klyngeversionen og sharding).
Basevalg
Som et resultat blev det besluttet, at vi for piloten stadig ville begrænse os til en enkelt InfluxDB-knude.
Der var flere hovedårsager til dette valg:
- Vi kunne virkelig godt lide hele funktionaliteten af TICK-stakken
- Vi formåede allerede at implementere det, og det fungerede godt
- Deadlines var ved at løbe ud, og der var ikke meget tid tilbage til at teste andre muligheder.
- Vi havde ikke forventet så tung en belastning
Vi havde ikke mange scootere til den første fase af piloten, og test under udviklingen afslørede ingen præstationsproblemer.
Derfor besluttede vi, at for dette projekt ville en tilstrømningsknude være nok for os uden behov for skalering (se konklusionerne sidst).
Vi har besluttet os for stakken og basen - nu om de resterende komponenter i TICK-stakken.
Kapacitor
Kapacitor er en del af TICK-stakken, en tjeneste, der kan overvåge metrikker, der kommer ind i databasen i realtid og udføre forskellige handlinger baseret på regler.
Generelt er det placeret som et værktøj til potentiel anomalisporing og maskinlæring (jeg er ikke sikker på, at disse funktioner er efterspurgte), men det mest populære tilfælde for dets brug er mere banalt - alarmerende.
Sådan brugte vi det til notifikationer. Vi satte Slack-advarsler op, når en bestemt scooter gik offline, og det samme blev gjort for smarte opladere og vigtige infrastrukturkomponenter.
Dette gjorde det muligt hurtigt at reagere på problemer, samt modtage meddelelser om, at alt var tilbage til det normale.
Et simpelt eksempel: et ekstra batteri til at drive vores "boks" er gået i stykker eller af en eller anden grund er løbet tør for strøm; blot ved at installere et nyt, skulle vi efter et stykke tid modtage en meddelelse om, at scooterens funktionalitet er blevet genoprettet.
I Influx 2.0 blev Kapacitor en del af DB
Kronograf
Jeg har set mange forskellige UI-løsninger til overvågning, men jeg kan sige, at med hensyn til funktionalitet og UX er der intet, der kan sammenlignes med Chronograf.
Vi begyndte at bruge TICK-stakken, mærkeligt nok, med Grafan som en webgrænseflade.
Jeg vil ikke beskrive dens funktionalitet; alle kender dens brede muligheder for at konfigurere hvad som helst.
Grafana er dog stadig et helt universelt instrument, mens Chronograf hovedsageligt er designet til brug med Influx.
Og selvfølgelig, takket være dette, har Chronograf råd til meget mere smart eller praktisk funktionalitet.
Måske er den største bekvemmelighed ved at arbejde med Chronograf, at du kan se indersiden af din InfluxDB gennem Explore.
Det ser ud til, at Grafana har næsten identisk funktionalitet, men i virkeligheden kan opsætning af et dashboard i Chronograf gøres med et par museklik (samtidig med at man ser på visualiseringen der), mens man i Grafana stadig før eller siden har at redigere JSON-konfigurationen (naturligvis tillader Chronograf uploade dine håndkonfigurerede dashas og redigere dem som JSON, hvis det er nødvendigt - men jeg behøvede aldrig at røre ved dem efter at have oprettet dem på brugergrænsefladen).
Kibana har meget rigere muligheder for at skabe dashboards og kontroller til dem, men UX til sådanne operationer er meget kompleks.
Det kræver en god forståelse for at skabe et praktisk dashboard. Og selvom funktionaliteten af Chronograf-dashboards er mindre, er det meget nemmere at lave og tilpasse dem.
Selve dashboards, bortset fra den behagelige visuelle stil, adskiller sig faktisk ikke fra dashboards i Grafana eller Kibana:
Sådan ser forespørgselsvinduet ud:
Det er blandt andet vigtigt at bemærke, at ved at kende typerne af felter i InfluxDB-databasen, kan kronografen nogle gange automatisk hjælpe dig med at skrive en forespørgsel eller vælge den korrekte aggregeringsfunktion som middelværdi.
Og selvfølgelig er Chronograf så praktisk som muligt til at se logfiler. Det ser sådan ud:
Som standard er Influx logs skræddersyet til at bruge syslog, og derfor har de en vigtig parameter - sværhedsgrad.
Grafen øverst er især nyttig, på den kan du se de fejl, der opstår, og farven viser med det samme tydeligt, om sværhedsgraden er højere.
Et par gange fangede vi vigtige fejl på denne måde, hvor vi skulle se logfilerne for den sidste uge og så en rød spids.
Selvfølgelig ville det ideelt set være at oprette alarmer for sådanne fejl, da vi allerede havde alt til dette.
Vi har endda slået dette til i et stykke tid, men under forberedelsen af pilotprojektet viste det sig, at vi fik en del fejl (inklusive systemfejl som manglende tilgængelighed af LTE-netværket), som også "spammede" Slack-kanalen meget, uden at det giver stor gavn.
Den korrekte løsning ville være at håndtere de fleste af disse typer fejl, justere alvoren for dem og først derefter aktivere alarmering.
På denne måde vil kun nye eller vigtige fejl blive sendt til Slack. Der var simpelthen ikke tid nok til sådan et setup givet de stramme deadlines.
autentificering
Det er også værd at nævne, at Chronograf understøtter OAuth og OIDC som godkendelse.
Dette er meget praktisk, da det giver dig mulighed for nemt at vedhæfte det til din server og oprette fuldgyldig SSO.
I vores tilfælde var serveren — den blev brugt til at oprette forbindelse til overvågning, men den samme server blev også brugt til at autentificere scootere og anmodninger til back-end.
"Admin"
Den sidste komponent, som jeg vil beskrive, er vores selvskrevne "admin panel" i Vue.
Grundlæggende er det bare en selvstændig tjeneste, der viser scooteroplysninger fra vores egne databaser, mikrotjenester og metriske data fra InfluxDB samtidigt.
Derudover blev mange administrative funktioner flyttet dertil, såsom en nødgenstart eller fjernåbning af en lås for supportteamet.
Der var også kort. Jeg har allerede nævnt, at vi startede med Grafana i stedet for Chronograf - fordi til Grafana er kort tilgængelige i form af plugins, hvorpå vi kunne se koordinaterne for scootere. Desværre er mulighederne for kort-widgets til Grafana meget begrænsede, og som følge heraf var det meget nemmere at skrive din egen webapplikation med kort på få dage, for ikke kun at se koordinaterne i øjeblikket, men også vise ruten taget af scooteren, kunne filtrere data på kort osv. (al den funktionalitet, som vi ikke kunne konfigurere i et simpelt dashboard).
En af de allerede nævnte fordele ved Influx er muligheden for nemt at oprette dine egne metrics.
Dette gør det muligt at bruge det til en lang række scenarier.
Vi forsøgte at registrere alle nyttige oplysninger der: batteriopladning, låsestatus, sensorydeevne, bluetooth, GPS og mange andre sundhedstjek.
Vi viste alt dette på adminpanelet.
Selvfølgelig var det vigtigste kriterium for os scooterens driftstilstand - faktisk tjekker Influx dette selv og viser det med "grønt lys" i sektionen Nodes.
Dette gøres af funktionen — vi brugte det til at forstå ydeevnen af vores boks og sende de samme advarsler til Slack.
Forresten opkaldte vi løbehjulene efter navnene på karakterer fra The Simpsons - det var så praktisk at skelne dem fra hinanden
Og generelt var det sjovere på denne måde. Sætninger som "Guys, Smithers er død!" blev konstant hørt.
Streng-metrics
Det er vigtigt, at InfluxDB giver dig mulighed for at gemme ikke kun numeriske værdier, som det er tilfældet med Victoria Metrics.
Det ser ud til, at dette ikke er så vigtigt - trods alt, bortset fra logfiler, kan enhver metrik gemmes i form af tal (bare tilføj mapping for kendte tilstande - en slags enum)?
I vores tilfælde var der mindst ét scenarie, hvor strengmetrikker var meget nyttige.
Det skete bare sådan, at leverandøren af vores "smart opladere" var en tredjepart, vi havde ingen kontrol over udviklingsprocessen og de oplysninger, som disse opladere kunne levere.
Som et resultat var opladnings-API'en langt fra ideel, men hovedproblemet var, at vi ikke altid kunne forstå deres tilstand.
Det var her, Influx kom til undsætning. Vi skrev simpelthen den strengstatus, der kom til os, i InfluxDB-databasefeltet uden ændringer.
I nogen tid kom kun værdier som "online" og "offline" der, baseret på hvilke oplysninger der blev vist i vores adminpanel, og meddelelser blev sendt til Slack. Men på et tidspunkt begyndte værdier som "afbrudt" også at dukke op der.
Som det viste sig senere, blev denne status sendt én gang efter et tab af forbindelsen, hvis opladeren ikke kunne etablere forbindelse til serveren efter et vist antal forsøg.
Således, hvis vi kun brugte et fast sæt værdier, vil vi muligvis ikke se disse ændringer i firmwaren på det rigtige tidspunkt.
Og generelt giver strengmetrikker meget flere muligheder for brug; du kan registrere stort set enhver information i dem. Selvom du selvfølgelig også skal bruge dette værktøj forsigtigt.
Ud over de sædvanlige målinger registrerede vi også GPS-placeringsoplysninger i InfluxDB. Dette var utrolig nyttigt til at overvåge placeringen af scootere i vores admin panel.
Faktisk vidste vi altid, hvor og hvilken scooter var i det øjeblik, vi havde brug for.
Dette var meget nyttigt for os, da vi ledte efter en scooter (se konklusionerne i slutningen).
Infrastrukturovervågning
Udover selve løbehjulene havde vi også brug for at overvåge hele vores (temmelig omfattende) infrastruktur.
En meget generel arkitektur så nogenlunde sådan ud:
Hvis vi fremhæver en ren overvågningsstack, ser den sådan ud:
Det vi gerne vil tjekke i skyen er:
- Database
- Nøglekappe
- Mikrotjenester
Da alle vores cloud-tjenester er placeret i Kubernetes, ville det være rart at indsamle oplysninger om deres tilstand.
Heldigvis kan Telegraf out of the box indsamle et stort antal målinger om tilstanden af Kubernetes-klyngen, og Chronograf tilbyder straks smukke dashboards til dette.
Vi overvågede hovedsageligt ydeevnen af pods og hukommelsesforbrug. I tilfælde af et fald, advarer i Slack.
Der er to måder at spore pods i Kubernetes: DaemonSet og Sidecar.
Begge metoder er beskrevet i detaljer .
Vi brugte Telegraf Sidecar og, udover metrikker, indsamlede vi pod-logs.
I vores tilfælde var vi nødt til at pille ved kævlerne. På trods af at Telegraf kan trække logfiler fra Docker API, ønskede vi at have en ensartet samling af logfiler med vores slutenheder og konfigureret syslog til containere til dette. Måske var denne løsning ikke smuk, men der var ingen klager over dens arbejde, og logfilerne blev vist godt i Chronograf.
Monitor overvågning???
I sidste ende opstod det ældgamle spørgsmål om overvågning af overvågningssystemer, men heldigvis, eller desværre, havde vi simpelthen ikke tid nok til dette.
Selvom Telegraf nemt kan sende sine egne metrics eller indsamle metrics fra InfluxDB-databasen for at sende enten til den samme Influx eller et andet sted.
Fund
Hvilke konklusioner trak vi ud fra resultaterne af pilotprojektet?
Hvordan kan du lave overvågning?
Først og fremmest levede TICK-stakken fuldt ud op til vores forventninger og gav os endnu flere muligheder, end vi oprindeligt forventede.
Al den funktionalitet, vi havde brug for, var til stede. Alt, hvad vi gjorde med det, fungerede uden problemer.
Ydelse
Hovedproblemet med TICK-stakken i den gratis version er manglen på skaleringsmuligheder. Dette var ikke et problem for os.
Vi indsamlede ikke nøjagtige lastdata/tal, men vi indsamlede data fra omkring 30 scootere ad gangen.
Hver af dem indsamlede mere end tre dusin metrics. Samtidig blev logfiler fra enhederne indsamlet. Dataindsamling og afsendelse fandt sted hvert 10. sekund.
Det er vigtigt at bemærke, at efter halvanden uges pilotforløb, hvor hovedparten af "barndomsproblemerne" var rettet og de vigtigste problemer allerede var løst, var vi nødt til at reducere hyppigheden af at sende data til serveren for at 30 sekunder. Dette blev nødvendigt, fordi trafikken på vores LTE SIM-kort hurtigt begyndte at forsvinde.
Størstedelen af trafikken blev forbrugt af logfiler; selve metrikken, selv med et 10-sekunders interval, spildte det praktisk talt ikke.
Som et resultat deaktiverede vi efter nogen tid fuldstændig indsamling af logfiler på enheder, da specifikke problemer allerede var indlysende, selv uden konstant indsamling.
I nogle tilfælde, hvis det stadig var nødvendigt at se logfilerne, oprettede vi blot forbindelse via WireGuard via VPN.
Jeg vil også tilføje, at hvert separat miljø var adskilt fra hinanden, og belastningen beskrevet ovenfor var kun relevant for produktionsmiljøet.
I udviklingsmiljøet rejste vi en separat InfluxDB-instans, der fortsatte med at indsamle data hvert 10. sekund, og vi stødte ikke på nogen ydeevneproblemer.
TICK - ideel til små til mellemstore projekter
Baseret på denne information vil jeg konkludere, at TICK-stakken er ideel til relativt små projekter eller projekter, der absolut ikke forventer nogen HighLoad.
Hvis du ikke har tusindvis af pods eller hundredvis af maskiner, vil selv en InfluxDB-instans klare belastningen fint.
I nogle tilfælde kan du være tilfreds med Influx Relay som en primitiv High Availability-løsning.
Og selvfølgelig er der ingen, der forhindrer dig i at opsætte "vertikal" skalering og simpelthen allokere forskellige servere til forskellige typer metrics.
Hvis du ikke er sikker på den forventede belastning på overvågningstjenesterne, eller du med garanti har/vil have en meget "tung" arkitektur, vil jeg ikke anbefale at bruge den gratis version af TICK-stakken.
Selvfølgelig ville en simpel løsning være at købe - men her kan jeg ikke udtale mig på en eller anden måde, da jeg ikke selv er fortrolig med finesserne. Udover at det er meget dyrt og absolut ikke egnet til små virksomheder.
I dette tilfælde vil jeg i dag anbefale, at man ser hen imod at indsamle metrics gennem Victoria Metrics og logfiler ved hjælp af Loki.
Sandt nok vil jeg igen tage forbehold for, at Loki/Grafana er meget mindre bekvemme (på grund af deres større alsidighed) end den færdiglavede TICK, men de er gratis.
Det er vigtigt: alle oplysningerne beskrevet her er relevante for version Influx 1.8, i øjeblikket er Influx 2.0 ved at blive frigivet.
Selvom jeg ikke har haft mulighed for at prøve det under kampforhold, og det er svært at drage konklusioner om forbedringer, er grænsefladen bestemt blevet endnu bedre, arkitekturen er blevet forenklet (uden kapacitor og kronograf),
skabeloner dukkede op ("killer feature" - ). Men desværre har version 2 i øjeblikket ikke det vigtigste, som vi valgte den første version til - der er ingen logsamling.
Denne funktionalitet vil også dukke op i Influx 2.0, men vi kunne ikke finde nogen deadlines, heller ikke omtrentlige.
Sådan laver du ikke IoT-platforme (nu)
I sidste ende, efter at have lanceret piloten, samlede vi selv vores egen fuldgyldige IoT-stak, i mangel af et alternativ, der passer til vores standarder.
Men for nylig er den tilgængelig i betaversion - det er ærgerligt, hun ikke var der, da vi begyndte at lave projektet.
Vi er fuldt ud tilfredse med slutresultatet og platformen baseret på Ansible + TICK + WireGuard, som vi selv har samlet. Men i dag vil jeg anbefale at kigge nærmere på Balena, før du selv forsøger at bygge din egen IoT-platform.
For i sidste ende kan den det meste af det, vi gjorde, og OpenBalena er gratis og open source.
Den ved allerede, hvordan man ikke kun sender opdateringer, men også en VPN er allerede indbygget og skræddersyet til brug i et IoT-miljø.
Og for nylig udgav de endda deres , som nemt forbindes med deres økosystem.
Hej, hvad med den forsvundne scooter?
Så scooteren, "Ralph", forsvandt sporløst.
Vi løb straks for at se på kortet i vores "admin panel", med GPS-metrics-data fra InfluxDB.
Takket være overvågningsdata kunne vi nemt konstatere, at scooteren forlod parkeringspladsen omkring kl. 21 sidste dag, kørte omkring en halv time til et område og var parkeret indtil kl. 00 ved siden af et tysk hus.
Efter kl. 5 blev der ikke modtaget nogen overvågningsdata - det betød enten, at det ekstra batteri var helt afladet, eller at angriberen endelig fandt ud af, hvordan man fjerner den smarte hardware fra scooteren.
På trods af dette blev politiet stadig tilkaldt til adressen, hvor scooteren befandt sig. Scooteren var der ikke.
Ejeren af huset var dog også overrasket over dette, da han faktisk kørte denne scooter hjem fra kontoret i går aftes.
Det viste sig, at en af supportmedarbejderne ankom tidligt om morgenen og hentede scooteren, idet de så, at dens ekstra batteri var helt afladet og tog den (til fods) til parkeringspladsen. Og det ekstra batteri fejlede på grund af fugt.
Vi stjal scooteren fra os selv. Jeg ved i øvrigt ikke hvordan og hvem der så løste problemet med politisagen, men overvågningen fungerede perfekt...
Kilde: www.habr.com