Aasta tagasi käivitasime reklaamprojekti pilootversiooni .
Algselt kandis projekt nime Road-To-Barcelona, hiljem sai sellest Road-To-Berlin (seega R2B ekraanipiltidel) ja lõpuks sai nimeks xRide.
Projekti põhiidee oli järgmine: tsentraliseeritud auto- või tõukerattarentimise teenuse asemel (räägime tõukeratastest ehk elektrimootorratastest, mitte tõukeratastest/tõukeratastest) soovisime teha platvormi detsentraliseeritud rentimiseks. Raskustest, millega kokku puutusime .
Algselt keskendus projekt autodele, kuid tähtaegade, tootjatega ülipika suhtluse ja tohutu hulga ohutuspiirangute tõttu valiti piloodiks elektritõukerattad.
Kasutaja installis telefoni iOS-i või Androidi rakenduse, lähenes talle meelepärasele rollerile, misjärel tekkis telefonil ja tõukerattal peer-to-peer ühendus, vahetati ETH ja kasutaja sai sõitu alustada, lülitades rolleri sisse telefoni. Reisi lõppedes oli võimalik reisi eest tasuda ka Ethereumi abil telefonis olevast kasutaja rahakotist.
Lisaks tõukeratastele nägi kasutaja rakenduses “nutilaadijaid”, mida külastades sai kasutaja praeguse aku tühjenemise korral ise vahetada.
Selline nägi üldiselt välja meie piloot, mis käivitati eelmise aasta septembris kahes Saksamaa linnas: Bonnis ja Berliinis.
Ja siis ühel päeval Bonnis, varahommikul, hoiatati meie tugimeeskonda (mis asus kohapeal, et tõukerattad töökorras hoida): üks rolleritest oli jäljetult kadunud.
Kuidas seda leida ja tagastada?
Selles artiklis räägin sellest, kuid kõigepealt sellest, kuidas me oma asjade Interneti-platvormi ehitasime ja kuidas seda jälgisime.
Mida ja miks jälgida: tõukerattad, taristu, laadimisjaamad?
Mida me siis oma projektis jälgida tahtsime?
Esiteks on need tõukerattad ise - elektrilised tõukerattad ise on üsna kallid, ilma piisava ettevalmistuseta sellist projekti käivitada ei saa; võimalusel soovite koguda tõukerataste kohta võimalikult palju teavet: nende asukoha, laetuse taseme kohta , jne.
Lisaks sooviksin jälgida meie enda IT-taristu seisukorda – andmebaasid, teenused ja kõik, mis tööks vajalik. Samuti oli vaja jälgida “nutilaadijate” olekut, juhuks kui need katki lähevad või akud tühjaks saavad.
Rollerid
Millised olid meie tõukerattad ja mida me nende kohta teada tahtsime?
Esimene ja kõige olulisem asi on GPS-koordinaadid, sest tänu neile saame aru, kus nad asuvad ja kus nad liiguvad.
Järgmine on aku laadimine, tänu millele saame kindlaks teha, et tõukerataste laadimine on lõppemas ja saata mahlapressi või vähemalt hoiatada kasutajat.
Loomulikult on vaja ka kontrollida, mis toimub meie riistvarakomponentidega:
- kas bluetooth töötab?
- kas GPS moodul ise töötab?
- Meil oli probleem ka sellega, et GPS võis saata valesid koordinaate ja takerduda ning seda sai kindlaks teha vaid rolleri täiendavate kontrollidega,
ja teavitage probleemi lahendamiseks tugiteenust niipea kui võimalik
- Meil oli probleem ka sellega, et GPS võis saata valesid koordinaate ja takerduda ning seda sai kindlaks teha vaid rolleri täiendavate kontrollidega,
Ja lõpuks: tarkvara kontrollimine, alustades OS-ist ja protsessorist, võrgu- ja kettakoormusest, lõpetades meie enda moodulite kontrollimisega, mis on meile spetsiifilisemad (, ).
riistvara
Mis oli meie "raudne" osa?
Võttes arvesse võimalikult lühikest ajavahemikku ja kiire prototüüpimise vajadust, valisime juurutamiseks ja komponentide valikuks lihtsaima variandi - Raspberry Pi.
Lisaks Rpi-le endale oli meil kohandatud plaat (mille me ise arendasime ja Hiinast tellisime, et kiirendada lõpplahenduse kokkupanekut) ja komponentide komplekt - relee (tõukeratta sisse/välja lülitamiseks), akulaadimislugeja, modem, antennid. Kõik see oli kompaktselt pakendatud spetsiaalsesse “xRide kasti”.
Samuti tuleb märkida, et kogu kasti toiteallikaks oli täiendav akupank, mis omakorda sai toite rolleri põhiakust.
See võimaldas tõukeratta jälgimist ja sisselülitamist ka pärast reisi lõppu, kuna põhiaku lülitati välja kohe pärast süütevõtme väljalülitamist.
Docker? Lihtne Linux? ja kasutuselevõtt
Tuleme tagasi seire juurde, seega Vaarikas – mis meil on?
Üks esimesi asju, mida tahtsime komponentide juurutamise, värskendamise ja füüsilistesse seadmetesse tarnimise protsessi kiirendamiseks kasutada, oli Docker.
Kahjuks sai kiiresti selgeks, et RPi Dockeril, kuigi see töötab, on palju üldkulusid, eriti energiatarbimise osas.
Erinevus „natiivse” OS-i kasutamisel, kuigi mitte nii tugev, oli siiski piisav, et olla ettevaatlik laengu liiga kiire kaotamise võimaluse suhtes.
Teiseks põhjuseks oli üks meie partnerteegid saidil Node.js (sic!) – süsteemi ainus komponent, mis ei olnud Go/C/C++ keeles kirjutatud.
Raamatukogu autoritel ei olnud aega üheski “emakeeles” töötavat versiooni pakkuda.
Sõlm ise pole mitte ainult madala jõudlusega seadmete jaoks kõige elegantsem lahendus, vaid ka raamatukogu ise oli väga ressursinäljas.
Mõistsime, et isegi kui tahaksime, oleks Dockeri kasutamine meie jaoks liiga suur kulu. Valik tehti algse OS-i kasuks ja selle all töötades.
OS
Selle tulemusena valisime taas OS-iks kõige lihtsama võimaluse ja kasutasime Raspbiani (Debiani ehitamine Pi jaoks).
Kirjutame kogu oma tarkvara Go-sse, seega kirjutasime Go-sse ka oma süsteemi peamise riistvaraagendi mooduli.
Just tema vastutab GPS-i, Bluetoothiga töötamise, laadimise lugemise, tõukeratta sisselülitamise jms eest.
Kasutusele võtta
Kohe tekkis küsimus, kas on vaja juurutada mehhanismi värskenduste edastamiseks seadmetesse (OTA) – nii meie agendi/rakenduse enda kui ka OS-i/püsivara enda värskendusi (kuna agendi uued versioonid võivad vajada kerneli värskendusi või süsteemikomponendid, teegid jne) .
Pärast üsna pikka turuanalüüsi selgus, et lahendusi uuenduste seadmesse toimetamiseks on päris palju.
Alates suhteliselt lihtsatest, enamasti värskendustele/kahekäivitustele orienteeritud utiliitidest nagu swupd/SWUpdate/OSTree kuni täisväärtuslike platvormideni nagu Mender ja Balena.
Esiteks otsustasime, et meid huvitavad otsast lõpuni lahendused, mistõttu langes valik kohe platvormidele.
Väga jäeti välja, kuna see kasutab tegelikult sama Dockerit oma balenaEngine'is.
Kuid märgin, et vaatamata sellele kasutasime pidevalt nende toodet SD-kaartide välgu püsivara jaoks - lihtne ja äärmiselt mugav utiliit selleks.
Seetõttu langes valik lõpuks . Mender on terviklik platvorm püsivara kokkupanekuks, tarnimiseks ja installimiseks.
Üldiselt näeb platvorm suurepärane välja, kuid meil kulus umbes poolteist nädalat, et luua õige püsivara versioon, kasutades mender builderit.
Ja mida rohkem me selle kasutamise keerukustesse sukeldusime, seda selgemaks sai, et selle täielikuks kasutuselevõtuks vajame palju rohkem aega, kui meil oli.
Kahjuks tähendasid meie kitsad tähtajad seda, et olime sunnitud Menderi kasutamisest loobuma ja valima veelgi lihtsama.
Võimalik
Lihtsaim lahendus meie olukorras oli Ansible kasutamine. Alustuseks piisas paarist mänguraamatust.
Nende olemus seisnes selles, et me lihtsalt ühendasime hostist (CI-server) ssh-i kaudu oma vaarikatega ja levitasime neile värskendusi.
Kohe alguses oli kõik lihtne - tuli olla seadmetega ühes võrgus, valamine käis wifi kaudu.
Kontoris oli lihtsalt kümmekond samasse võrku ühendatud testvaarikat, igal seadmel oli staatiline IP-aadress, mis oli ka Ansible Inventorys määratud.
See oli Ansible, kes viis meie seireagendi lõppseadmeteni
3G / LTE
Kahjuks sai see Ansible'i kasutusjuht töötada ainult arendusrežiimis enne, kui meil olid tegelikud tõukerattad.
Kuna tõukerattad, nagu te mõistate, ei istu ühendatud ühe WiFi-ruuteriga, oodates pidevalt võrgu kaudu värskendusi.
Tegelikkuses ei saa tõukeratastel olla peale mobiilse 3G/LTE (ja isegi siis mitte kogu aeg) muud ühendust.
See toob kohe kaasa palju probleeme ja piiranguid, nagu näiteks madal ühenduse kiirus ja ebastabiilne side.
Kuid kõige tähtsam on see, et 3G/LTE võrgus ei saa me lihtsalt loota võrgule määratud staatilisele IP-le.
Selle lahendavad osaliselt mõned SIM-kaardi pakkujad, staatilise IP-aadressiga IoT-seadmete jaoks on isegi spetsiaalsed SIM-kaardid. Kuid meil polnud juurdepääsu sellistele SIM-kaartidele ega saanud kasutada IP-aadresse.
Muidugi oli ideid teha mingisugune IP-aadresside registreerimine ehk service discovery kuskil nagu Consul, kuid sellistest ideedest tuli loobuda, kuna meie testides võis IP-aadress liiga sageli muutuda, mis tõi kaasa suure ebastabiilsuse.
Sel põhjusel oleks kõige mugavam kasutada mõõdikute edastamiseks mitte pull-mudelit, kus läheksime seadmetesse vajalike mõõdikute järele, vaid push, edastades mõõdikud seadmest otse serverisse.
VPN
Selle probleemi lahenduseks valisime VPN-i - konkreetselt .
Kliendid (tõukerattad) ühendasid süsteemi alguses VPN-serveriga ja said nendega ühenduse luua. Seda tunnelit kasutati värskenduste edastamiseks.
Teoreetiliselt saaks sama tunnelit kasutada ka monitooringuks, kuid selline ühendus oli keerulisem ja vähem töökindel kui lihtne tõuge.
Pilveressursid
Viimaseks on vaja jälgida meie pilveteenuseid ja andmebaase, kuna nende jaoks kasutame Kubernetest, ideaaljuhul selleks, et seire juurutamine klastris oleks võimalikult lihtne. Ideaalis kasutades , kuna juurutamiseks kasutame seda enamikul juhtudel. Ja loomulikult tuleb pilve jälgimiseks kasutada samu lahendusi, mis tõukerataste endi puhul.
Antud
Pheh, tundub, et oleme kirjelduse lahendanud, teeme lõpuks nimekirja, mida vajame:
- Kiire lahendus, kuna monitooring on vajalik juba arendusprotsessi käigus
- Maht/kogus – vaja on palju mõõdikuid
- Vajalik on palkide kogumine
- Usaldusväärsus – andmed on eduka käivitamise jaoks üliolulised
- Tõmbemudelit kasutada ei saa – vaja on tõuget
- Vajame mitte ainult riistvara, vaid ka pilve ühtset jälgimist
Lõplik pilt nägi välja umbes selline
Virna valik
Niisiis seisime silmitsi seirevirna valimise küsimusega.
Esiteks otsisime kõige terviklikumat kõik-ühes lahendust, mis kataks üheaegselt kõik meie nõuded, kuid oleks samas piisavalt paindlik, et kohandada selle kasutamist vastavalt meie vajadustele. Sellegipoolest seadsid meile palju riistvara, arhitektuuri ja tähtaegadega seotud piiranguid.
Seirelahendusi on tohutult palju, alustades täisväärtuslikest süsteemidest nagu , või ja lõpetades autopargi haldamise valmislahendustega.
Esialgu tundus viimane meile ideaalne lahendus, kuid mõnel polnud täielikku jälgimist, teistel oli tasuta versioonide võimalused tõsiselt piiratud ja teised lihtsalt ei katnud meie “soove” või polnud piisavalt paindlikud, et meie stsenaariumitega sobituda. Mõned on lihtsalt aegunud.
Analüüsides mitmeid sarnaseid lahendusi, jõudsime kiiresti järeldusele, et lihtsam ja kiirem oleks sarnast virna ise kokku panna. Jah, see on veidi keerulisem kui täiesti valmis autopargi haldusplatvormi juurutamine, kuid me ei pea tegema kompromisse.
Peaaegu kindlasti leidub kogu tohutu lahenduste rohkuse juures juba valmis, mis meile täiesti sobiks, kuid meie puhul oli palju kiirem teatud virn ise kokku panna ja “enese jaoks” kohandada kui valmistoodete testimine.
Selle kõige juures ei püüdnud me ise tervet jälgimisplatvormi kokku panna, vaid otsisime kõige funktsionaalsemaid “valmis” virnasid, ainult võimalusega neid paindlikult konfigureerida.
(B)ELK?
Esimene lahendus, mida tegelikult kaaluti, oli tuntud ELK stäkk.
Tegelikult peaks selle nime kandma BELK, sest kõik algab Beatsist -
Loomulikult on ELK üks tuntumaid ja võimsamaid lahendusi seire, aga veelgi enam logide kogumise ja töötlemise vallas.
Tahtsime, et ELK-d kasutataks palkide kogumiseks ja Prometheuselt saadud mõõdikute pikaajaliseks säilitamiseks.
Visualiseerimiseks võite kasutada Grafani.
Tegelikult saab uus ELK pinu koguda mõõdikuid iseseisvalt (metricbeat) ja Kibana saab neid ka kuvada.
Kuid siiski kasvas ELK algselt palkidest välja ja seni on mõõdikute funktsionaalsusel mitmeid tõsiseid puudusi:
- Oluliselt aeglasem kui Prometheus
- Integreerub palju vähematesse kohtadesse kui Prometheus
- Nende jaoks on märguandeid raske seadistada
- Mõõdikud võtavad palju ruumi
- Kibanis on mõõdikutega armatuurlaudade seadistamine palju keerulisem kui Grafanis
Üldjoontes on ELK mõõdikud rasked ja mitte veel nii mugavad kui teistes lahendustes, mida on nüüd palju rohkem kui lihtsalt Prometheus: TSDB, Victoria Metrics, Cortex jne jne. Muidugi tahaks väga kohe täisväärtuslikku kõik-ühes lahendust, aga metricbeati puhul oli liiga palju kompromisse.
Ja ELK stäkil endal on mitmeid raskeid hetki:
- See on raske, mõnikord isegi väga raske, kui kogute üsna suure hulga andmeid
- Peate seda "oskama süüa teha" - peate selle skaleerima, kuid see pole triviaalne
- Tühistatud tasuta versioon - tasuta versioonil pole tavalist hoiatust ja valiku ajal autentimist ei olnud
Pean ütlema, et viimasel ajal on viimane punkt muutunud paremaks ja lisaks (sh autentimine) hakkas muutuma ka hinnamudel ise.
Kuid sel ajal, kui kavatsesime selle lahenduse kasutusele võtta, ei antud üldse hoiatust.
Võib-olla oleksime võinud proovida midagi ehitada ElastAlerti või muude kogukonnalahenduste abil, kuid otsustasime siiski kaaluda muid alternatiive.
Loki – Grafana – Prometheus
Hetkel võiks hea lahendus olla puhtalt Prometheuse kui mõõdikute pakkuja baasil seirepinn, logide jaoks Loki ja visualiseerimiseks saab kasutada sedasama Grafanat.
Kahjuks oli Loki projekti müügipiloodi alguse ajal (september-oktoober 19) veel beetaversioonis 0.3-0.4 ning arenduse alustamise hetkel ei saanud seda pidada tootmislahenduseks. üleüldse.
Mul pole veel kogemusi Loki reaalses kasutamises tõsistes projektides, kuid võin öelda, et Promtail (palkide kogumise agent) töötab suurepäraselt nii palkide metallide kui ka kubernetes kaunade jaoks.
PILK
Ehk kõige väärikamaks (ainsaks?) täisfunktsionaalseks alternatiiviks ELK stäkile saab nüüd nimetada vaid TICK stäkki - Telegraf, InfluxDB, Chronograf, Kapacitor.
Allpool kirjeldan kõiki komponente üksikasjalikumalt, kuid üldine idee on järgmine:
- Telegraf - mõõdikute kogumise agent
- InfluxDB – mõõdikute andmebaas
- Kapacitor – reaalajas mõõdikute protsessor hoiatamiseks
- Chronograf - veebipaneel visualiseerimiseks
InfluxDB, Kapacitori ja Chronografi jaoks on olemas ametlikud tüürikaardid, mida kasutasime nende juurutamiseks.
Tuleb märkida, et Influx 2.0 (beeta) uusimas versioonis said Kapacitor ja Chronograf InfluxDB osaks ja neid ei eksisteeri enam eraldi
Telegraaf
on väga kerge vahend mõõdikute kogumiseks olekumasinale.
Ta saab jälgida tohutul hulgal kõike, alates kuni
server .
Sellel on mitmeid lahedaid eeliseid:
- Kiire ja kerge (kirjutatud Go-s)
- Sööb minimaalselt ressursse
- Vaikimisi lükake mõõdikud
- Kogub kõik vajalikud mõõdikud
- Süsteemi mõõdikud ilma seadeteta
- Riistvaramõõdikud, näiteks anduritelt saadav teave
- Oma mõõdikuid on väga lihtne lisada
- Palju pistikprogramme karbist välja
- Kogub palke
Kuna tõukemeetrika oli meile vajalik, siis kõik muud plussid olid rohkem kui meeldivad täiendused.
Agendi enda poolt logide kogumine on samuti väga mugav, kuna logide logimiseks pole vaja täiendavaid utiliite ühendada.
Influx pakub kõige mugavamat kogemust palgiga töötamiseks, kui kasutate .
Telegraf on üldiselt suurepärane agent mõõdikute kogumiseks, isegi kui te ei kasuta ülejäänud ICK-i pinu.
Paljud inimesed kasutavad seda mugavuse huvides ELK-i ja muude aegridade andmebaasidega, kuna see võib kirjutada mõõdikuid peaaegu kõikjal.
InfluxDB
InfluxDB on TICKi virna põhituum, nimelt mõõdikute aegridade andmebaas.
Lisaks mõõdikutele saab Influx salvestada ka logisid, kuigi sisuliselt on tema logid lihtsalt samad mõõdikud, ainult tavaliste numbrinäitajate asemel täidab põhifunktsiooni logiteksti rida.
InfluxDB on kirjutatud ka Go-s ja tundub, et see töötab meie (mitte kõige võimsama) klastri ELK-ga võrreldes palju kiiremini.
Üks Influxi lahedatest eelistest oleks ka väga mugav ja rikkalik API andmepäringute jaoks, mida me väga aktiivselt kasutasime.
Puudused – $$$ või skaleerimine?
TICKi virnal on ainult üks puudus, mille avastasime – see kallis. Isegi rohkem.
Mis on tasulisel versioonil, mida tasuta versioonil pole?
Niipalju kui me aru saime, on ainus erinevus TICKi virna tasulise versiooni ja tasuta versiooni vahel skaleerimisvõimalused.
Nimelt saab Kõrge kättesaadavusega klastri kasvatada ainult in .
Kui soovite täisväärtuslikku HA-d, peate kas maksma või kasutama mõnda karku. On paar kogukonnalahendust – näiteks näeb välja pädev lahendus, aga kirjas, et tootmiseks ei sobi, samuti
- lihtne lahendus NATS-i kaudu andmete pumpamisega (seda tuleb ka skaleerida, kuid see on lahendatav).
Kahju, aga mõlemad tunduvad olevat hüljatud – värskeid sissemakseid pole, eeldan, et probleem on peagi oodatavas Influx 2.0 uue versiooni väljalaskmises, milles on palju asju teisiti (puudub info skaleerimine selles veel).
Ametlikult on olemas tasuta versioon - tegelikult on see primitiivne HA, kuid ainult tasakaalustamise kaudu,
kuna kõik andmed kirjutatakse kõikidesse InfluxDB eksemplaridesse koormuse tasakaalustaja taga.
Tal on mõned nagu võimalikud probleemid punktide ülekirjutamisega ja vajadus luua eelnevalt mõõdikute alused
(mis juhtub automaatselt InfluxDB-ga tavapärase töö ajal).
Lisaks sellele , tähendab see täiendavaid üldkulusid topeltmõõdikute jaoks (nii töötlemine kui ka salvestamine), mida te ei pruugi vajada, kuid neid pole võimalik eraldada.
Victoria mõõdikud?
Selle tulemusena, hoolimata asjaolust, et olime TICK-i virnaga kõiges muus kui tasulises skaleerimises täiesti rahul, otsustasime vaadata, kas on olemas tasuta lahendusi, mis võiksid InfluxDB andmebaasi asendada, jättes ülejäänud T_CK komponendid alles.
Aegridade andmebaase on palju, kuid kõige lootustandvam on Victoria Metrics, millel on mitmeid eeliseid:
- Kiire ja lihtne, vähemalt tulemuste järgi
- On olemas kobarversioon, mille kohta on praegu isegi häid ülevaateid
- Ta oskab killustada
- Toetab InfluxDB protokolli
Me ei kavatsenud Victoria baasil täielikult kohandatud pinu ehitada ja peamine lootus oli, et saame seda kasutada InfluxDB asendajana.
Kahjuks pole see võimalik, hoolimata asjaolust, et InfluxDB protokoll on toetatud, töötab see ainult mõõdikute salvestamiseks - ainult Prometheuse API on saadaval "väljaspool", mis tähendab, et Chronografi pole võimalik sellele seadistada.
Veelgi enam, mõõdikute jaoks toetatakse ainult arvväärtusi (kasutasime kohandatud mõõdikute jaoks stringiväärtusi – sellest leiate lähemalt jaotises ).
Ilmselgelt ei saa VM samal põhjusel logisid salvestada nagu Influx.
Samuti tuleb märkida, et optimaalse lahenduse otsimise ajal ei olnud Victoria Metrics veel nii populaarne, dokumentatsioon oli palju väiksem ja funktsionaalsus nõrgem
(Ma ei mäleta klastri versiooni ja jaotamise üksikasjalikku kirjeldust).
Aluse valik
Selle tulemusel otsustati, et piloodi puhul piirdume siiski ühe InfluxDB sõlmega.
Sellel valikul oli mitu peamist põhjust:
- Meile meeldis väga kogu TICKi virna funktsionaalsus
- Meil õnnestus see juba kasutusele võtta ja see töötas suurepäraselt
- Tähtajad olid lõppemas ja teiste võimaluste katsetamiseks ei jäänud palju aega.
- Me ei oodanud nii suurt koormust
Meil ei olnud pilootprojekti esimeses etapis palju rollereid ja arenduse ajal testimine ei näidanud jõudlusprobleeme.
Seetõttu otsustasime, et selle projekti jaoks piisab meile ühest Influx-sõlmest, ilma et oleks vaja skaleerida (vt järeldusi lõpus).
Oleme otsustanud virna ja aluse kasuks – nüüd TICKi virna ülejäänud komponentide kohta.
Kondensaator
Kapacitor on osa TICK-pinust – teenus, mis suudab reaalajas jälgida andmebaasi sisenevaid mõõdikuid ja teha reeglite alusel erinevaid toiminguid.
Üldiselt positsioneeritakse see potentsiaalsete kõrvalekallete jälgimise ja masinõppe tööriistana (ma pole kindel, et need funktsioonid on nõutud), kuid selle kasutamise kõige populaarsem juhtum on tavalisem - hoiatamine.
Nii kasutasime seda teatiste jaoks. Seadistasime Slacki märguanded, kui konkreetne roller läks võrguühenduseta, ja sama tehti nutikate laadijate ja oluliste infrastruktuurikomponentide puhul.
See võimaldas probleemidele kiiresti reageerida ja saada teateid, et kõik on taas normaalne.
Lihtne näide: lisaaku meie “kasti” toiteks on katki läinud või on mingil põhjusel tühjaks saanud; lihtsalt uue paigaldades peaksime mõne aja pärast saama teate, et rolleri töövõime on taastatud.
Influx 2.0-s sai Kapacitor DB osaks
Kronograaf
Olen näinud palju erinevaid kasutajaliidese lahendusi jälgimiseks, kuid võin öelda, et funktsionaalsuse ja UX-i poolest ei anna Chronografiga võrrelda midagi.
Kummalisel kombel hakkasime kasutama TICKi pinu, kasutades veebiliidesena Grafani.
Ma ei kirjelda selle funktsionaalsust, kõik teavad selle laialdasi võimalusi millegi seadistamiseks.
Grafana on aga endiselt täiesti universaalne instrument, Chronograf on aga mõeldud peamiselt Influxiga kasutamiseks.
Ja loomulikult saab Chronograf tänu sellele lubada endale palju nutikamat või mugavamat funktsionaalsust.
Võib-olla on Chronografiga töötamise peamine mugavus see, et saate Explore'i kaudu vaadata oma InfluxDB sisemust.
Näib, et Grafanal on peaaegu identsed funktsioonid, kuid tegelikult saab Chronografis armatuurlaua seadistada mõne hiireklõpsuga (samal ajal vaadates sealset visualiseerimist), samas kui Grafanas on see varem või hiljem siiski olemas. JSON-i konfiguratsiooni redigeerimiseks (loomulikult lubab Chronograf teie käsitsi konfigureeritud dashasid üles laadida ja vajadusel JSON-idena redigeerida – aga ma ei pidanud neid pärast kasutajaliideses loomist kunagi puudutama).
Kibanal on palju rikkalikumad võimalused armatuurlaudade ja nende jaoks juhtelementide loomiseks, kuid selliste toimingute kasutuskogemus on väga keeruline.
Mugava armatuurlaua loomiseks on vaja head arusaamist. Ja kuigi Chronografi armatuurlaudade funktsionaalsus on väiksem, on nende valmistamine ja kohandamine palju lihtsam.
Armatuurlauad ise, peale meeldiva visuaalse stiili, ei erine tegelikult Grafana või Kibana armatuurlaudadest:
Päringu aken näeb välja selline:
Muuhulgas on oluline märkida, et teades InfluxDB andmebaasi väljade tüüpe, võib kronograaf ise mõnikord automaatselt aidata päringu kirjutamisel või õige koondamisfunktsiooni (nt keskmine) valimisel.
Ja loomulikult on Chronograf logide vaatamiseks võimalikult mugav. See näeb välja selline:
Vaikimisi on sissevoolu logid kohandatud syslogi kasutamiseks ja seetõttu on neil oluline parameeter - tõsidus.
Eriti kasulik on ülaosas olev graafik, millel on näha esinevad vead ja värv näitab kohe selgelt, kas raskusaste on suurem.
Paar korda tabasime sel teel olulisi putukaid, käisime viimase nädala palke vaatamas ja nägime punast piiki.
Muidugi oleks ideaaljuhul selliste vigade puhul hoiatusteadete seadistamine, kuna meil oli selleks juba kõik olemas.
Lülitasime selle korraks isegi sisse, kuid piloodi ettevalmistamise käigus selgus, et saime päris palju tõrkeid (sealhulgas süsteemivigu nagu LTE võrgu kättesaamatus), mis “spämmitasid” ka Slacki kanalit. palju, ilma probleeme tekitamata.suur kasu.
Õige lahendus oleks käsitleda enamikku seda tüüpi tõrkeid, kohandada nende tõsidust ja alles seejärel lubada hoiatus.
Nii postitatakse Slacki ainult uued või olulised vead. Arvestades kitsaid tähtaegu, polnud sellise seadistuse jaoks lihtsalt piisavalt aega.
Autentimine
Samuti väärib mainimist, et Chronograf toetab autentimiseks OAuthi ja OIDC-d.
See on väga mugav, kuna võimaldab teil selle hõlpsalt oma serveriga ühendada ja luua täieõiguslik SSO.
Meie puhul oli server — seda kasutati seirega ühenduse loomiseks, kuid sama serverit kasutati ka tõukerataste ja päringute autentimiseks taustasüsteemile.
"Administraator"
Viimane komponent, mida ma kirjeldan, on meie enda kirjutatud "administraatori paneel" Vue's.
Põhimõtteliselt on see lihtsalt eraldiseisev teenus, mis kuvab samaaegselt tõukerattateavet meie enda andmebaasidest, mikroteenustest ja InfluxDB mõõdikute andmeid.
Lisaks viidi sinna palju haldusfunktsioone, näiteks hädaabi taaskäivitamine või tugimeeskonna luku kaugavamine.
Seal olid ka kaardid. Ma juba mainisin, et alustasime Chronografi asemel Grafanaga - kuna Grafana jaoks on olemas kaardid pluginate kujul, millelt saime vaadata rollerite koordinaate. Kahjuks on Grafana jaoks mõeldud kaardividinate võimalused väga piiratud ja sellest tulenevalt oli mõne päevaga palju lihtsam kirjutada oma veebirakendus koos kaartidega, et mitte ainult hetkel koordinaate näha, vaid ka kuvada. rolleri läbitud marsruut, suutma filtreerida andmeid kaardil jne (kõik see funktsionaalsus, mida me lihtsal armatuurlaual seadistada ei saanud).
Üks juba mainitud Influxi eelistest on võimalus lihtsalt luua oma mõõdikuid.
See võimaldab seda kasutada väga erinevate stsenaariumide jaoks.
Üritasime sinna salvestada kogu kasuliku info: aku laetuse, luku oleku, andurite jõudluse, bluetooth, GPS-i ja palju muid tervisekontrolle.
Näitasime seda kõike administraatoripaneelil.
Loomulikult oli meie jaoks kõige olulisem kriteerium rolleri töökord - tegelikult kontrollib Influx seda ise ja näitab seda jaotises Nodes “roheliste tuledega”.
Seda teeb funktsioon — kasutasime seda oma kasti toimivuse mõistmiseks ja samade hoiatuste saatmiseks Slackile.
Muide, panime rolleritele nimed Simpsonite tegelaste nimede järgi - nii mugav oli neid üksteisest eristada
Ja üldiselt oli nii lõbusam. Pidevalt kõlasid sellised laused nagu "Poisid, Smithers on surnud!".
Stringi mõõdikud
On oluline, et InfluxDB võimaldaks salvestada mitte ainult arvväärtusi, nagu Victoria Metricsi puhul.
Tundub, et see polegi nii oluline - peale logide saab mis tahes mõõdikuid salvestada ka numbrite kujul (lihtsalt lisage teadaolevate olekute kaardistamine - omamoodi enum)?
Meie puhul oli vähemalt üks stsenaarium, kus stringi mõõdikud olid väga kasulikud.
Juhtus nii, et meie “nutilaadijate” tarnija oli kolmas osapool, meil puudus kontroll arendusprotsessi ja nende laadijate poolt pakutava teabe üle.
Selle tulemusena ei olnud laadimis-API kaugeltki ideaalne, kuid peamine probleem oli see, et me ei saanud nende olekust alati aru.
Siin tuli appi Influx. Meieni jõudnud stringi oleku kirjutasime lihtsalt InfluxDB andmebaasi väljale ilma muudatusteta.
Mõnda aega jõudsid sinna ainult sellised väärtused nagu "online" ja "offline", mille põhjal kuvati teave meie administraatoripaneelil ja teatised saadeti Slackile. Kuid mingil hetkel hakkasid sinna ilmuma ka sellised väärtused nagu "lahti ühendatud".
Nagu hiljem selgus, saadeti see olek üks kord pärast ühenduse katkemist, kui laadija ei suutnud pärast teatud arvu katseid serveriga ühendust luua.
Seega, kui kasutaksime ainult fikseeritud väärtuste komplekti, ei pruugi me neid püsivara muudatusi õigel ajal näha.
Ja üldiselt pakuvad stringimõõdikud palju rohkem kasutusvõimalusi, nendesse saab salvestada praktiliselt igasugust teavet. Kuigi loomulikult peate ka seda tööriista hoolikalt kasutama.
Lisaks tavapärastele mõõdikutele salvestasime InfluxDB-s ka GPS-i asukohateavet. See oli meie administraatoripaneelil tõukerataste asukoha jälgimiseks uskumatult kasulik.
Tegelikult teadsime alati, kus ja milline roller parasjagu vaja on.
See oli meile tõukeratta otsimisel väga kasulik (vt järeldusi lõpus).
Infrastruktuuri monitooring
Lisaks rolleritele endile oli meil vaja jälgida ka kogu meie (üsna ulatuslikku) infrastruktuuri.
Väga üldine arhitektuur nägi välja umbes selline:
Kui tõstame esile puhta seirevirna, näeb see välja järgmine:
Tahaksime pilves kontrollida:
- Andmebaasid
- võtmesärk
- Mikroteenused
Kuna kõik meie pilveteenused asuvad Kubernetes, oleks tore koguda teavet selle oleku kohta.
Õnneks suudab Telegraf karbist välja võtta tohutul hulgal mõõdikuid Kubernetese klastri seisu kohta ja Chronograf pakub selleks kohe kauneid armatuurlaudu.
Peamiselt jälgisime kaunade jõudlust ja mälutarbimist. Kukkumise korral hoiatab Slackis.
Kubernetes on kaunade jälgimiseks kaks võimalust: DaemonSet ja Sidecar.
Mõlemat meetodit kirjeldatakse üksikasjalikult .
Kasutasime Telegrafi Sidecari ja lisaks mõõdikutele kogusime ka pod logisid.
Meie puhul tuli palkide kallal nokitseda. Hoolimata asjaolust, et Telegraf saab Dockeri API-st logisid tõmmata, tahtsime oma lõppseadmetega luua ühtse logide kogu ja konfigureerisime selle jaoks konteinerite jaoks syslogi. Võib-olla ei olnud see lahendus ilus, kuid selle töö üle ei kurtnud ja Chronografis olid logid hästi kuvatud.
Monitori jälgimine???
Lõpuks kerkis üles igivana küsimus seiresüsteemide jälgimisest, kuid õnneks või kahjuks ei jätkunud meil selleks lihtsalt aega.
Kuigi Telegraf saab lihtsalt saata oma mõõdikuid või koguda mõõdikuid InfluxDB andmebaasist kas samale Influxile või kuhugi mujale saatmiseks.
Järeldused
Milliseid järeldusi me piloodi tulemustest tegime?
Kuidas saate jälgida?
Esiteks vastas TICKi stäkk täielikult meie ootustele ja andis meile isegi rohkem võimalusi, kui esialgu eeldasime.
Kõik funktsioonid, mida vajasime, olid olemas. Kõik, mis me sellega tegime, toimis probleemideta.
Производительность
Tasuta versiooni TICKi virna põhiprobleemiks on skaleerimisvõimaluste puudumine. See ei olnud meie jaoks probleem.
Täpseid koormusandmeid/näitajaid me ei kogunud, küll aga kogusime andmeid korraga umbes 30 tõukerattalt.
Igaüks neist kogus üle kolme tosina mõõdiku. Samal ajal koguti seadmetelt logisid. Andmete kogumine ja saatmine toimus iga 10 sekundi järel.
Oluline on märkida, et pärast poolteisenädalast pilootiperioodi, mil suurem osa “lapsepõlveprobleemidest” sai parandatud ja olulisemad probleemid juba lahendatud, tuli meil vähendada andmete serverisse saatmise sagedust. 30 sekundit. See muutus vajalikuks, kuna liiklus meie LTE SIM-kaartidel hakkas kiiresti kaduma.
Suurema osa liiklusest neelasid logid, mõõdikud ise isegi 10-sekundilise intervalliga seda praktiliselt ei raisanud.
Selle tulemusena keelasime mõne aja pärast täielikult seadmete logide kogumise, kuna konkreetsed probleemid olid juba ilmsed isegi ilma pideva kogumiseta.
Mõnel juhul, kui logide vaatamine oli siiski vajalik, ühendasime lihtsalt WireGuardi kaudu VPN-i kaudu.
Lisan ka, et iga eraldiseisev keskkond oli üksteisest eraldatud ja ülalkirjeldatud koormus puudutas ainult tootmiskeskkonda.
Arenduskeskkonnas tõstsime esile eraldi InfluxDB eksemplari, mis jätkas andmete kogumist iga 10 sekundi järel ja meil ei tekkinud toimivusprobleeme.
TICK – ideaalne väikeste ja keskmiste projektide jaoks
Selle teabe põhjal järeldan, et TICK-pinn on ideaalne suhteliselt väikeste projektide jaoks või projektide jaoks, mis kindlasti ei eelda HighLoad'i.
Kui teil pole tuhandeid kaustasid või sadu masinaid, tuleb isegi üks InfluxDB eksemplar koormusega hästi toime.
Mõnel juhul võite olla rahul sissevoolureleega kui primitiivse kõrge saadavuse lahendusega.
Ja loomulikult ei takista keegi teil seadistamast "vertikaalset" skaleerimist ja lihtsalt eraldamast erinevaid servereid erinevat tüüpi mõõdikute jaoks.
Kui te pole kindel jälgimisteenuste eeldatavas koormuses või on/tuleb olema väga "raske" arhitektuur, ei soovita ma kasutada TICKi pinu tasuta versiooni.
Lihtne lahendus oleks muidugi ostmine - aga siin ei saa ma kuidagi kommenteerida, kuna ma ise pole peensustega kursis. Peale selle, et see on väga kallis ja kindlasti ei sobi väikefirmadele.
Sel juhul soovitaksin täna vaadata mõõdikute kogumist Victoria Metricsi kaudu ja logisid Loki abil.
Tõsi, ma teen taaskord reservatsiooni, et Loki/Grafana on palju vähem mugavad (oma suurema mitmekülgsuse tõttu) kui valmis TICK, kuid need on tasuta.
Oluline: kogu siin kirjeldatud teave kehtib Influx 1.8 versiooni kohta, hetkel on Influx 2.0 väljastamisel.
Kuigi mul pole olnud võimalust seda lahingutingimustes proovida ja täiustustest on raske järeldusi teha, on liides kindlasti veelgi paremaks muutunud, arhitektuur on lihtsustatud (ilma kapacitori ja kronografita),
ilmusid mallid ("tapja funktsioon" - ). Kuid kahjuks pole versioonil 2 hetkel seda võtmeasja, mille jaoks me esimese versiooni valisime - logikogu pole.
See funktsioon ilmub ka Influx 2.0-s, kuid me ei leidnud ühtegi tähtaega, isegi ligikaudseid.
Kuidas mitte teha IoT platvorme (nüüd)
Lõpuks, pärast pilootprojekti käivitamist, koostasime meie standarditele sobiva alternatiivi puudumisel ise oma täisväärtusliku IoT pinu.
Kuid hiljuti on see saadaval beetaversioonis — kahju, et teda ei olnud, kui projekti tegema hakkasime.
Oleme lõpptulemuse ja ise kokku pandud Ansible + TICK + WireGuardil põhineva platvormiga igati rahul. Kuid täna soovitaksin Balenaga lähemalt tutvuda, enne kui proovite ise oma IoT-platvormi luua.
Sest lõppkokkuvõttes suudab see teha enamiku meie tegemistest ning OpenBalena on tasuta ja avatud lähtekoodiga.
See juba teab, kuidas mitte ainult värskendusi saata, vaid ka VPN on juba sisse ehitatud ja kohandatud IoT keskkonnas kasutamiseks.
Ja just hiljuti avaldasid nad isegi oma , mis ühendub kergesti nende ökosüsteemiga.
Hei, aga kadunud roller?
Nii kadus tõukeratas "Ralph" jäljetult.
Jooksime kohe oma "administraatoripaneelil" kaarti vaatama, kus olid InfluxDB GPS-i mõõdikud.
Tänu seireandmetele tegime hõlpsalt kindlaks, et roller lahkus eelmisel päeval kella 21 paiku parklast, sõitis mingisse piirkonda umbes pool tundi ja seisis kella 00-ni mõne sakslase maja kõrval.
Pärast kella viit hommikul seireandmeid ei laekunud – see tähendas, et lisaaku oli täiesti tühjaks saanud või sai ründaja lõpuks aru, kuidas tõukerattalt nutikas riistvara eemaldada.
Vaatamata sellele kutsuti politsei siiski kohale, kus roller asus. Rollerit polnud.
See oli aga üllatunud ka majaomanikule, kes tegelikult sõitis eile õhtul selle rolleriga kontorist koju.
Nagu selgus, jõudis üks tugitöötajatest varahommikul kohale ja võttis rollerile järele, nähes, et selle lisaaku sai täielikult tühjaks ja viis selle (jalgsi) parklasse. Ja lisaaku ütles niiskuse tõttu üles.
Varastasime rolleri enda käest. Muide, ma ei tea, kuidas ja kes siis politseiasjaga probleemi lahendas, aga jälgimine toimis suurepäraselt...
Allikas: www.habr.com