Vuosi sitten käynnistimme pilottiversion promootioprojektista .
Aluksi projektin nimi oli Road-To-Barcelona, myöhemmin siitä tuli Road-To-Berlin (siis R2B kuvakaappauksissa), ja lopulta sen nimi oli xRide.
Projektin pääidea oli tämä: keskitetyn auton- tai skootterivuokrauspalvelun (puhumme skoottereista eli sähkömoottoripyöristä, ei potkulaudoista/skoottereista) sijasta halusimme tehdä alustan hajautettuun vuokraukseen. Kohtaamiamme vaikeuksista .
Aluksi projekti keskittyi autoihin, mutta määräaikojen, erittäin pitkän yhteydenpidon valmistajien kanssa ja valtavan määrän turvallisuusrajoitusten vuoksi pilottiin valittiin sähköskootterit.
Käyttäjä asensi puhelimeen iOS- tai Android-sovelluksen, lähestyi haluamaansa skootteria, minkä jälkeen puhelin ja skootteri muodostivat vertaisyhteyden, ETH vaihdettiin ja käyttäjä saattoi aloittaa matkan käynnistämällä skootterin puhelin. Matkan päätteeksi matkan voitiin maksaa myös Ethereumilla puhelimen lompakosta.
Skootterien lisäksi käyttäjä näki sovelluksessa älykkäitä latureita käymällä, jonka käyttäjä voi muuttaa nykyisen akun itse, jos se oli alhainen.
Tältä näytti yleisesti pilottimme, joka käynnistettiin viime vuoden syyskuussa kahdessa Saksan kaupungissa: Bonnissa ja Berliinissä.
Ja sitten eräänä päivänä Bonnissa varhain aamulla tukitiimimme (joka sijaitsi paikan päällä pitämään skootterit toimintakunnossa) sai hälytyksen: yksi skoottereista oli kadonnut jälkiä jättämättä.
Miten löytää ja palauttaa?
Tässä artikkelissa puhun tästä, mutta ensin - kuinka rakensimme oman IoT-alustamme ja kuinka valvoimme sitä.
Mitä ja miksi seurata: skootterit, infrastruktuuri, latausasemat?
Joten mitä halusimme seurata projektissamme?
Ensinnäkin nämä ovat itse skootterit - itse sähköskootterit ovat melko kalliita, et voi käynnistää tällaista projektia ilman riittävää valmistautumista; jos mahdollista, haluat kerätä mahdollisimman paljon tietoa skoottereista: niiden sijainnista, lataustasosta , jne.
Lisäksi haluan seurata oman IT-infrastruktuurimme tilaa - tietokannat, palvelut ja kaikki, mitä ne tarvitsevat toimiakseen. Myös "älylatureiden" tilaa oli seurattava, mikäli ne hajoavat tai loppuivat täyteen akut.
Skootterit
Mitkä olivat skootterimme ja mitä halusimme tietää niistä?
Ensimmäinen ja tärkein asia on GPS-koordinaatit, koska niiden ansiosta ymmärrämme missä ne ovat ja missä ne liikkuvat.
Seuraavana on akun lataus, jonka ansiosta voimme todeta, että skootterien lataus on loppumassa ja lähettää mehupuristimen tai ainakin varoittaa käyttäjää.
Tietenkin on myös tarpeen tarkistaa, mitä laitteistokomponenttiemme tapahtuu:
- toimiiko bluetooth?
- toimiiko itse gps-moduuli?
- Meillä oli myös ongelma, että GPS saattoi lähettää vääriä koordinaatteja ja juuttua, ja tämä saatiin selville vain skootterin lisätarkastuksilla,
ja ota yhteyttä tukeen mahdollisimman pian ongelman ratkaisemiseksi
- Meillä oli myös ongelma, että GPS saattoi lähettää vääriä koordinaatteja ja juuttua, ja tämä saatiin selville vain skootterin lisätarkastuksilla,
Ja lopuksi: ohjelmistojen tarkistukset alkaen käyttöjärjestelmästä ja prosessorista, verkko- ja levykuormituksesta, päättyen omien, meille erityisempien moduulien tarkastuksiin (, ).
Tarvikkeet
Mikä oli meidän "rautaosamme"?
Ottaen huomioon mahdollisimman lyhyen aikakehyksen ja nopean prototyyppien valmistuksen, valitsimme helpoimman vaihtoehdon toteuttamiseen ja komponenttien valintaan - Raspberry Pi.
Itse Rpi:n lisäksi meillä oli räätälöity kortti (jonka itse kehitimme ja tilasimme Kiinasta nopeuttamaan lopullisen ratkaisun kokoonpanoprosessia) ja joukko komponentteja - rele (skootterin kytkemiseen päälle/pois), akkulatauslukija, modeemi, antennit. Kaikki tämä oli pakattu tiiviisti erityiseen "xRide boxiin".
On myös huomattava, että koko laatikko sai virtansa lisävirtapankista, joka puolestaan sai virtaa skootterin pääakusta.
Tämä mahdollisti skootterin valvonnan ja käynnistämisen myös matkan päätyttyä, koska pääakku sammutettiin heti virta-avaimen kääntämisen jälkeen "pois"-asentoon.
Satamatyöläinen? Pelkkä Linux? ja käyttöönotto
Palataan seurantaan, joten vadelma - mitä meillä on?
Yksi ensimmäisistä asioista, jota halusimme käyttää nopeuttaaksemme komponenttien käyttöönottoa, päivittämistä ja toimittamista fyysisiin laitteisiin, oli Docker.
Valitettavasti kävi nopeasti selväksi, että RPi:n Dockerilla, vaikka se toimii, on paljon yleiskustannuksia, etenkin virrankulutuksen suhteen.
Ero "alkuperäisessä" käyttöjärjestelmässä, vaikkakaan ei niin voimakas, oli silti riittävä, jotta voimme olla varovaisia mahdollisuudesta menettää lataus liian nopeasti.
Toinen syy oli yksi kumppanikirjastoistamme Node.js:ssä (sic!) - järjestelmän ainoassa komponentissa, jota ei kirjoitettu Go/C/C++:ssa.
Kirjaston tekijöillä ei ollut aikaa tarjota toimivaa versiota millään ”äidinkielellä”.
Sen lisäksi, että solmu itsessään ei ole kaikkein tyylikkäin ratkaisu heikkotehoisille laitteille, itse kirjasto oli erittäin resursseja nälkäinen.
Ymmärsimme, että vaikka haluaisimmekin, Dockerin käyttäminen olisi meille liikaa. Valinta tehtiin alkuperäisen käyttöjärjestelmän hyväksi ja suoraan sen alla.
OS
Tämän seurauksena valitsimme jälleen yksinkertaisimman vaihtoehdon käyttöjärjestelmäksi ja käytimme Raspbiania (Debian build for Pi).
Kirjoitamme kaikki ohjelmistomme Go:lla, joten kirjoitimme myös päälaitteistoagenttimoduulin järjestelmäämme Go:lla.
Hän on vastuussa GPS:n, Bluetoothin kanssa työskentelystä, latauksen lukemisesta, skootterin käynnistämisestä jne.
Ota käyttöön
Välittömästi heräsi kysymys tarpeesta ottaa käyttöön mekanismi päivitysten toimittamiseksi laitteisiin (OTA) - sekä päivitykset itse agenttiimme/sovellukseemme että itse käyttöjärjestelmän/laiteohjelmiston päivitykset (koska agentin uudet versiot saattavat vaatia päivityksiä ytimeen tai järjestelmäkomponentit, kirjastot jne.).
Melko pitkän markkina-analyysin jälkeen kävi ilmi, että ratkaisuja päivitysten toimittamiseen laitteeseen on olemassa melko paljon.
Suhteellisen yksinkertaisista, enimmäkseen päivitys-/kaksoiskäynnistyssuuntautuneista apuohjelmista, kuten swupd/SWUpdate/OSTree, täysimittaisiin alustoihin, kuten Mender ja Balena.
Ensinnäkin päätimme, että olemme kiinnostuneita päästä päähän -ratkaisuista, joten valinta putosi välittömästi alustoihin.
Hyvin jätettiin pois, koska se itse asiassa käyttää samaa Dockeria balenaEnginessä.
Mutta huomaan, että tästä huolimatta päädyimme jatkuvasti käyttämään heidän tuotettaan flash-laiteohjelmistolle SD-korteilla - yksinkertainen ja erittäin kätevä apuohjelma tähän.
Siksi valinta kaatui lopulta . Mender on täydellinen alusta laiteohjelmiston kokoamiseen, toimittamiseen ja asentamiseen.
Kaiken kaikkiaan alusta näyttää hyvältä, mutta meillä kesti noin puolitoista viikkoa vain rakentaa oikea versio laiteohjelmistostamme käyttämällä mender builder -ohjelmaa.
Ja mitä enemmän upposimme sen käytön monimutkaisuuteen, sitä selvemmäksi kävi, että sen täysimääräinen käyttöönotto tarvitsisi paljon enemmän aikaa kuin meillä oli.
Valitettavasti tiukat määräaikamme johtivat siihen, että jouduimme luopumaan Menderin käytöstä ja valitsemaan vielä yksinkertaisemman.
Ansible
Yksinkertaisin ratkaisu tilanteessamme oli käyttää Ansiblea. Pari pelikirjaa riitti alkuun.
Heidän olemuksensa oli, että muodostimme yksinkertaisesti yhteyden isännästä (CI-palvelimesta) ssh:n kautta vadelmiimme ja jakoimme päivitykset niille.
Heti alussa kaikki oli yksinkertaista - piti olla samassa verkossa laitteiden kanssa, kaataminen tapahtui Wi-Fi:n kautta.
Toimistossa oli yksinkertaisesti kymmenkunta testivadelmaa kytkettynä samaan verkkoon, jokaisella laitteella oli staattinen IP-osoite myös Ansible Inventoryssa.
Ansible toimitti valvonta-agenttimme loppulaitteisiin
3G / LTE
Valitettavasti tämä Ansible -käyttötapaus voisi toimia vain kehitystilassa ennen kuin meillä oli todellisia skoottereita.
Koska skootterit, kuten ymmärrät, eivät ole kytkettynä yhteen Wi-Fi-reitittimeen odottaen jatkuvasti päivityksiä verkon kautta.
Todellisuudessa skootterilla ei voi olla mitään muuta yhteyttä kuin mobiili 3G/LTE (eikä silloinkaan koko ajan).
Tämä asettaa välittömästi monia ongelmia ja rajoituksia, kuten alhainen yhteysnopeus ja epävakaa viestintä.
Mutta tärkeintä on, että 3G/LTE-verkossa emme voi vain luottaa verkolle määrättyyn staattiseen IP-osoitteeseen.
Tämä on osittain ratkaistu joidenkin SIM-korttien tarjoajien toimesta; olemassa on jopa erityisiä SIM-kortteja, jotka on suunniteltu IoT-laitteille, joilla on staattinen IP-osoite. Mutta meillä ei ollut pääsyä tällaisiin SIM-kortteihin, emmekä voineet käyttää IP-osoitteita.
Tietysti oli ideoita tehdä jonkinlainen IP-osoitteiden rekisteröinti eli service discovery jonnekin Consulin tapaan, mutta sellaisista ajatuksista jouduttiin luopumaan, koska testeissämme IP-osoite saattoi vaihtua liian usein, mikä johti suureen epävakauteen.
Tästä syystä kätevin käyttö metriikan toimittamiseen ei olisi pull-mallin käyttö, jossa menisimme laitteille tarvittavia mittareita varten, vaan push, toimittaen mittarit laitteesta suoraan palvelimelle.
VPN
Ratkaisuksi tähän ongelmaan valitsimme VPN - erityisesti .
Asiakkaat (skootterit) järjestelmän alussa liittyivät VPN-palvelimeen ja pystyivät muodostamaan yhteyden niihin. Tätä tunnelia käytettiin päivitysten toimittamiseen.
Teoriassa samaa tunnelia voitiin käyttää seurantaan, mutta tällainen yhteys oli monimutkaisempi ja vähemmän luotettava kuin yksinkertainen työntö.
Pilviresurssit
Lopuksi on välttämätöntä valvoa pilvipalveluitamme ja tietokantojamme, koska käytämme niihin Kubernetesia, ihanteellisesti, jotta seurannan käyttöönotto klusterissa on mahdollisimman helppoa. Ihannetapauksessa käyttää , koska käytämme sitä useimmissa tapauksissa käyttöönottoon. Ja tietysti pilven valvontaan on käytettävä samoja ratkaisuja kuin itse skoottereissa.
Annettu
Huh, olemme ilmeisesti selvittäneet kuvauksen, tehdään lopuksi luettelo tarpeistamme:
- Nopea ratkaisu, koska seurantaa tarvitaan jo kehitysprosessin aikana
- Tilavuus/määrä - tarvitaan monia mittareita
- Lokkikeräys vaaditaan
- Luotettavuus – tiedot ovat ratkaisevan tärkeitä menestymisen kannalta
- Et voi käyttää vetomallia - tarvitset työntöä
- Tarvitsemme laitteiston lisäksi myös pilven yhtenäisen valvonnan
Lopullinen kuva näytti tältä
Pinon valinta
Joten kohtasimme kysymyksen valvontapinon valitsemisesta.
Ensinnäkin etsimme täydellisintä all-in-one-ratkaisua, joka kattaisi samanaikaisesti kaikki vaatimuksemme, mutta olisi samalla riittävän joustava räätälöidäkseen sen käytön tarpeisiimme. Silti laitteisto, arkkitehtuuri ja määräajat asettivat meille monia rajoituksia.
Valvontaratkaisuja on valtava valikoima, alkaen täysimittaisista järjestelmistä, kuten , tai ja päättyen valmiisiin ratkaisuihin kaluston hallintaan.
Aluksi jälkimmäinen vaikutti ihanteelliselta ratkaisulta meille, mutta joillain ei ollut täydellistä valvontaa, toisilla ilmaisten versioiden ominaisuudet olivat erittäin rajalliset, ja toiset eivät yksinkertaisesti täyttäneet "toiveitamme" tai eivät olleet tarpeeksi joustavia sopimaan skenaarioihimme. Jotkut ovat yksinkertaisesti vanhentuneita.
Analysoituamme useita samanlaisia ratkaisuja tulimme nopeasti siihen tulokseen, että samanlainen pino olisi helpompi ja nopeampi koota itse. Kyllä, se on hieman monimutkaisempaa kuin täysin valmiin kalustonhallintaalustan käyttöönotto, mutta meidän ei tarvitse tehdä kompromisseja.
Melkein varmasti kaikessa valtavassa ratkaisujen runsaudessa on jo valmis, joka sopisi meille täysin, mutta meidän tapauksessamme oli paljon nopeampaa koota tietty pino itse ja räätälöidä se "itsellemme" kuin valmiiden tuotteiden testaamiseen.
Kaiken tämän myötä emme pyrkineet kokoamaan kokonaista valvontaalustaa itse, vaan etsimme toimivimpia "valmiita" pinoja, joiden konfigurointi oli mahdollista joustavasti.
(B)ELK?
Ensimmäinen todella harkittu ratkaisu oli tunnettu ELK-pino.
Itse asiassa sen pitäisi olla nimeltään BELK, koska kaikki alkaa Beatsistä -
Tietenkin ELK on yksi tunnetuimmista ja tehokkaimmista ratkaisuista valvonnan alalla ja vielä enemmän lokien keräämisessä ja käsittelyssä.
Aioimme, että hirviä käytetään lokkien keräämiseen ja Prometheuksesta saatujen mittareiden pitkäaikaiseen varastointiin.
Visualisointiin voit käyttää Grafania.
Itse asiassa uusi ELK-pino voi kerätä mittareita itsenäisesti (metricbeat), ja Kibana voi myös näyttää ne.
Mutta silti ELK kasvoi alun perin lokeista ja tähän mennessä mittareiden toimivuudessa on useita vakavia haittoja:
- Huomattavasti hitaampi kuin Prometheus
- Integroituu paljon harvempiin paikkoihin kuin Prometheus
- Heille on vaikea asettaa hälytyksiä
- Mittarit vievät paljon tilaa
- Mittareiden koontinäyttöjen määrittäminen Kibanissa on paljon monimutkaisempaa kuin Grafanissa
Yleisesti ottaen ELK:n mittarit ovat raskaita eivätkä vielä niin käteviä kuin muissa ratkaisuissa, joita on nyt paljon enemmän kuin vain Prometheus: TSDB, Victoria Metrics, Cortex jne., jne. Haluaisin tietysti heti täysimittaisen all-in-one-ratkaisun, mutta metricbeatin tapauksessa kompromisseja oli liikaa.
Ja itse ELK-pinolla on useita vaikeita hetkiä:
- Se on raskasta, joskus jopa erittäin raskasta, jos keräät melko paljon dataa
- Sinun täytyy osata "keittää" se - sinun täytyy skaalata se, mutta tämä ei ole triviaalia
- Puristettu ilmainen versio - ilmaisessa versiossa ei ole normaalia hälytystä, eikä valintahetkellä ollut todennusta
Minun on sanottava, että viime aikoina viimeinen kohta on parantunut ja lisäksi (mukaan lukien todennus) itse hinnoittelumalli alkoi muuttua.
Mutta silloin, kun aiomme ottaa tämän ratkaisun käyttöön, ei varoitusta ollut ollenkaan.
Ehkä olisimme voineet yrittää rakentaa jotain ElastAlertilla tai muilla yhteisöratkaisuilla, mutta päätimme silti harkita muita vaihtoehtoja.
Loki - Grafana - Prometheus
Tällä hetkellä hyvä ratkaisu voisi olla rakentaa puhtaasti Prometheukseen perustuva valvontapino metriikkatoimittajana, Loki lokeille ja visualisointiin voi käyttää samaa Grafanaa.
Valitettavasti Loki oli projektin myyntipilotin alkaessa (syys-lokakuu 19) vielä beta-versiossa 0.3-0.4, eikä sitä kehityksen alkaessa voitu pitää tuotantoratkaisuna. ollenkaan.
Minulla ei ole vielä kokemusta varsinaisesta Lokin käyttämisestä vakavissa projekteissa, mutta voin sanoa, että Promtail (tukkien keräysagentti) toimii loistavasti sekä paljasmetallilla että kuberneteissä.
RASTI
Ehkä arvokkain (ainoa?) täysin varusteltu vaihtoehto ELK-pinolle voidaan nyt kutsua vain TICK-pinoksi - Telegraf, InfluxDB, Chronograf, Kapacitor.
Kuvaan kaikkia komponentteja alla yksityiskohtaisemmin, mutta yleinen idea on tämä:
- Telegraf - agentti mittareiden keräämiseen
- InfluxDB - metriikkatietokanta
- Kapacitor - reaaliaikainen mittausprosessori hälyttämistä varten
- Chronograf - web-paneeli visualisointia varten
InfluxDB:lle, Kapacitorille ja Chronografille on olemassa viralliset ruorikaaviot, joita käytimme niiden käyttöönotossa.
On huomattava, että Influx 2.0:n (beta) uusimmassa versiossa Kapacitor ja Chronograf tulivat osaksi InfluxDB:tä eivätkä enää ole olemassa erikseen
Lennätin
on erittäin kevyt agentti mittareiden keräämiseen tilakoneella.
Hän voi seurata valtavasti kaikkea, alkaen до
palvelin .
Sillä on useita hienoja etuja:
- Nopea ja kevyt (kirjoitettu Go)
- Syö mahdollisimman vähän resursseja
- Push-mittarit oletuksena
- Kerää kaikki tarvittavat mittarit
- Järjestelmämittarit ilman asetuksia
- Laitteistomittarit, kuten tiedot antureista
- Omien mittareiden lisääminen on erittäin helppoa
- Paljon laajennuksia paketista
- Kerää lokit
Koska push-mittarit olivat meille välttämättömiä, kaikki muut edut olivat enemmän kuin miellyttäviä lisäyksiä.
Agentin itsensä suorittama lokien kerääminen on myös erittäin kätevää, koska lokien kirjaamiseen ei tarvitse liittää lisäapuohjelmia.
Influx tarjoaa kätevimmän kokemuksen tukkien kanssa työskentelemiseen, jos käytät sitä .
Telegraf on yleensä loistava agentti mittareiden keräämiseen, vaikka et käyttäisikään muuta ICK-pinoa.
Monet ihmiset yhdistävät sen ELK:n ja useiden muiden aikasarjatietokantojen kanssa käyttömukavuuden vuoksi, koska se voi kirjoittaa mittareita melkein missä tahansa.
TuloDB
InfluxDB on TICK-pinon pääydin, nimittäin aikasarjatietokanta mittareita varten.
Mittareiden lisäksi Influx voi tallentaa myös lokeja, vaikka pohjimmiltaan sen lokit ovat vain samoja mittareita, vain tavallisten numeeristen indikaattoreiden sijasta päätoimintoa suorittaa lokitekstirivi.
InfluxDB on myös kirjoitettu Go-kielellä ja näyttää toimivan paljon nopeammin kuin ELK (ei tehokkaimmassa) klusterissamme.
Yksi Influxin hienoista eduista olisi myös erittäin kätevä ja rikas API datakyselyille, jota käytimme erittäin aktiivisesti.
Haitat - $$$ vai skaalaus?
TICK-pinolla on vain yksi havaitsemamme haittapuoli - se rakas. Vielä enemmän.
Mitä maksullisessa versiossa on, mitä ilmaisversiossa ei ole?
Sikäli kuin pystyimme ymmärtämään, ainoa ero TICK-pinon maksullisen version ja ilmaisen version välillä on skaalausominaisuudet.
Voit nimittäin nostaa klusterin korkealla käytettävyydellä vain sisällä .
Jos haluat täysimittaisen HA:n, joudut joko maksamaan tai käyttämään kainalosauvoja. On olemassa pari yhteisöratkaisua - esimerkiksi näyttää pätevältä ratkaisulta, mutta kirjoitetaan, että se ei sovellu tuotantoon, samoin kuin
- yksinkertainen ratkaisu tiedon pumppaamiseen NATS:n kautta (se on myös skaalattava, mutta tämä voidaan ratkaista).
Harmi, mutta molemmat näyttävät hylätyiltä - uusia sitoumuksia ei ole, oletan, että ongelma on pian odotettavissa oleva Influx 2.0:n uuden version julkaisu, jossa monet asiat ovat toisin (ei tietoa skaalaus siinä vielä).
Virallisesti on ilmainen versio - Itse asiassa tämä on primitiivinen HA, mutta vain tasapainottamisen kautta,
koska kaikki tiedot kirjoitetaan kaikkiin InfluxDB-esiintymiin kuormituksen tasapainottimen takana.
Hänellä on joitain kuten mahdolliset ongelmat pisteiden ylikirjoituksessa ja tarve luoda perusteet mittareille etukäteen
(mikä tapahtuu automaattisesti normaalin InfluxDB-työskentelyn aikana).
Lisäksi , tämä tarkoittaa lisäkustannuksia päällekkäisistä mittareista (sekä käsittelystä että tallennustilasta), joita et ehkä tarvitse, mutta niitä ei voi erottaa toisistaan.
Victoria Metrics?
Huolimatta siitä, että olimme täysin tyytyväisiä TICK-pinoon kaikessa muussa kuin maksetussa skaalauksessa, päätimme katsoa, oliko olemassa ilmaisia ratkaisuja, jotka voisivat korvata InfluxDB-tietokannan, jättäen kuitenkin jäljellä olevat T_CK-komponentit.
Aikasarjatietokantoja on paljon, mutta lupaavin niistä on Victoria Metrics, jolla on useita etuja:
- Nopeaa ja helppoa, ainakin tulosten perusteella
- On olemassa klusteriversio, josta on nyt jopa hyviä arvosteluja
- Hän osaa murskata
- Tukee InfluxDB-protokollaa
Emme aikoneet rakentaa täysin mukautettua pinoa Victorian pohjalta, ja päätoivomme oli, että voisimme käyttää sitä InfluxDB:n korvikkeena.
Valitettavasti tämä ei ole mahdollista huolimatta siitä, että InfluxDB-protokollaa tuetaan, se toimii vain mittareiden tallentamiseen - vain Prometheus API on saatavana "ulkopuolella", mikä tarkoittaa, että Chronografia ei voi asettaa siihen.
Lisäksi mittareille tuetaan vain numeerisia arvoja (käytimme merkkijonoarvoja mukautetuille mittareille - lisää siitä osiossa ).
Ilmeisesti samasta syystä virtuaalikone ei voi tallentaa lokeja kuten Influx.
Lisäksi on huomioitava, että optimaalista ratkaisua etsiessään Victoria Metrics ei ollut vielä niin suosittu, dokumentaatio oli paljon pienempi ja toiminnallisuus heikompi
(En muista yksityiskohtaista kuvausta klusteriversiosta ja jakamisesta).
Perusvalinta
Tämän seurauksena päätettiin, että pilotissa rajoitamme silti yhteen InfluxDB-solmuun.
Tälle valinnalle oli useita tärkeimpiä syitä:
- Pidimme todella TICK-pinon koko toimivuudesta
- Onnistuimme jo ottamaan sen käyttöön ja se toimi hienosti
- Määräajat olivat loppumassa, eikä aikaa ollut paljon jäljellä muiden vaihtoehtojen testaamiseen.
- Emme odottaneet näin raskasta kuormaa
Meillä ei ollut paljon skoottereita pilotin ensimmäiseen vaiheeseen, eikä kehitysvaiheessa suoritettu testaus paljastanut suorituskykyongelmia.
Siksi päätimme, että tähän projektiin riittäisi meille yksi Influx-solmu ilman skaalauksen tarvetta (katso johtopäätökset lopussa).
Olemme päättäneet pinosta ja pohjasta - nyt TICK-pinon jäljellä olevista komponenteista.
Kondensaattori
Kapacitor on osa TICK-pinoa, palvelua, joka voi seurata tietokantaan saapuvia mittareita reaaliajassa ja suorittaa erilaisia sääntöihin perustuvia toimintoja.
Yleensä se on sijoitettu työkaluksi mahdollisten poikkeamien seurantaan ja koneoppimiseen (en ole varma, että näillä toiminnoilla on kysyntää), mutta suosituin käyttötapaus on yleisempi - hälyttäminen.
Näin käytimme sitä ilmoituksiin. Asetimme Slack-hälytykset, kun tietty skootteri meni offline-tilaan, ja sama tehtiin älylatureille ja tärkeille infrastruktuurikomponenteille.
Näin oli mahdollista reagoida nopeasti ongelmiin ja saada ilmoituksia, että kaikki oli palannut normaaliksi.
Yksinkertainen esimerkki: "laatikkomme" virtaa käyttävä lisäakku on rikki tai jostain syystä loppunut; yksinkertaisesti asentamalla uusi, pitäisi saada jonkin ajan kuluttua ilmoitus, että skootterin toiminta on palautunut.
Influx 2.0:ssa Kapacitorista tuli osa DB:tä
Chronographs
Olen nähnyt monia erilaisia käyttöliittymäratkaisuja seurantaan, mutta voin sanoa, että toiminnallisuuden ja käyttökokemuksen suhteen mikään ei ole verrattavissa Chronografiin.
Aloimme käyttää TICK-pinoa, kummallista kyllä, Grafanilla verkkoliittymänä.
En kuvaile sen toimivuutta; kaikki tietävät sen laajat mahdollisuudet asentaa mitä tahansa.
Grafana on kuitenkin edelleen täysin universaali instrumentti, kun taas Chronograf on suunniteltu pääasiassa käytettäväksi Influxin kanssa.
Ja tietysti tämän ansiosta Chronografilla on varaa paljon älykkäämpään tai kätevämpään toimivuuteen.
Ehkä tärkein käyttömukavuus Chronografin kanssa on se, että voit tarkastella InfluxDB:n sisäosia Exploren kautta.
Vaikuttaa siltä, että Grafanalla on lähes identtiset toiminnot, mutta todellisuudessa kojelaudan määrittäminen Chronografissa voidaan tehdä muutamalla hiiren napsautuksella (samalla katsomalla siellä olevaa visualisointia), kun taas Grafanassa sinulla on kuitenkin ennemmin tai myöhemmin muokata JSON-määrityksiä (tietenkin Chronograf sallii käsin määritetyn dashasi lataamisen ja muokkaamisen tarvittaessa JSON-muodossa - mutta minun ei koskaan tarvinnut koskea niihin sen jälkeen, kun ne oli luotu käyttöliittymässä).
Kibanalla on paljon rikkaampia kykyjä luoda kojetauluja ja hallintalaitteita heille, mutta tällaisten toimintojen UX on erittäin monimutkainen.
Kätevän kojelaudan luominen vaatii hyvää ymmärrystä. Ja vaikka Chronograf-kojetaulujen toiminnallisuus on vähemmän, niiden tekeminen ja mukauttaminen on paljon yksinkertaisempaa.
Itse kojelaudat, miellyttävää visuaalista tyyliä lukuun ottamatta, eivät itse asiassa eroa Grafanan tai Kibanan kojelaudoista:
Kyselyikkuna näyttää tältä:
On tärkeää huomata muun muassa, että kun tiedät InfluxDB-tietokannan kenttätyypit, itse kronografi voi joskus automaattisesti auttaa sinua kyselyn kirjoittamisessa tai oikean aggregointifunktion, kuten keskiarvon, valinnassa.
Ja tietysti Chronograf on mahdollisimman kätevä lokien katseluun. Se näyttää tältä:
Influx-lokit on oletuksena räätälöity käyttämään syslogia, ja siksi niillä on tärkeä parametri - vakavuus.
Ylhäällä oleva kaavio on erityisen hyödyllinen, sillä siinä näet tapahtuvat virheet ja väri näyttää heti selvästi, onko vakavuus suurempi.
Pari kertaa saimme tällä tavalla tärkeitä bugeja, kun kävimme katsomassa viimeisen viikon lokit ja nähdessämme punaisen piikin.
Tietenkin ihannetapauksessa olisi asettaa hälytyksiä tällaisista virheistä, koska meillä oli jo kaikki tähän.
Laitoimme tämän jopa päälle hetkeksi, mutta pilotin valmistelussa kävi ilmi, että saimme aika paljon virheitä (mukaan lukien järjestelmävirheet, kuten LTE-verkon epäkäytettävyys), jotka "spammittivat" myös Slack-kanavan. paljon, aiheuttamatta ongelmia, suuri hyöty.
Oikea ratkaisu olisi käsitellä suurin osa tämäntyyppisistä virheistä, säätää niiden vakavuutta ja ottaa hälytyksen käyttöön vasta sitten.
Tällä tavalla vain uudet tai tärkeät virheet lähetettäisiin Slackiin. Aika ei yksinkertaisesti riittänyt sellaiseen järjestelyyn tiukkojen määräaikojen vuoksi.
todennus
On myös syytä mainita, että Chronograf tukee OAuth- ja OIDC-tunnistusta.
Tämä on erittäin kätevää, koska sen avulla voit helposti liittää sen palvelimeesi ja luoda täysimittaisen SSO:n.
Meidän tapauksessamme palvelin oli — sitä käytettiin yhteyden muodostamiseen valvontaan, mutta samaa palvelinta käytettiin myös skootterien ja pyyntöjen todentamiseen taustalle.
"Järjestelmänvalvoja"
Viimeinen komponentti, jonka kuvaan, on itse kirjoitettu "hallintapaneelimme" Vuessa.
Pohjimmiltaan se on vain itsenäinen palvelu, joka näyttää skootteritiedot omista tietokannoistamme, mikropalveluistamme ja InfluxDB:n mittaustietoja samanaikaisesti.
Lisäksi sinne siirrettiin monia hallinnollisia toimintoja, kuten hätäkäynnistys tai tukitiimin lukon avaaminen etänä.
Siellä oli myös karttoja. Mainitsin jo, että aloitimme Grafanalla Chronografin sijasta - koska Grafanalle on saatavilla karttoja lisäosien muodossa, joista voisimme tarkastella skootterien koordinaatteja. Valitettavasti Grafanan karttawidgetien ominaisuudet ovat hyvin rajalliset, ja sen seurauksena oli paljon helpompaa kirjoittaa oma web-sovellus karttojen kanssa muutamassa päivässä, jotta ei vain näkisi tällä hetkellä koordinaatteja, vaan myös skootterin kulkeman reitin, pystyä suodattamaan tietoja kartalla jne. (kaikki ne toiminnot, joita emme voineet määrittää yksinkertaisessa kojelautassa).
Yksi jo mainituista Influxin eduista on kyky luoda helposti omia mittareita.
Tämä mahdollistaa sen käytön valtavaan valikoimaan skenaarioita.
Yritimme tallentaa sinne kaiken hyödyllisen tiedon: akun lataus, lukituksen tila, anturin suorituskyky, bluetooth, GPS ja monet muut terveystarkastukset.
Näytimme kaiken tämän hallintapaneelissa.
Tietenkin meille tärkein kriteeri oli skootterin toimintakunto - itse asiassa Influx tarkistaa tämän itse ja näyttää sen "vihreillä valoilla" Solmut-osiossa.
Tämä tapahtuu funktiolla - Käytimme sitä ymmärtääksemme laatikkomme suorituskyvyn ja lähettääksemme samat hälytykset Slackiin.
Muuten, annoimme skootterit Simpsonien hahmojen nimien mukaan - oli niin kätevää erottaa ne toisistaan
Ja yleensä se oli hauskempaa näin. Lausuja kuten "Kaverit, Smithers on kuollut!" kuultiin jatkuvasti.
Merkkijonomittarit
On tärkeää, että InfluxDB sallii sinun tallentaa ei vain numeerisia arvoja, kuten Victoria Metricsin tapauksessa.
Vaikuttaa siltä, että tämä ei ole niin tärkeää - loppujen lopuksi, lokien lisäksi mitä tahansa mittareita voidaan tallentaa numeroiden muodossa (lisää vain tunnettujen tilojen kartoitus - eräänlainen enum)?
Meidän tapauksessamme oli ainakin yksi skenaario, jossa merkkijonomittarit olivat erittäin hyödyllisiä.
Sattui vain niin, että "älylatureidemme" toimittaja oli kolmas osapuoli, emmekä voineet vaikuttaa kehitysprosessiin ja tietoihin, joita nämä laturit voisivat toimittaa.
Tämän seurauksena lataussovellusliittymä oli kaukana ihanteellisesta, mutta suurin ongelma oli, että emme aina voineet ymmärtää niiden tilaa.
Tässä Influx tuli apuun. Kirjoitimme vain meille tulleen merkkijonon tilan InfluxDB-tietokantakenttään ilman muutoksia.
Jonkin aikaa sinne pääsivät vain arvot, kuten "online" ja "offline", joiden perusteella tiedot näytettiin hallintapaneelissamme ja ilmoitukset lähetettiin Slackiin. Jossain vaiheessa siellä alkoi kuitenkin ilmaantua myös sellaisia arvoja kuin "irrotettu".
Kuten myöhemmin kävi ilmi, tämä tila lähetettiin kerran yhteyden katkeamisen jälkeen, jos laturi ei pystynyt muodostamaan yhteyttä palvelimeen tietyn yrityksen jälkeen.
Jos siis käytimme vain kiinteitä arvoja, emme ehkä näe näitä muutoksia laiteohjelmistossa oikeaan aikaan.
Ja yleensä merkkijonomittarit tarjoavat paljon enemmän mahdollisuuksia käytettäväksi; voit tallentaa käytännössä kaikki tiedot niissä. Vaikka sinun on tietysti myös käytettävä tätä työkalua huolellisesti.
Tavallisten mittareiden lisäksi tallensimme myös GPS-sijaintitiedot InfluxDB:hen. Tämä oli uskomattoman hyödyllistä valvottaessa skootterien sijaintia hallintapaneelissamme.
Itse asiassa tiesimme aina missä ja mikä skootteri oli tällä hetkellä tarvitsemme.
Tämä oli erittäin hyödyllinen meille, kun etsimme skootteria (katso johtopäätökset lopussa).
Infrastruktuurin seuranta
Itse skootterien lisäksi meidän piti valvoa myös koko (melko laajaa) infrastruktuuriamme.
Hyvin yleinen arkkitehtuuri näytti tältä:
Jos korostamme puhdasta valvontapinoa, se näyttää tältä:
Haluaisimme tarkistaa pilvestä:
- tietokannat
- Avaimenperä
- Mikropalvelut
Koska kaikki pilvipalvelumme sijaitsevat Kubernetesissa, olisi mukava kerätä tietoa sen tilasta.
Onneksi Telegraf valmiina voi kerätä valtavan määrän mittareita Kubernetes-klusterin tilasta, ja Chronograf tarjoaa heti kauniita kojetauluja tähän.
Seurasimme pääasiassa podien suorituskykyä ja muistin kulutusta. Putoamisen sattuessa hälyttää Slackissa.
Kubernetesissa podeja voi seurata kahdella tavalla: DaemonSet ja Sidecar.
Molemmat menetelmät kuvataan yksityiskohtaisesti .
Käytimme Telegraf Sidecaria ja keräsimme mittareiden lisäksi pod-lokeja.
Meidän tapauksessamme jouduimme puuhailemaan tukkeja. Huolimatta siitä, että Telegraf voi vetää lokit Docker API:sta, halusimme yhtenäisen lokikokoelman loppulaitteillamme ja konfiguroimme syslogin konteille tätä varten. Ehkä tämä ratkaisu ei ollut kaunis, mutta sen toiminnassa ei ollut valittamista ja lokit näkyivät hyvin Chronografissa.
Monitorin valvonta???
Lopulta nousi esille ikivanha kysymys valvontajärjestelmien seurannasta, mutta onneksi tai valitettavasti aika ei yksinkertaisesti riittänyt siihen.
Vaikka Telegraf voi helposti lähettää omia mittareitaan tai kerätä mittareita InfluxDB-tietokannasta lähetettäväksi joko samalle Influxille tai jonnekin muualle.
Tulokset
Mitä johtopäätöksiä teimme pilotin tuloksista?
Miten seurantaa voi tehdä?
Ensinnäkin TICK-pino vastasi täysin odotuksiamme ja antoi meille jopa enemmän mahdollisuuksia kuin mitä alun perin odotimme.
Kaikki tarvittava toiminnallisuus oli läsnä. Kaikki mitä teimme sen kanssa toimi ilman ongelmia.
Suorituskyky
Ilmaisversion TICK-pinon suurin ongelma on skaalausominaisuuksien puute. Tämä ei ollut meille ongelma.
Emme keränneet tarkkoja kuormitustietoja/lukuja, mutta keräsimme tietoja noin 30 skootterista kerrallaan.
Jokainen heistä keräsi yli kolme tusinaa mittaria. Samalla kerättiin lokit laitteista. Tietojen kerääminen ja lähettäminen tapahtui 10 sekunnin välein.
On tärkeää huomata, että puolentoista viikon pilotin jälkeen, kun suurin osa "lapsuuden ongelmista" oli korjattu ja tärkeimmät ongelmat oli jo ratkaistu, jouduimme vähentämään tiedon lähetystiheyttä palvelimelle. 30 sekuntia. Tämä tuli tarpeelliseksi, koska LTE SIM-korttiemme liikenne alkoi nopeasti kadota.
Suurimman osan liikenteestä kuluttivat lokit, itse mittarit eivät 10 sekunnin väleinkään käytännössä tuhlanneet sitä.
Tämän seurauksena jonkin ajan kuluttua poistimme lokien keräämisen kokonaan käytöstä laitteissa, koska tietyt ongelmat olivat jo ilmeisiä jopa ilman jatkuvaa keräämistä.
Joissakin tapauksissa, jos lokien katselu oli edelleen tarpeen, muodostimme yksinkertaisesti yhteyden WireGuardin kautta VPN:n kautta.
Lisään vielä, että jokainen erillinen ympäristö erotettiin toisistaan ja yllä kuvattu kuormitus koski vain tuotantoympäristöä.
Kehitysympäristössä esitimme erillisen InfluxDB-esiintymän, joka jatkoi tietojen keräämistä 10 sekunnin välein, eikä meillä ollut mitään suorituskykyongelmia.
TICK - ihanteellinen pieniin ja keskikokoisiin projekteihin
Näiden tietojen perusteella päättelen, että TICK-pino on ihanteellinen suhteellisen pienille projekteille tai projekteille, jotka eivät todellakaan odota HighLoadia.
Jos sinulla ei ole tuhansia podeja tai satoja koneita, jopa yksi InfluxDB-esiintymä kestää kuorman hienosti.
Joissakin tapauksissa saatat olla tyytyväinen Influx Relay -ratkaisuun primitiivisenä High Availability -ratkaisuna.
Ja tietenkään kukaan ei estä sinua asettamasta "pystysuuntaista" skaalausta ja yksinkertaisesti allokoimasta eri palvelimia erityyppisille mittareille.
Jos et ole varma valvontapalvelujen odotetusta kuormituksesta tai sinulla on taatusti erittäin "raskas" arkkitehtuuri, en suosittele TICK-pinon ilmaisen version käyttöä.
Yksinkertaisin ratkaisu olisi tietysti ostaa - mutta tässä en voi mitenkään kommentoida, koska en itse ole perehtynyt hienouksiin. Sen lisäksi, että se on erittäin kallista eikä todellakaan sovi pienille yrityksille.
Tässä tapauksessa suosittelen tänään etsimään mittareita Victoria Metricsin kautta ja lokeja Lokin avulla.
Totta, teen taas varauksen, että Loki/Grafana ovat paljon vähemmän käteviä (suuremman monipuolisuutensa vuoksi) kuin valmiit TICK, mutta ne ovat ilmaisia.
On tärkeää: kaikki tässä kuvatut tiedot koskevat versiota Influx 1.8, tällä hetkellä Influx 2.0 julkaistaan.
Vaikka minulla ei ole ollut mahdollisuutta kokeilla sitä taisteluolosuhteissa ja on vaikea tehdä johtopäätöksiä parannuksista, käyttöliittymä on ehdottomasti parantunut, arkkitehtuuria on yksinkertaistettu (ilman kapasitoria ja kronografia),
malleja ilmestyi ("tappajaominaisuus" - ). Mutta valitettavasti tällä hetkellä versiossa 2 ei ole sitä avainasiaa, jolle valitsimme ensimmäisen version - lokikokoelmaa ei ole.
Tämä toiminto tulee näkyviin myös Influx 2.0:ssa, mutta emme löytäneet mitään määräaikoja, edes likimääräisiä.
Kuinka olla tekemättä IoT-alustoja (nyt)
Loppujen lopuksi, kun olemme käynnistäneet lentäjän, me itse kootimme oman täysimittaisen Internet-pinon, koska standardimme sopivaa vaihtoehtoa ei ole.
Se on kuitenkin hiljattain saatavilla beta-versiona – Harmi, että hän ei ollut paikalla, kun aloitimme projektin tekemisen.
Olemme täysin tyytyväisiä lopputulokseen ja itse kokoamiimme Ansible + TICK + WireGuard -pohjaiseen alustaan. Mutta tänään suosittelen tutustumaan Balenaan tarkemmin ennen kuin yrität rakentaa omaa IoT-alustaa itse.
Koska lopulta se voi tehdä suurimman osan siitä, mitä teimme, ja OpenBalena on ilmainen ja avoimen lähdekoodin.
Se tietää jo, kuinka ei vain lähetä päivityksiä, vaan myös VPN on jo sisäänrakennettu ja räätälöity IoT-ympäristössä käytettäväksi.
Ja juuri äskettäin he jopa julkaisivat omansa , joka yhdistyy helposti heidän ekosysteemiinsä.
Hei, entä kadonnut skootteri?
Joten skootteri "Ralph" katosi jälkiä jättämättä.
Juosimme heti katsomaan karttaa "hallintapaneelissamme", jossa oli InfluxDB:n GPS-mittaritietoja.
Valvontatietojen ansiosta selvisimme helposti, että skootteri poistui parkkipaikalta viime päivänä klo 21:00 aikoihin, ajoi noin puoli tuntia jollekin alueelle ja oli pysäköity klo 5:een asti jonkun saksalaisen talon viereen.
Klo 5 jälkeen valvontatietoja ei saatu – tämä tarkoitti, että lisäakku oli täysin tyhjä tai hyökkääjä lopulta keksi, kuinka älykäs laitteisto voidaan poistaa skootterista.
Tästä huolimatta poliisi hälytettiin osoitteeseen, jossa skootteri sijaitsi. Skootteri ei ollut siellä.
Tästä kuitenkin yllättyi myös talon omistaja, sillä hän itse asiassa ajoi tällä skootterilla kotiin toimistolta eilen illalla.
Kuten kävi ilmi, yksi tukityöntekijöistä saapui aikaisin aamulla ja haki skootterin, koska sen lisäakku oli täysin tyhjä ja vei sen (jalan) parkkipaikalle. Ja lisäakku epäonnistui kosteuden vuoksi.
Varastimme skootterin itseltämme. En muuten tiedä miten ja kuka sitten ratkaisi asian poliisijutun kanssa, mutta valvonta toimi täydellisesti...
Lähde: will.com