For et år siden lanserte vi en pilotversjon av et promoteringsprosjekt for .
Opprinnelig ble prosjektet kalt Road-To-Barcelona, senere ble det Road-To-Berlin (derav R2B i skjermbildene), og til slutt ble det kalt xRide.
Hovedideen med prosjektet var denne: i stedet for å ha en sentralisert bil- eller scooterutleietjeneste (vi snakker om scootere aka elektriske motorsykler, ikke sparkesykler/scootere) ønsket vi å lage en plattform for desentralisert utleie. Om vanskene vi møtte .
Opprinnelig fokuserte prosjektet på biler, men på grunn av tidsfrister, ekstremt lang kommunikasjon med produsenter og et stort antall sikkerhetsbegrensninger, ble elektriske scootere valgt for piloten.
Brukeren installerte en iOS- eller Android-applikasjon på telefonen, nærmet seg scooteren han likte, hvoretter telefonen og scooteren etablerte en peer-to-peer-forbindelse, ETH ble byttet ut og brukeren kunne starte turen ved å slå på scooteren via telefonen. På slutten av reisen var det også mulig å betale for reisen med Ethereum fra brukerens lommebok på telefonen.
I tillegg til scootere, så brukeren "smartladere" i applikasjonen, ved å besøke hvor brukeren selv kunne bytte gjeldende batteri hvis det var lavt.
Slik så piloten vår ut, som ble lansert i september i fjor i to tyske byer: Bonn og Berlin.
Og så, en dag, i Bonn, tidlig på morgenen, ble supportteamet vårt (plassert på stedet for å holde scootere i stand) varslet: en av scooterne hadde forsvunnet sporløst.
Hvordan finne den og returnere den?
I denne artikkelen vil jeg snakke om dette, men først - om hvordan vi bygde vår egen IoT-plattform og hvordan vi overvåket den.
Hva og hvorfor skal man overvåke: scootere, infrastruktur, ladestasjoner?
Så hva ønsket vi å overvåke i prosjektet vårt?
For det første er dette scooterne selv - elektriske scootere i seg selv er ganske dyre, du kan ikke starte et slikt prosjekt uten å være tilstrekkelig forberedt; hvis mulig, vil du samle så mye informasjon som mulig om scooterne: om deres plassering, ladenivå , etc.
I tillegg vil jeg gjerne overvåke tilstanden til vår egen IT-infrastruktur – databaser, tjenester og alt de trenger for å fungere. Det var også nødvendig å overvåke statusen til "smartladerne", i tilfelle de gikk i stykker eller gikk tomme for fulle batterier.
Sparkesykler
Hva var scooterne våre og hva ville vi vite om dem?
Det første og viktigste er GPS-koordinater, siden vi takket være dem kan forstå hvor de er og hvor de beveger seg.
Neste er batteriladingen, takket være den kan vi fastslå at ladingen av scooterne nærmer seg slutten og sende en juicepresse eller i det minste advare brukeren.
Selvfølgelig er det også nødvendig å sjekke hva som skjer med våre maskinvarekomponenter:
- fungerer bluetooth?
- fungerer selve GPS-modulen?
- Vi hadde også et problem med at GPS-en kunne sende feil koordinater og sette seg fast, og dette kunne kun avgjøres ved ytterligere kontroller på scooteren,
og varsle brukerstøtten så snart som mulig for å løse problemet
- Vi hadde også et problem med at GPS-en kunne sende feil koordinater og sette seg fast, og dette kunne kun avgjøres ved ytterligere kontroller på scooteren,
Og til slutt: kontroller av programvaren, starter med OS og prosessor, nettverk og diskbelastning, og slutter med kontroller av våre egne moduler som er mer spesifikke for oss (, ).
maskinvare
Hva var vår "jern" del?
Med hensyn til kortest mulig tidsramme og behovet for rask prototyping, valgte vi det enkleste alternativet for implementering og valg av komponenter - Raspberry Pi.
I tillegg til selve Rpi hadde vi et tilpasset brett (som vi selv utviklet og bestilte fra Kina for å fremskynde monteringsprosessen av den endelige løsningen) og et sett med komponenter - et relé (for å slå på/av scooteren), en batteriladeleser, et modem, antenner. Alt dette var kompakt pakket i en spesiell "xRide-boks".
Det skal også bemerkes at hele boksen ble drevet av en ekstra strømbank, som igjen ble drevet av hovedbatteriet til scooteren.
Dette gjorde det mulig å bruke overvåking og slå på scooteren selv etter slutten av turen, siden hovedbatteriet ble slått av umiddelbart etter at tenningsnøkkelen ble vridd til "av"-posisjon.
Docker? Vanlig Linux? og utplassering
La oss gå tilbake til overvåking, så bringebær - hva har vi?
En av de første tingene vi ønsket å bruke for å fremskynde prosessen med å distribuere, oppdatere og levere komponenter til fysiske enheter, var Docker.
Dessverre ble det raskt klart at Docker på RPi, selv om det fungerer, har mye overhead, spesielt når det gjelder strømforbruk.
Forskjellen ved å bruke det "native" operativsystemet, selv om det ikke var så sterkt, var fortsatt tilstrekkelig for oss til å være på vakt mot muligheten for å miste ladningen for raskt.
Den andre grunnen var et av partnerbibliotekene våre på Node.js (sic!) - den eneste komponenten i systemet som ikke var skrevet i Go/C/C++.
Forfatterne av biblioteket hadde ikke tid til å gi en fungerende versjon på noen av de "morsmålene".
Ikke bare er selve noden ikke den mest elegante løsningen for enheter med lav ytelse, men selve biblioteket var veldig ressurssultent.
Vi innså at selv om vi ønsket det, ville bruken av Docker bli for mye av en overhead for oss. Valget ble tatt til fordel for det opprinnelige operativsystemet og arbeidet direkte under det.
OS
Som et resultat valgte vi igjen det enkleste alternativet som OS og brukte Raspbian (Debian build for Pi).
Vi skriver all programvaren vår i Go, så vi skrev også hovedmaskinvareagentmodulen i systemet vårt i Go.
Det er han som har ansvaret for å jobbe med GPS, Bluetooth, lese av ladningen, slå på sparkesykkelen m.m.
Utplassere
Spørsmålet dukket umiddelbart opp om behovet for å implementere en mekanisme for å levere oppdateringer til enheter (OTA) - både oppdateringer til vår agent/applikasjon selv, og oppdateringer til selve OS/firmware (siden nye versjoner av agenten kan kreve oppdateringer til kjernen) eller systemkomponenter, biblioteker osv.).
Etter en ganske lang analyse av markedet, viste det seg at det finnes ganske mange løsninger for å levere oppdateringer til enheten.
Fra relativt enkle, for det meste oppdaterings-/dobbeltoppstartsorienterte verktøy som swupd/SWUpdate/OSTree til fullverdige plattformer som Mender og Balena.
Først og fremst bestemte vi oss for at vi var interessert i ende-til-ende-løsninger, så valget falt umiddelbart på plattformer.
Selve ble ekskludert på grunn av det faktum at den faktisk bruker den samme Docker inne i balenaEngine.
Men jeg legger merke til at til tross for dette, endte vi opp med å bruke produktet deres konstant for flash-firmware på SD-kort - et enkelt og ekstremt praktisk verktøy for dette.
Derfor falt valget til slutt på . Mender er en komplett plattform for montering, levering og installasjon av fastvare.
Totalt sett ser plattformen bra ut, men det tok oss omtrent en og en halv uke bare å bygge den riktige versjonen av fastvaren vår ved å bruke mender-byggeren.
Og jo mer vi fordypet oss i vanskelighetene ved bruken av den, desto mer ble det klart at for å implementere den fullt ut ville vi trenge mye mer tid enn vi hadde.
Dessverre, våre stramme tidsfrister gjorde at vi ble tvunget til å forlate bruken av Mender og velge en enda enklere.
Ansible
Den enkleste løsningen i vår situasjon var å bruke Ansible. Et par lekebøker var nok til å komme i gang.
Essensen deres var at vi ganske enkelt koblet fra verten (CI-serveren) via ssh til rasbærene våre og distribuerte oppdateringer til dem.
Helt i begynnelsen var alt enkelt - du måtte være på samme nettverk med enhetene, skjenking ble gjort via Wi-Fi.
På kontoret var det rett og slett et dusin prøvebringebær koblet til det samme nettverket, hver enhet hadde en statisk IP-adresse også spesifisert i Ansible Inventory.
Det var Ansible som leverte overvåkingsagenten vår til sluttenheter
3G / LTE
Dessverre kunne denne brukssaken for Ansible bare fungere i utviklingsmodus før vi hadde faktiske scootere.
Fordi scootere, som du forstår, ikke sitter koblet til én Wi-Fi-ruter, og venter konstant på oppdateringer over nettverket.
I virkeligheten kan ikke scootere ha noen forbindelse i det hele tatt annet enn mobil 3G/LTE (og selv da ikke hele tiden).
Dette medfører umiddelbart mange problemer og begrensninger, som lav tilkoblingshastighet og ustabil kommunikasjon.
Men det viktigste er at i et 3G/LTE-nettverk kan vi ikke bare stole på en statisk IP som er tildelt nettverket.
Dette er delvis løst av noen SIM-kortleverandører; det finnes til og med spesielle SIM-kort designet for IoT-enheter med statiske IP-adresser. Men vi hadde ikke tilgang til slike SIM-kort og kunne ikke bruke IP-adresser.
Selvfølgelig var det ideer om å gjøre en form for registrering av IP-adresser aka service discovery et sted som Consul, men slike ideer måtte forlates, siden i våre tester kunne IP-adressen endres for ofte, noe som førte til stor ustabilitet.
Av denne grunn vil den mest praktiske bruken for å levere beregninger ikke være å bruke pull-modellen, der vi ville gå til enheter for de nødvendige metrikkene, men push, levere metrikk fra enheten direkte til serveren
VPN
Som en løsning på dette problemet valgte vi VPN – spesifikt .
Klienter (scootere) ved starten av systemet koblet til VPN-serveren og var i stand til å koble til dem. Denne tunnelen ble brukt til å levere oppdateringer.
I teorien kunne den samme tunnelen brukes til overvåking, men en slik forbindelse var mer komplisert og mindre pålitelig enn enkel push.
Skyressurser
Til slutt er det nødvendig å overvåke skytjenestene og databasene våre, siden vi bruker Kubernetes for dem, ideelt sett slik at distribusjon av overvåking i klyngen er så enkel som mulig. Ideelt sett bruker , siden vi bruker den i de fleste tilfeller for distribusjon. Og, selvfølgelig, for å overvåke skyen må du bruke de samme løsningene som for scooterne selv.
Gitt
Puh, vi ser ut til å ha ordnet beskrivelsen, la oss lage en liste over hva vi trengte til slutt:
- En rask løsning, siden overvåking er nødvendig allerede under utviklingsprosessen
- Volum/mengde – mange beregninger kreves
- Loggsamling er nødvendig
- Pålitelighet – data er avgjørende for å lykkes med lanseringen
- Du kan ikke bruke pull-modellen - du trenger push
- Vi trenger enhetlig overvåking av ikke bare maskinvare, men også sky
Det endelige bildet så omtrent slik ut
Stabelvalg
Så vi sto overfor spørsmålet om å velge en overvåkingsstabel.
Først og fremst var vi på utkikk etter den mest komplette alt-i-ett-løsningen som samtidig skulle dekke alle våre krav, men samtidig være fleksibel nok til å skreddersy bruken til våre behov. Likevel hadde vi mange begrensninger pålagt oss av maskinvare, arkitektur og tidsfrister.
Det finnes et stort utvalg av overvåkingsløsninger, som starter med fullverdige systemer som , eller og avsluttes med ferdige løsninger for flåtestyring.
I utgangspunktet virket sistnevnte som en ideell løsning for oss, men noen hadde ikke full overvåking, andre hadde sterkt begrensede muligheter til gratisversjonene, og andre dekket rett og slett ikke våre "ønsker" eller var ikke fleksible nok til å passe scenariene våre. Noen er rett og slett utdaterte.
Etter å ha analysert en rekke lignende løsninger, kom vi raskt frem til at det ville være enklere og raskere å sette sammen en lignende stabel selv. Ja, det vil være litt mer komplisert enn å distribuere en helt ferdig flåtestyringsplattform, men vi trenger ikke inngå kompromisser.
Nesten sikkert, i all den enorme mengden av løsninger, er det allerede en ferdig en som ville passe oss helt, men i vårt tilfelle var det mye raskere å sette sammen en viss stabel på egen hånd og tilpasse den "for oss selv" i stedet for testing av ferdige produkter.
Med alt dette strevde vi ikke etter å sette sammen en hel overvåkingsplattform selv, men var på utkikk etter de mest funksjonelle "ferdige" stablene, bare med muligheten til å konfigurere dem fleksibelt.
(B)ELK?
Den første løsningen som faktisk ble vurdert var den velkjente ELK-stakken.
Faktisk burde det hete BELK, for det hele starter med Beats -
Selvfølgelig er ELK en av de mest kjente og kraftige løsningene innen overvåking, og enda mer innen innsamling og behandling av logger.
Vi hadde til hensikt at ELK skulle brukes til å samle inn logger og samt langtidslagring av metrikk hentet fra Prometheus.
For visualisering kan du bruke Grafan.
Faktisk kan den nye ELK-stakken samle inn beregninger uavhengig (metricbeat), og Kibana kan også vise dem.
Men likevel vokste ELK i utgangspunktet ut av logger, og så langt har funksjonaliteten til beregningene en rekke alvorlige ulemper:
- Betydelig tregere enn Prometheus
- Integrerer på langt færre steder enn Prometheus
- Det er vanskelig å sette opp varsler for dem
- Beregninger tar opp mye plass
- Å sette opp dashbord med beregninger i Kiban er mye mer komplisert enn i Grafan
Generelt er metrikkene i ELK tunge og ennå ikke like praktiske som i andre løsninger, som det nå finnes mye mer av enn bare Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Selvfølgelig vil jeg veldig gjerne ha en fullverdig alt-i-ett-løsning med en gang, men i tilfellet med metricbeat ble det for mange kompromisser.
Og selve ELK-stakken har en rekke vanskelige øyeblikk:
- Det er tungt, noen ganger til og med veldig tungt hvis du samler inn en ganske stor mengde data
- Du må "vite hvordan du lager mat" det - du må skalere det, men dette er ikke trivielt å gjøre
- Fjernet gratisversjon - gratisversjonen har ikke normal varsling, og på tidspunktet for valg var det ingen autentisering
Jeg må si at nylig har det siste punktet blitt bedre og i tillegg (inkludert autentisering) selve prismodellen begynte å endre seg.
Men på det tidspunktet da vi skulle distribuere denne løsningen, var det ingen varsling i det hele tatt.
Kanskje vi kunne ha prøvd å bygge noe ved hjelp av ElastAlert eller andre fellesskapsløsninger, men vi bestemte oss likevel for å vurdere andre alternativer.
Loke - Grafana - Prometheus
For øyeblikket kan en god løsning være å bygge en overvåkingsstabel utelukkende basert på Prometheus som metrikkleverandør, Loki for logger, og for visualisering kan du bruke samme Grafana.
Dessverre, på tidspunktet for starten av salgspiloten for prosjektet (september-oktober 19), var Loki fortsatt i betaversjon 0.3-0.4, og på tidspunktet for starten av utviklingen kunne den ikke betraktes som en produksjonsløsning i det hele tatt.
Jeg har ennå ikke erfaring med å faktisk bruke Loki i seriøse prosjekter, men jeg kan si at Promtail (en agent for innsamling av tømmerstokker) fungerer utmerket for både bare-metall og pods i kubernetes.
SETT KRYSS
Det kanskje mest verdige (det eneste?) fullfunksjonsalternativet til ELK-stakken kan nå bare kalles TICK-stakken - Telegraf, InfluxDB, Chronograf, Kapacitor.
Jeg vil beskrive alle komponentene nedenfor mer detaljert, men den generelle ideen er denne:
- Telegraf - agent for innsamling av beregninger
- InfluxDB - metrikkdatabase
- Kapacitor - sanntids metrikkprosessor for varsling
- Chronograf - webpanel for visualisering
For InfluxDB, Kapacitor og Chronograf er det offisielle rordiagrammer som vi brukte til å distribuere dem.
Det skal bemerkes at i den siste versjonen av Influx 2.0 (beta) ble Kapacitor og Chronograf en del av InfluxDB og eksisterer ikke lenger hver for seg
telegraf
er et veldig lett middel for å samle inn beregninger på en statsmaskin.
Han kan overvåke en enorm mengde av alt, fra til
server .
Den har en rekke kule fordeler:
- Rask og lett (skrevet i Go)
- Spiser et minimum av ressurser
- Push-beregninger som standard
- Samler inn alle nødvendige beregninger
- Systemmålinger uten noen innstillinger
- Maskinvareberegninger som informasjon fra sensorer
- Det er veldig enkelt å legge til dine egne beregninger
- Mange plugins ut av esken
- Samler logger
Siden push-metrikk var nødvendig for oss, var alle andre fordeler mer enn hyggelige tillegg.
Innsamling av logger av agenten selv er også veldig praktisk, siden det ikke er nødvendig å koble til flere verktøy for logging av logger.
Influx tilbyr den mest praktiske opplevelsen for å jobbe med logger hvis du bruker .
Telegraf er generelt en god agent for å samle inn beregninger, selv om du ikke bruker resten av ICK-stakken.
Mange krysser den med ELK og forskjellige andre tidsseriedatabaser for enkelhets skyld, siden den kan skrive beregninger nesten hvor som helst.
TilstrømningDB
InfluxDB er hovedkjernen i TICK-stakken, nemlig en tidsseriedatabase for metrikk.
I tillegg til beregninger, kan Influx også lagre logger, selv om logger for det i hovedsak bare er de samme beregningene, bare i stedet for de vanlige numeriske indikatorene, utføres hovedfunksjonen av en linje med loggtekst.
InfluxDB er også skrevet i Go og ser ut til å kjøre mye raskere sammenlignet med ELK på vår (ikke den kraftigste) klyngen.
En av de kule fordelene med Influx vil også inkludere en veldig praktisk og rik API for dataspørringer, som vi brukte veldig aktivt.
Ulemper - $$$ eller skalering?
TICK-stakken har bare én ulempe som vi oppdaget - den kjære. Enda mer.
Hva har den betalte versjonen som gratisversjonen ikke har?
Så vidt vi var i stand til å forstå, er den eneste forskjellen mellom den betalte versjonen av TICK-stakken og den gratis skaleringsmulighetene.
Du kan nemlig heve en klynge med høy tilgjengelighet bare i .
Hvis du vil ha fullverdig HA, må du enten betale eller bruke noen krykker. Det finnes et par fellesskapsløsninger – for eksempel ser ut som en kompetent løsning, men det er skrevet at den ikke egner seg for produksjon, samt
- en enkel løsning med datapumping gjennom NATS (det vil også måtte skaleres, men dette kan løses).
Det er synd, men begge ser ut til å være forlatt - det er ingen nye forpliktelser, jeg antar at problemet er den snart forventede utgivelsen av den nye versjonen av Influx 2.0, der mange ting vil være annerledes (det er ingen informasjon om skalering i den ennå).
Offisielt er det en gratisversjon - faktisk er dette en primitiv HA, men bare gjennom balansering,
siden alle data vil bli skrevet til alle InfluxDB-instanser bak lastbalanseren.
Han har noen som potensielle problemer med å overskrive poeng og behovet for å lage grunnlag for beregninger på forhånd
(noe som skjer automatisk under normalt arbeid med InfluxDB).
I tillegg , betyr dette ekstra overhead for dupliserte beregninger (både behandling og lagring) som du kanskje ikke trenger, men det er ingen måte å skille dem fra hverandre.
Victoria Metrics?
Som et resultat, til tross for at vi var helt fornøyd med TICK-stakken i alt annet enn betalt skalering, bestemte vi oss for å se om det fantes noen gratisløsninger som kunne erstatte InfluxDB-databasen, samtidig som vi la de gjenværende T_CK-komponentene.
Det er mange tidsseriedatabaser, men den mest lovende er Victoria Metrics, den har en rekke fordeler:
- Raskt og enkelt, i hvert fall i henhold til resultatene
- Det er en klyngeversjon, som det til og med er gode anmeldelser om nå
- Hun kan skjære
- Støtter InfluxDB-protokollen
Vi hadde ikke til hensikt å bygge en helt tilpasset stack basert på Victoria og hovedhåpet var at vi kunne bruke den som en drop-in erstatning for InfluxDB.
Dessverre er dette ikke mulig, til tross for at InfluxDB-protokollen støttes, fungerer den bare for opptak av beregninger - bare Prometheus API er tilgjengelig "utenfor", noe som betyr at det ikke vil være mulig å sette Chronograf på den.
Dessuten støttes bare numeriske verdier for beregninger (vi brukte strengverdier for egendefinerte beregninger - mer om det i delen ).
Av samme grunn kan selvsagt ikke VM lagre logger slik Influx gjør.
Det skal også bemerkes at på tidspunktet for søk etter den optimale løsningen, var Victoria Metrics ennå ikke så populær, dokumentasjonen var mye mindre og funksjonaliteten var svakere
(Jeg husker ikke en detaljert beskrivelse av klyngeversjonen og skjæringen).
Basevalg
Som et resultat ble det bestemt at vi for piloten fortsatt ville begrense oss til en enkelt InfluxDB-node.
Det var flere hovedgrunner for dette valget:
- Vi likte hele funksjonaliteten til TICK-stakken
- Vi har allerede klart å distribuere det, og det fungerte utmerket
- Fristene var i ferd med å gå ut og det var ikke mye tid igjen til å teste andre alternativer.
- Vi forventet ikke så tung belastning
Vi hadde ikke mange scootere i den første fasen av piloten, og testing under utviklingen avslørte ingen ytelsesproblemer.
Derfor bestemte vi oss for at for dette prosjektet ville en tilstrømningsnode være nok for oss uten behov for skalering (se konklusjoner på slutten).
Vi har bestemt oss for stabelen og basen - nå om de resterende komponentene i TICK-stabelen.
Kapasitor
Kapacitor er en del av TICK-stakken, en tjeneste som kan overvåke metrikker som kommer inn i databasen i sanntid og utføre ulike handlinger basert på regler.
Generelt er det posisjonert som et verktøy for potensiell anomalisporing og maskinlæring (jeg er ikke sikker på at disse funksjonene er etterspurt), men det mest populære tilfellet av bruken er mer vanlig - varsling.
Det var slik vi brukte det for varsler. Vi satte opp Slack-varsler når en bestemt scooter gikk offline, og det samme ble gjort for smarte ladere og viktige infrastrukturkomponenter.
Dette gjorde det mulig å raskt svare på problemer, samt motta varsler om at alt var tilbake til det normale.
Et enkelt eksempel: et ekstra batteri for å drive "boksen" vår har gått i stykker eller av en eller annen grunn har gått tom for strøm; ganske enkelt ved å installere et nytt, bør vi etter en stund motta et varsel om at scooterens funksjonalitet er gjenopprettet.
I Influx 2.0 ble Kapacitor en del av DB
Kronograf
Jeg har sett mange forskjellige UI-løsninger for overvåking, men jeg kan si at når det gjelder funksjonalitet og UX, er det ingenting som kan sammenlignes med Chronograf.
Vi begynte å bruke TICK-stakken, merkelig nok, med Grafan som webgrensesnitt.
Jeg vil ikke beskrive funksjonaliteten; alle kjenner dens brede muligheter for å sette opp hva som helst.
Grafana er imidlertid fortsatt et helt universelt instrument, mens Chronograf hovedsakelig er designet for bruk med Influx.
Og selvfølgelig, takket være dette, har Chronograf råd til mye mer smart eller praktisk funksjonalitet.
Den viktigste fordelen med å jobbe med Chronograf er kanskje at du kan se innsiden av InfluxDB gjennom Explore.
Det ser ut til at Grafana har nesten identisk funksjonalitet, men i realiteten kan det å sette opp et dashbord i Chronograf gjøres med noen få museklikk (samtidig som man ser på visualiseringen der), mens man i Grafana fortsatt før eller siden vil ha å redigere JSON-konfigurasjonen (selvfølgelig lar Chronograf laste opp dine håndkonfigurerte dashas og redigere dem som JSON om nødvendig - men jeg måtte aldri røre dem etter å ha opprettet dem på brukergrensesnittet).
Kibana har mye rikere muligheter for å lage dashbord og kontroller for dem, men brukeropplevelsen for slike operasjoner er veldig kompleks.
Det vil kreve litt god forståelse for å lage et praktisk dashbord. Og selv om funksjonaliteten til Chronograf-dashbord er mindre, er det mye enklere å lage og tilpasse dem.
Selve dashbordene, bortsett fra den hyggelige visuelle stilen, er faktisk ikke forskjellig fra dashbordene i Grafana eller Kibana:
Slik ser spørringsvinduet ut:
Det er viktig å merke seg blant annet at når du kjenner til felttypene i InfluxDB-databasen, kan kronografen i seg selv noen ganger automatisk hjelpe deg med å skrive en spørring eller velge riktig aggregeringsfunksjon som gjennomsnitt.
Og selvfølgelig er Chronograf så praktisk som mulig for visning av logger. Det ser slik ut:
Som standard er Influx-logger skreddersydd for å bruke syslog og derfor har de en viktig parameter - alvorlighetsgrad.
Grafen øverst er spesielt nyttig, på den kan du se feilene som oppstår og fargen viser umiddelbart tydelig om alvorlighetsgraden er høyere.
Et par ganger fanget vi viktige feil på denne måten, vi skulle se loggene for den siste uken og så en rød pigg.
Selvfølgelig ville det ideelt sett vært å sette opp varsler for slike feil, siden vi allerede hadde alt for dette.
Vi skrudde til og med på dette en stund, men i prosessen med å forberede piloten viste det seg at vi fikk ganske mange feil (inkludert systemfeil som manglende tilgjengelighet av LTE-nettverket), som også "spammet" Slack-kanalen mye, uten å forårsake noen problemer, stor fordel.
Den riktige løsningen ville være å håndtere de fleste av disse typene feil, justere alvorlighetsgraden for dem, og først da aktivere varsling.
På denne måten vil bare nye eller viktige feil bli lagt ut på Slack. Det var rett og slett ikke nok tid til et slikt oppsett gitt de stramme tidsfristene.
Autentisering
Det er også verdt å nevne at Chronograf støtter OAuth og OIDC som autentisering.
Dette er veldig praktisk, siden det lar deg enkelt koble den til serveren din og lage fullverdig SSO.
I vårt tilfelle var serveren — den ble brukt til å koble til overvåking, men den samme serveren ble også brukt til å autentisere scootere og forespørsler til back-end.
«Admin»
Den siste komponenten jeg vil beskrive er vårt selvskrevne "adminpanel" i Vue.
I utgangspunktet er det bare en frittstående tjeneste som viser scooterinformasjon fra våre egne databaser, mikrotjenester og metrikkdata fra InfluxDB samtidig.
I tillegg ble mange administrative funksjoner flyttet dit, for eksempel en nødstart eller ekstern åpning av en lås for støtteteamet.
Det var også kart. Jeg har allerede nevnt at vi startet med Grafana i stedet for Chronograf - fordi for Grafana er kart tilgjengelige i form av plugins, der vi kan se koordinatene til scootere. Dessverre er mulighetene til kartwidgets for Grafana svært begrenset, og som et resultat var det mye enklere å skrive din egen nettapplikasjon med kart på noen få dager, for ikke bare å se koordinatene for øyeblikket, men også vise ruten scooteren tar, kunne filtrere dataene på kart osv. (all den funksjonaliteten som vi ikke kunne konfigurere i et enkelt dashbord).
En av de allerede nevnte fordelene med Influx er muligheten til å enkelt lage dine egne beregninger.
Dette gjør at den kan brukes til et stort utvalg scenarier.
Vi prøvde å registrere all nyttig informasjon der: batterilading, låsestatus, sensorytelse, bluetooth, GPS og mange andre helsesjekker.
Vi viste alt dette på administrasjonspanelet.
Selvfølgelig var det viktigste kriteriet for oss driftstilstanden til scooteren - faktisk sjekker Influx dette selv og viser det i Nodes-delen med "grønne lys".
Dette gjøres av funksjonen — vi brukte den til å forstå ytelsen til boksen vår og sende de samme varslene til Slack.
Forresten, vi kalte scooterne etter navnene på karakterene fra The Simpsons - det var så praktisk å skille dem fra hverandre
Og generelt var det morsommere på denne måten. Fraser som «Gutter, Smithers er død!» ble stadig hørt.
Strengberegninger
Det er viktig at InfluxDB lar deg lagre ikke bare numeriske verdier, slik tilfellet er med Victoria Metrics.
Det ser ut til at dette ikke er så viktig - tross alt, bortsett fra logger, kan alle beregninger lagres i form av tall (bare legg til kartlegging for kjente tilstander - en slags enum)?
I vårt tilfelle var det minst ett scenario der strengberegninger var svært nyttige.
Det skjedde at leverandøren av våre "smartladere" var en tredjepart, vi hadde ingen kontroll over utviklingsprosessen og informasjonen som disse laderne kunne levere.
Som et resultat var lade-API-en langt fra ideell, men hovedproblemet var at vi ikke alltid kunne forstå tilstanden deres.
Det var her Influx kom til unnsetning. Vi skrev ganske enkelt strengstatusen som kom til oss i InfluxDB-databasefeltet uten endringer.
I noen tid kom bare verdier som "online" og "offline" dit, basert på hvilken informasjon som ble vist i administrasjonspanelet vårt, og varsler ble sendt til Slack. Men på et tidspunkt begynte også verdier som "frakoblet" å dukke opp der.
Som det viste seg senere, ble denne statusen sendt én gang etter tap av forbindelse, hvis laderen ikke kunne opprette forbindelse med serveren etter et visst antall forsøk.
Derfor, hvis vi bare brukte et fast sett med verdier, vil vi kanskje ikke se disse endringene i fastvaren til rett tid.
Og generelt gir strengberegninger mye flere muligheter for bruk; du kan registrere praktisk talt all informasjon i dem. Selv om du selvfølgelig også må bruke dette verktøyet forsiktig.
I tillegg til de vanlige beregningene, registrerte vi også GPS-posisjonsinformasjon i InfluxDB. Dette var utrolig nyttig for å overvåke plasseringen av scootere i administrasjonspanelet vårt.
Faktisk visste vi alltid hvor og hvilken scooter var i øyeblikket vi trengte.
Dette var veldig nyttig for oss når vi var på utkikk etter en scooter (se konklusjoner på slutten).
Infrastrukturovervåking
I tillegg til selve scooterne, trengte vi også å overvåke hele vår (ganske omfattende) infrastruktur.
En veldig generell arkitektur så omtrent slik ut:
Hvis vi fremhever en ren overvåkingsstabel, ser den slik ut:
Det vi ønsker å sjekke i skyen er:
- databaser
- Nøkkelkappe
- Mikrotjenester
Siden alle våre skytjenester er lokalisert i Kubernetes, ville det være fint å samle informasjon om tilstanden.
Heldigvis kan Telegraf ut av esken samle et stort antall beregninger om tilstanden til Kubernetes-klyngen, og Chronograf tilbyr umiddelbart vakre dashbord for dette.
Vi overvåket hovedsakelig ytelsen til podene og minneforbruk. Ved fall, varsler i Slack.
Det er to måter å spore pods i Kubernetes: DaemonSet og Sidecar.
Begge metodene er beskrevet i detalj .
Vi brukte Telegraf Sidecar og, i tillegg til beregninger, samlet vi podlogger.
I vårt tilfelle måtte vi tukle med tømmerstokkene. Til tross for at Telegraf kan trekke logger fra Docker API, ønsket vi å ha en enhetlig samling av logger med våre sluttenheter og konfigurert syslog for containere for dette. Kanskje denne løsningen ikke var vakker, men det var ingen klager på arbeidet, og loggene ble vist godt i Chronograf.
Overvåke overvåking???
Til slutt dukket det eldgamle spørsmålet om overvåking av overvåkingssystemer opp, men heldigvis, eller dessverre, hadde vi rett og slett ikke nok tid til dette.
Selv om Telegraf enkelt kan sende sine egne beregninger eller samle inn beregninger fra InfluxDB-databasen for å sende enten til samme Influx eller et annet sted.
Funn
Hvilke konklusjoner trakk vi fra resultatene av piloten?
Hvordan kan du overvåke?
For det første oppfylte TICK-stabelen fullt ut forventningene våre og ga oss enda flere muligheter enn det vi først forventet.
All funksjonaliteten vi trengte var til stede. Alt vi gjorde med den fungerte uten problemer.
Производительность
Hovedproblemet med TICK-stakken i gratisversjonen er mangelen på skaleringsmuligheter. Dette var ikke et problem for oss.
Vi samlet ikke inn eksakte lastdata/tall, men vi samlet inn data fra ca 30 scootere om gangen.
Hver av dem samlet mer enn tre dusin beregninger. Samtidig ble logger fra enhetene samlet inn. Datainnsamling og sending skjedde hvert 10. sekund.
Det er viktig å merke seg at etter halvannen uke av piloten, da mesteparten av "barndomssårene" ble korrigert og de viktigste problemene allerede var løst, måtte vi redusere frekvensen av å sende data til serveren for å 30 sekunder. Dette ble nødvendig fordi trafikken på våre LTE SIM-kort begynte å forsvinne raskt.
Mesteparten av trafikken ble konsumert av logger; selve metrikkene, selv med et intervall på 10 sekunder, kastet praktisk talt ikke bort det.
Som et resultat deaktiverte vi etter en tid fullstendig innsamling av logger på enheter, siden spesifikke problemer allerede var åpenbare selv uten konstant innsamling.
I noen tilfeller, hvis visning av loggene fortsatt var nødvendig, koblet vi ganske enkelt til via WireGuard via VPN.
Jeg vil også legge til at hvert separat miljø var skilt fra hverandre, og belastningen beskrevet ovenfor var kun relevant for produksjonsmiljøet.
I utviklingsmiljøet tok vi opp en egen InfluxDB-instans som fortsatte å samle inn data hvert 10. sekund, og vi fikk ingen ytelsesproblemer.
TICK - ideell for små til mellomstore prosjekter
Basert på denne informasjonen vil jeg konkludere med at TICK-stakken er ideell for relativt små prosjekter eller prosjekter som definitivt ikke forventer noen HighLoad.
Hvis du ikke har tusenvis av pods eller hundrevis av maskiner, vil selv én InfluxDB-forekomst håndtere belastningen helt fint.
I noen tilfeller kan du være fornøyd med Influx Relay som en primitiv High Availability-løsning.
Og selvfølgelig er det ingen som hindrer deg i å sette opp "vertikal" skalering og ganske enkelt tildele forskjellige servere for forskjellige typer beregninger.
Hvis du ikke er sikker på forventet belastning på overvåkingstjenestene, eller du garantert har/vil ha en veldig "tung" arkitektur, vil jeg ikke anbefale å bruke gratisversjonen av TICK-stakken.
Selvfølgelig vil en enkel løsning være å kjøpe - men her kan jeg ikke kommentere på en eller annen måte, siden jeg selv ikke er kjent med finessene. Foruten det faktum at det er veldig dyrt og definitivt ikke egnet for små selskaper.
I dette tilfellet, i dag, vil jeg anbefale å se mot å samle inn beregninger gjennom Victoria Metrics og logger ved å bruke Loki.
Riktignok vil jeg igjen ta forbehold om at Loki/Grafana er mye mindre praktiske (på grunn av deres større allsidighet) enn den ferdiglagde TICK, men de er gratis.
Det er viktig: all informasjonen som er beskrevet her er relevant for versjon Influx 1.8, for øyeblikket er Influx 2.0 i ferd med å bli utgitt.
Selv om jeg ikke har hatt en sjanse til å prøve det i kampforhold og det er vanskelig å trekke konklusjoner om forbedringer, har grensesnittet definitivt blitt enda bedre, arkitekturen har blitt forenklet (uten kapasitor og kronograf),
maler dukket opp ("killer feature" - ). Men dessverre, for øyeblikket, har ikke versjon 2 nøkkelen som vi valgte den første versjonen for - det er ingen loggsamling.
Denne funksjonaliteten vil også vises i Influx 2.0, men vi kunne ikke finne noen tidsfrister, heller ikke omtrentlige.
Hvordan ikke lage IoT-plattformer (nå)
Til slutt, etter å ha lansert piloten, satte vi selv sammen vår egen fullverdige IoT-stabel, i fravær av et alternativ som passer etter våre standarder.
Imidlertid er den nylig tilgjengelig i betaversjon – Det er synd at hun ikke var der da vi begynte å lage prosjektet.
Vi er helt fornøyd med sluttresultatet og plattformen basert på Ansible + TICK + WireGuard som vi monterte selv. Men i dag vil jeg anbefale å se nærmere på Balena før du prøver å bygge din egen IoT-plattform selv.
For til syvende og sist kan den gjøre det meste av det vi gjorde, og OpenBalena er gratis og åpen kildekode.
Den vet allerede hvordan den ikke bare skal sende oppdateringer, men også en VPN er allerede innebygd og skreddersydd for bruk i et IoT-miljø.
Og nylig ga de til og med ut sine , som enkelt kobles til deres økosystem.
Hei, hva med den savnede scooteren?
Så scooteren, "Ralph", forsvant sporløst.
Vi løp umiddelbart for å se på kartet i "admin-panelet", med GPS-data fra InfluxDB.
Takket være overvåkingsdata fant vi enkelt ut at scooteren forlot parkeringsplassen rundt kl. 21 siste dag, kjørte omtrent en halvtime til et område og var parkert til kl. 00 ved siden av et tysk hus.
Etter klokken 5 ble ingen overvåkingsdata mottatt - dette betydde enten at tilleggsbatteriet var helt utladet, eller at angriperen endelig fant ut hvordan han skulle fjerne den smarte maskinvaren fra scooteren.
Til tross for dette ble politiet fortsatt tilkalt til adressen hvor scooteren befant seg. Scooteren var ikke der.
Eieren av huset ble imidlertid også overrasket over dette, siden han faktisk kjørte denne scooteren hjem fra kontoret i går kveld.
Det viste seg at en av støttemedarbeiderne kom tidlig om morgenen og hentet scooteren, da han så at ekstrabatteriet var helt utladet og tok den (til fots) til parkeringsplassen. Og tilleggsbatteriet sviktet på grunn av fuktighet.
Vi stjal scooteren fra oss selv. Forresten, jeg vet ikke hvordan og hvem som da løste problemet med politisaken, men overvåkingen fungerte perfekt...
Kilde: www.habr.com