Duela urtebete jarri genuen martxan sustapen proiektu baten bertsio pilotua .
Hasieran, Road-To-Barcelona deitzen zen proiektua, ββgero Road-To-Berlin bihurtu zen (hortaz, R2B pantaila-argazkietan), eta azkenean xRide deitzen zen.
Proiektuaren ideia nagusia hau izan zen: auto edo scooter alokairu zerbitzu zentralizatu bat eduki beharrean (scooter edo moto elektrikoez ari gara, ez kickscooter/scooter) alokairu deszentralizaturako plataforma bat egin nahi genuen. Aurkitu ditugun zailtasunei buruz .
Hasieran, proiektua autoetan zentratu zen, baina epeak, fabrikatzaileekiko komunikazio oso luzeak eta segurtasun murrizketa ugari zirela eta, scooter elektrikoak aukeratu ziren piloturako.
Erabiltzaileak iOS edo Android aplikazio bat instalatu zuen telefonoan, gustuko zuen scooterera hurbildu zen, eta ondoren telefonoak eta scooterrak peer-to-peer konexioa ezarri zuten, ETH trukatu zen eta erabiltzaileak ibilaldia hasi zezakeen scooterra piztuz. telefonoa. Bidaiaren amaieran, Ethereum erabiliz bidaia ordaintzea ere posible zen erabiltzailearen zorrotik telefonoan.
Patineteez gain, erabiltzaileak "kargagailu adimendunak" ikusten zituen aplikazioan, bisitatuz erabiltzaileak berak alda zezakeen egungo bateria gutxi balitz.
Hau da, oro har, gure pilotuaren itxura, iazko irailean abian jarri zen Alemaniako bi hiritan: Bonn eta Berlin.
Eta orduan, egun batean, Bonnen, goizean goiz, gure laguntza-taldea (patinetak funtzionatzen mantentzeko lekuan kokatua) abisua jaso zuen: patineteetako bat arrastorik gabe desagertu zen.
Nola aurkitu eta itzuli?
Artikulu honetan honi buruz hitz egingo dut, baina lehenik eta behin - nola eraiki genuen gure IoT plataforma eta nola kontrolatu genuen.
Zer eta zergatik kontrolatu: patineteak, azpiegiturak, kargaguneak?
Beraz, zer monitorizatu nahi genuen gure proiektuan?
Lehenik eta behin, scooter elektrikoak beraiek dira - scooter elektrikoak berak nahiko garestiak dira, ezin duzu horrelako proiektu bat abiarazi behar bezain prestatuta egon gabe; ahal bada, scooterrei buruzko ahalik eta informazio gehien bildu nahi duzu: haien kokapenari, karga-mailari buruz. , etab.
Horrez gain, gure IT azpiegituren egoera kontrolatu nahiko nuke: datu-baseak, zerbitzuak eta funtzionatzeko behar duten guztia. Halaber, beharrezkoa zen "kargagailu adimendunen" egoera kontrolatzea, bateriak apurtu edo agortzen baziren.
Scooters
Zeintzuk ziren gure patineteak eta zer jakin nahi genuen haiei buruz?
Lehenengo eta garrantzitsuena GPS koordenatuak dira, horiei esker non dauden eta nora mugitzen diren uler dezakegulako.
Hurrengoa bateriaren karga da, eta horri esker scooterren karga amaitzen ari dela zehaztu eta zukugailu bat bidali edo, gutxienez, erabiltzaileari abisatu.
Jakina, gure Hardware osagaiekin zer gertatzen den ere egiaztatu behar da:
- funtzionatzen du bluetooth-ak?
- GPS moduluak berak funtzionatzen du?
- Arazo bat ere izan dugu GPSak koordenatu okerrak bidali eta trabatu egin zezakeela, eta hori scooterren egiaztapen gehigarrien bidez bakarrik zehaztu zitekeen.
eta jakinarazi laguntzari ahalik eta azkarren arazoa konpontzeko
- Arazo bat ere izan dugu GPSak koordenatu okerrak bidali eta trabatu egin zezakeela, eta hori scooterren egiaztapen gehigarrien bidez bakarrik zehaztu zitekeen.
Eta azkenik: softwarearen egiaztapenak, OS eta prozesadoretik hasita, sare eta diskoen karga, gure espezifikoagoak diren moduluen egiaztapenekin amaituz (, ).
Hardware
Zein zen gure "burdina" zatia?
Ahalik eta denbora-tarte laburrena eta prototipo azkarraren beharra kontuan hartuta, osagaiak ezartzeko eta aukeratzeko aukerarik errazena aukeratu dugu - Raspberry Pi.
Rpi beraz gain, taula pertsonalizatu bat (guk garatu eta Txinatik agindu genuen azken irtenbidearen muntaketa prozesua bizkortzeko) eta osagai multzo bat - errele bat (scooter pizteko/itzaltzeko) genuen. bateria kargatzeko irakurgailua, modem bat, antenak. Hori guztia trinkoki paketatu zen "xRide kutxa" berezi batean.
Kontuan izan behar da, gainera, kutxa osoa power banku gehigarri batek elikatzen zuela, eta, aldi berean, scooterren bateria nagusiarekin elikatzen zen.
Horri esker, jarraipena eta scooterra piztea posible izan zen bidaia amaitu ondoren ere, bateria nagusia itzali baitzen pizte-giltza "off" posizioan jarri eta berehala.
Docker? Linux arrunta? eta hedapena
Itzuli gaitezen monitorizaziora, beraz, Raspberry - zer dugu?
Gailu fisikoetara osagaiak hedatzeko, eguneratzeko eta bidaltzeko prozesua bizkortzeko erabili nahi genuen lehen gauzetako bat Docker izan zen.
Zoritxarrez, azkar argi geratu zen RPi-n Docker-ek, funtzionatzen duen arren, gainkostu asko dituela, batez ere energia-kontsumoari dagokionez.
"Jatorrizko" OS erabiltzearen aldea, hain indartsua izan ez arren, nahikoa zen oraindik karga azkarregi galtzeko aukeraz kontuz izateko.
Bigarren arrazoia Node.js-en gure bazkideen liburutegietako bat izan zen (sic!) - Go/C/C++-n idatzi ez zen sistemaren osagai bakarra.
Liburutegiko egileek ez zuten denborarik izan lan-bertsio bat "jatorrizko" hizkuntzatan emateko.
Nodoa bera ez da soluzio dotoreena errendimendu baxuko gailuetarako, baizik eta liburutegia bera baliabide-gose handia zen.
Konturatu ginen, nahi bagenu ere, Docker erabiltzea gastu handiegia litzatekeela guretzat. Hautua jatorrizko OSaren alde egin zen eta zuzenean haren azpian lan egitea.
OS
Ondorioz, berriro ere aukerarik errazena aukeratu genuen OS gisa eta Raspbian erabili genuen (Debian Pi-rako).
Gure software guztia Go-n idazten dugu, beraz, gure sistemako hardware-agentearen modulua ere idatzi dugu Go-n.
Bera da GPSarekin, Bluetootharekin lan egiteaz, karga irakurtzeaz, scooterra pizteaz, etab.
Zabaldu
Galdera berehala sortu zen gailuei eguneraketak (OTA) emateko mekanismo bat ezartzeko beharrari buruz - bai gure agente/aplikazioaren eguneratzeak, bai OS/firmwarearen eguneratzeak (agentearen bertsio berriek nukleoaren eguneraketak behar baitituzte). edo sistemaren osagaiak, liburutegiak, etab.) .
Merkatuaren azterketa luze samarra egin ondoren, gailuari eguneraketak emateko irtenbide asko daudela ikusi zen.
swupd/SWUpdate/OSTree bezalako erabilgarritasun sinple samarrak, gehienbat eguneratze/abio bikoitzetara zuzendutako erabilgarritasunetatik Mender eta Balena bezalako plataformetaraino.
Lehenik eta behin, amaierako irtenbideak interesatzen zitzaizkigula erabaki genuen, beraz, aukera berehala plataformatan erori zen.
Oso kanpoan geratu zen bere balenaEngine barruan Docker bera erabiltzen duelako.
Baina ohartzen naiz, hala ere, haien produktua etengabe erabiltzen amaitu genuela SD txarteletako flash firmwarerako - horretarako erabilgarritasun sinple eta oso erosoa.
Hori dela eta, azkenean hautaketak erori egin ziren . Mender firmwarea muntatzeko, entregatzeko eta instalatzeko plataforma osoa da.
Orokorrean plataformak itxura bikaina du, baina aste eta erdi inguru behar izan dugu gure firmwarearen bertsio zuzena eraikitzeko mender builder erabiliz.
Eta zenbat eta gehiago murgildu bere erabileraren korapilatsuetan, orduan eta argiago geratu zen guztiz zabaltzeko genuena baino askoz denbora gehiago beharko genuela.
Ai, gure epe estuek Mender-en erabilera alde batera utzi eta are sinpleagoa aukeratzera behartu gintuzten.
Ansible
Gure egoeran irtenbiderik errazena Ansible erabiltzea zen. Jolas liburu pare bat nahikoa izan ziren hasteko.
Haien funtsa zen ostalaritik (CI zerbitzaria) ssh bidez konektatu genuela gure mugurdietara eta eguneraketak banatzen genituela.
Hasieran, dena erraza zen: gailuekin sare berean egon behar zenuen, isurketa Wi-Fi bidez egiten zen.
Bulegoan dozena bat test mugurdi zeuden sare berera konektatuta, gailu bakoitzak IP helbide estatiko bat zuen Ansible Inventory-n ere zehaztuta.
Ansible izan zen gure monitorizazio agentea amaierako gailuetara entregatu zuena
3G / LTE
Zoritxarrez, Ansible-ren erabilera-kasu honek garapen moduan bakarrik funtzionatu zezakeen benetako scooterrak izan baino lehen.
Scooters, ulertzen duzun bezala, ez daudelako Wi-Fi bideratzaile batera konektatuta eseri, etengabe sarearen bidez eguneratzeak zain.
Egia esan, scooter-ek ezin dute inolako konexiorik izan 3G/LTE mugikorra ez den beste konexiorik (eta orduan ere ez uneoro).
Horrek berehala arazo eta muga asko ezartzen ditu, hala nola, konexio-abiadura baxua eta komunikazio ezegonkorra.
Baina garrantzitsuena da 3G/LTE sare batean ezin garela sareari esleitutako IP estatiko batean soilik fidatu.
SIM txartel hornitzaile batzuek partzialki konpontzen dute; IP helbide estatikoak dituzten IoT gailuetarako diseinatutako SIM txartel bereziak ere badaude. Baina ez genuen horrelako SIM txarteletarako sarbiderik eta ezin izan genituen IP helbideak erabili.
Jakina, bazeuden IP helbideak edo zerbitzuen aurkikuntza nolabaiteko erregistroa egiteko ideiak nonbait, Consul bezalako nonbait, baina ideia horiek alde batera utzi behar izan genituen, gure probetan IP helbidea maizegi alda zitekeelako eta horrek ezegonkortasun handia ekarri zuen.
Hori dela eta, metrikak emateko erabilerarik erosoena ez litzateke tira eredua erabiltzea izango, non gailuetara joango ginateke beharrezkoak diren metriketarako, baizik eta push, metrikak gailutik zerbitzarira zuzenean entregatuz.
VPN
Arazo honen konponbide gisa, VPN aukeratu dugu, zehazki .
Bezeroak (scooters) sistemaren hasieran VPN zerbitzariarekin konektatu ziren eta haietara konektatu ahal izan ziren. Tunel hau eguneraketak emateko erabili zen.
Teorian, tunel bera erabil zitekeen monitorizaziorako, baina halako konexioa bultzada sinplea baino konplikatuagoa eta fidagarriagoa zen.
Hodeiko baliabideak
Azkenik, beharrezkoa da gure hodeiko zerbitzuak eta datu-baseak kontrolatzea, Kubernetes erabiltzen baitugu haietarako, hobe da klusterrean monitorizazioa hedatzea ahalik eta errazena izan dadin. Egokiena, erabiltzea , hedapenerako, kasu gehienetan erabiltzen dugu. Eta, noski, hodeia monitorizatzeko, scooterrentzako irtenbide berberak erabili behar dituzu.
Emana
Uf, badirudi deskribapena konpondu dugula, egin dezagun azkenean behar genuenaren zerrenda:
- Irtenbide azkarra, garapen prozesuan zehar monitorizazioa beharrezkoa baita
- Bolumena/kantitatea - neurri asko behar dira
- Erregistro bilketa beharrezkoa da
- Fidagarritasuna: datuak funtsezkoak dira abiarazteko arrakasta izateko
- Ezin duzu tira-eredua erabili - bultzada behar duzu
- Hardwarea ez ezik, hodeiaren monitorizazio bateratua behar dugu
Azken irudiak antzeko zerbait zuen
Pila hautatzea
Beraz, jarraipen-pila bat aukeratzeko galderaren aurrean geunden.
Lehenik eta behin, gure eskakizun guztiak aldi berean estaliko lituzkeen soluzio integralik osatuena bilatzen ari ginen, baina, aldi berean, erabilera gure beharretara egokitzeko nahikoa malgu izango zen. Hala ere, hardwareak, arkitekturak eta epeek muga asko ezarri zizkiguten.
Jarraipen-irtenbide ugari daude, sistema osoetatik hasita , edo eta Flota kudeatzeko prest dauden soluzioekin amaitzeko.
Hasieran, azken hau irtenbide aproposa iruditu zitzaigun, baina batzuek ez zuten monitorizazio osoa, beste batzuek doako bertsioen gaitasun oso mugatuak zituzten, eta beste batzuk, besterik gabe, ez zituzten gure "nahiak" estaltzen edo ez ziren nahikoa malguak gure eszenatoki egokitzeko. Batzuk, besterik gabe, zaharkituta daude.
Antzeko hainbat soluzio aztertu ondoren, azkar ondorioztatu genuen errazago eta azkarragoa izango zela antzeko pila bat geuk muntatzea. Bai, guztiz prest egindako Fleet kudeaketa plataforma zabaltzea baino pixka bat konplikatuagoa izango da, baina ez dugu konpromisorik hartu beharko.
Ia zalantzarik gabe, irtenbide ugarien artean, dagoeneko prest dagoen bat dago guztiz egokituko zitzaigun, baina gure kasuan askoz azkarragoa zen pila jakin bat gure kabuz muntatzea eta pertsonalizatzea "guretzat" baino. prest egindako produktuak probatzea.
Horrekin guztiarekin, ez ginen ahalegindu monitorizazio-plataforma oso bat geuk muntatzen, baizik eta "prest eginiko" pilarik funtzionalenak bilatzen ari ginen, malgutasunez konfiguratzeko gaitasunarekin soilik.
(B)ELK?
Benetan kontuan hartu zen lehen irtenbidea ELK pila ezaguna izan zen.
Izan ere, BELK deitu behar zaio, dena Beats-ekin hasten baita -
Jakina, ELK monitorizazioaren alorreko soluzio ospetsu eta indartsuenetako bat da, eta are gehiago erregistroak biltzeko eta prozesatzeko.
ELK erregistroak biltzeko eta Prometheus-etik lortutako neurketak epe luzerako biltegiratzeko erabiliko zela pentsatu genuen.
Bistaratzeko Grafan erabil dezakezu.
Izan ere, ELK pila berriak neurketak modu independentean bil ditzake (metricbeat), eta Kibanak ere bistaratu ditzake.
Hala ere, ELK hasieran erregistroetatik hazi zen eta orain arte neurketen funtzionaltasunak hainbat eragozpen larri ditu:
- Prometheus baino nabarmen motelagoa
- Prometheus baino askoz leku gutxiagotan integratzen da
- Zaila da haientzat alertak ezartzea
- Metrikek leku asko hartzen dute
- Kiban-en metrikekin aginte-panelak konfiguratzea Grafan-en baino askoz zailagoa da
Orokorrean, ELKn metrikak astunak dira eta oraindik ez dira beste soluzio batzuetan bezain erosoak, gaur egun Prometheus baino askoz gehiago baitaude: TSDB, Victoria Metrics, Cortex, etab., etab. Jakina, nahiko nuke berehalako soluzio osoa edukitzea, baina metricbeat-en kasuan konpromezu gehiegi zeuden.
Eta ELK pilak berak une zail batzuk ditu:
- Astuna da, batzuetan oso astuna ere bada datu kopuru handi samarra biltzen baduzu
- "Egosten jakin" behar duzu - eskalatu behar duzu, baina hau ez da hutsala.
- Doako bertsioa kendua - doako bertsioak ez du abisu arruntik, eta aukeraketa unean ez zegoen autentifikaziorik
Esan behar dut duela gutxi azken puntua hobetu dela eta gainera (autentifikazioa barne) prezioen eredua bera aldatzen hasi zen.
Baina irtenbide hau zabalduko genuen garaian, ez zegoen inolako alertarik.
Agian saiatu gintezke ElastAlert edo komunitateko beste irtenbide batzuk erabiliz zerbait eraikitzen, baina hala ere beste alternatiba batzuk kontuan hartzea erabaki genuen.
Loki - Grafana - Prometeo
Momentuz, irtenbide on bat Prometheus-en soilik oinarritutako neurketa-hornitzaile gisa oinarritutako monitorizazio pila bat eraikitzea izan daiteke, Loki erregistroetarako, eta bistaratzeko Grafana bera erabil dezakezu.
Zoritxarrez, proiektuaren salmenta-pilota hasi zen unean (19ko iraila-urria), Loki 0.3-0.4 beta bertsioan zegoen oraindik, eta garapena hasi zen unean ezin zen produkzio irtenbide gisa hartu. batere.
Oraindik ez dut esperientziarik Loki proiektu serioetan erabiltzeko, baina esan dezaket Promtailek (erregistroak biltzeko agentea) oso ondo funtzionatzen duela bai bare-metaletarako bai kubernetes-en leketarako.
TICK
Beharbada, ELK pilarako alternatibarik merezi duen (bakarra?) TICK pila bakarrik deitu daiteke orain - Telegraf, InfluxDB, Chronograf, Kapacitor.
Osagai guztiak zehatzago deskribatuko ditut jarraian, baina ideia orokorra hau da:
- Telegraf - neurriak biltzeko agentea
- InfluxDB - metrika datu-basea
- Kapacitor - alertak emateko denbora errealeko neurketa-prozesadorea
- Chronograf - bistaratzeko web panela
InfluxDB, Kapacitor eta Chronograf-entzat, horiek zabaltzeko erabili ditugun lema-taula ofizialak daude.
Kontuan izan behar da Influx 2.0-ren azken bertsioan (beta), Kapacitor eta Chronograf InfluxDBren parte bihurtu zirela eta jada ez direla bereizita.
Telegrafoa
egoera-makina batean metrikak biltzeko agente oso arina da.
Guztien kopuru handi bat kontrolatu dezake, batetik to
zerbitzaria .
Abantaila polit batzuk ditu:
- Azkarra eta arina (Go-n idatzia)
- Gutxieneko baliabideak jaten ditu
- Sakatu neurketak lehenespenez
- Beharrezko neurri guztiak biltzen ditu
- Sistemaren neurketak inolako ezarpenik gabe
- Hardware-neurriak, esate baterako, sentsoreen informazioa
- Oso erraza da zure neurriak gehitzea
- Plugin asko kutxatik kanpo
- Erregistroak biltzen ditu
Bultza-neurriak beharrezkoak zirenez guretzat, beste abantaila guztiak gehiketa atseginak baino gehiago ziren.
Agenteak berak erregistroak biltzea ere oso erosoa da, ez baitago erregistroak erregistratzeko utilitate gehigarriak konektatu beharrik.
Influx-ek erregistroekin lan egiteko esperientziarik erosoena eskaintzen du erabiltzen baduzu .
Telegraf, oro har, agente bikaina da metrikak biltzeko, nahiz eta ICK pilaren gainerakoa erabiltzen ez duzun.
Jende askok ELK eta denbora-serieko beste datu-base batzuekin gurutzatzen du erosotasunerako, ia edonon idatz ditzakeelako metrikak.
InfluxDB
InfluxDB TICK pilaren muin nagusia da, hau da, metriketarako denbora serieko datu-base bat.
Neurriez gain, Influx-ek erregistroak ere gorde ditzake, nahiz eta, funtsean, haren erregistroak neurri berberak diren, soilik ohiko zenbaki-adierazleen ordez, funtzio nagusia erregistroko testu-lerro batek egiten du.
InfluxDB Go-n ere idatzita dago eta badirudi askoz azkarrago exekutatzen dela ELK-rekin alderatuta gure klusterrean (ez da indartsuena).
Influx-en abantaila politetako bat datu-kontsultetarako API oso erosoa eta aberatsa ere sartuko litzateke, oso aktiboki erabili genuena.
Desabantailak - $$$ edo eskalatzea?
TICK pilak aurkitu dugun eragozpen bakarra du: hura maitea. Are gehiago.
Zer dauka doako bertsioak ez duen ordainpeko bertsioak?
Ulertu ahal izan genuenez, TICK pilaren ordainpeko bertsioaren eta doakoaren arteko desberdintasun bakarra eskalatzeko gaitasunak dira.
Hots, erabilgarritasun handiko kluster bat sor dezakezu hemen bakarrik .
HA osoa nahi baduzu, ordaindu edo makulu batzuk erabili behar dituzu. Komunitatearen irtenbide pare bat daude, adibidez konponbide eskudun bat dirudi, baina idatzita dago ez dela ekoizpenerako egokia, baita
- NATS bidez datuak ponpatzeko irtenbide sinple bat (eskalatu egin beharko da ere, baina hori konpondu daiteke).
Pena da, baina biak abandonatuta daudela dirudi - ez dago konpromiso berririk, suposatzen dut arazoa Influx 2.0-ren bertsio berriaren laster espero den kaleratzea dela, zeinetan gauza asko desberdinak izango diren (ez dago informaziorik eskalatzen oraindik).
Ofizialki doako bertsio bat dago - Izan ere, hau HA primitiboa da, baina oreka bidez soilik,
datu guztiak karga-orekatzailearen atzean dagoen InfluxDB instantzia guztietan idatziko baitira.
Batzuk ditu puntuak gainidazteko balizko arazoak eta aldez aurretik metriketarako oinarriak sortzeko beharra bezala
(InfluxDB-rekin lan arruntean automatikoki gertatzen dena).
Horrez gain , horrek behar ez dituzun neurri bikoiztuetarako (prozesatzeko eta biltegiratzeko) kostu gehigarria esan nahi du, baina ez dago bereizteko modurik.
Victoria Metrics?
Ondorioz, ordainpeko eskalatzeaz gain TICK pilarekin guztiz pozik geunden arren, InfluxDB datu-basea ordezkatu zezakeen doako soluziorik ba ote zegoen ikustea erabaki genuen, gainerako T_CK osagaiak utzita.
Denbora-serieen datu-base asko daude, baina itxaropentsuena Victoria Metrics da, hainbat abantaila ditu:
- Azkarra eta erraza, emaitzen arabera behintzat
- Cluster bertsio bat dago, eta orain kritika onak ere badaude
- Apurtu dezake
- InfluxDB protokoloa onartzen du
Ez genuen Victorian oinarritutako pila guztiz pertsonalizatu bat eraikitzeko asmorik eta itxaropen nagusia InfluxDB-ren ordezko gisa erabil genezakeela zen.
Zoritxarrez, hori ez da posible, InfluxDB protokoloa onartzen den arren, metrikak grabatzeko bakarrik funtzionatzen du - Prometheus APIa bakarrik dago eskuragarri "kanpoan", hau da, ezin izango da Chronograf ezarri.
Gainera, neurgailuetarako zenbakizko balioak soilik onartzen dira (neurri pertsonalizatuetarako kate-balioak erabili ditugu - gehiago atalean ).
Jakina, arrazoi beragatik, VM-k ezin ditu erregistroak gorde Influx-ek bezala.
Gainera, kontuan izan behar da irtenbide optimoa bilatzeko garaian Victoria Metrics oraindik ez zela hain ezaguna, dokumentazioa askoz txikiagoa zela eta funtzionaltasuna ahulagoa zela.
(Ez dut gogoan cluster bertsioaren eta zatiketaren deskribapen zehatzik).
Oinarrizko hautaketa
Ondorioz, piloturako oraindik InfluxDB nodo bakar batera mugatuko ginela erabaki zen.
Aukera hau egiteko hainbat arrazoi nagusi zeuden:
- Asko gustatu zitzaigun TICK pilaren funtzionaltasun osoa
- Dagoeneko zabaltzea lortu dugu eta oso ondo funtzionatu du
- Epeak amaitzen ari ziren eta ez zen denbora asko geratzen beste aukera batzuk probatzeko.
- Ez genuen espero halako zama astuna
Ez genuen scooter askorik pilotuaren lehen faserako, eta garapenean egindako probek ez zuten errendimendu-arazorik aurkitu.
Horregatik, proiektu honetarako Influx nodo bat nahikoa izango zela erabaki genuen eskalatzeko beharrik gabe (ikus ondorioak amaieran).
Pila eta oinarria erabaki dugu - orain TICK pilaren gainerako osagaiei buruz.
Kapacitor
Kapacitor TICK pilaren parte da, datu basean sartzen diren neurketak denbora errealean kontrola ditzakeen zerbitzu bat eta arauetan oinarritutako hainbat ekintza egin ditzake.
Oro har, anomalien balizko jarraipenerako eta ikaskuntza automatikorako tresna gisa kokatzen da (ez nago ziur funtzio hauek eskatzen direnik), baina erabileraren kasurik ezagunena ohikoagoa da: alertak.
Horrela erabili genuen jakinarazpenetarako. Scooter jakin bat lineaz kanpo geratzen zenean Slack alertak konfiguratu genituen, eta gauza bera egin zen kargagailu adimendunekin eta azpiegitura osagai garrantzitsuekin.
Horrek arazoei azkar erantzutea ahalbidetu zuen, baita dena normaltasunera itzuli zelako jakinarazpenak jasotzea ere.
Adibide sinple bat: gure "kutxa" elikatzeko bateria gehigarri bat apurtu egin da edo arrazoiren batengatik agortu egin da; berri bat instalatuz gero, scooterren funtzionaltasuna leheneratu dela dioen jakinarazpena jaso beharko genuke.
Influx 2.0-n Kapacitor DBren parte bihurtu zen
Kronografoa
Monitorizaziorako UI irtenbide desberdinak ikusi ditut, baina esan dezaket funtzionaltasun eta UX aldetik ez dela ezer Chronografekin alderatzen.
TICK pila erabiltzen hasi ginen, bitxia bada ere, Grafan web interfaze gisa.
Ez dut bere funtzionaltasuna deskribatuko; denek dakite edozer konfiguratzeko dituen aukera zabalak.
Hala ere, Grafana tresna guztiz unibertsala da oraindik, eta Chronograf Influx-ekin erabiltzeko diseinatuta dago batez ere.
Eta, jakina, horri esker, Chronograf-ek askoz funtzionalitate adimentsuagoa edo erosoagoa izan dezake.
Agian Chronograf-ekin lan egiteko erosotasun nagusia zure InfluxDB-ren barrualdea arakatu bidez ikus dezakezula da.
Badirudi Grafanak funtzionaltasun ia berdina duela, baina, egia esan, Chronograf-en panel bat konfiguratzea saguaren klik gutxi batzuekin egin daiteke (aldi berean hango bistaratzeari begiratuta), Grafanan oraindik ere lehenago edo beranduago izango duzu. JSON konfigurazioa editatzeko (noski Chronograf-ek eskuz konfiguratutako dashas igotzeko eta behar izanez gero JSON gisa editatzeko aukera ematen du - baina inoiz ez ditut ukitu behar izan UI-n sortu ondoren).
Kibanak askoz gaitasun aberatsagoak ditu haientzako aginte-panelak eta kontrolak sortzeko, baina eragiketa horietarako UX-a oso konplexua da.
Ulermen ona beharko da panel eroso bat sortzeko. Eta Chronograf aginteen funtzionaltasuna txikiagoa den arren, horiek egitea eta pertsonalizatzea askoz errazagoa da.
Aginte-panelak beraiek, estilo bisual atseginaz gain, ez dira Grafana edo Kibanako aginte-paneletatik desberdinak:
Hau da kontsulta-leihoaren itxura:
Garrantzitsua da kontuan izan, besteak beste, InfluxDB datu-baseko eremu motak ezagututa, kronografoak berak batzuetan automatikoki lagun zaitzakeela Kontsulta bat idazten edo batez besteko funtzioa zuzena aukeratzen.
Eta, jakina, Chronograf ahalik eta erosoena da erregistroak ikusteko. Honela dirudi:
Lehenespenez, Influx erregistroak syslog erabiltzeko egokituta daude eta, beraz, parametro garrantzitsu bat dute: larritasuna.
Goiko grafikoa bereziki erabilgarria da; bertan gertatzen diren akatsak ikus ditzakezu eta koloreak berehala erakusten du larritasuna handiagoa den.
Pare bat aldiz akats garrantzitsuak harrapatu ditugu horrela, azken asteko erregistroak ikustera joan eta erpin gorri bat ikusi dugu.
Noski, hobe da horrelako akatsen alertak ezartzea, horretarako dena geneukan eta.
Denbora batez ere aktibatu genuen hau, baina pilotua prestatzeko prozesuan akats dezente jasotzen ari ginen (LTE sarearen erabilgarritasuna bezalako sistemakoak barne), eta horrek Slack kanala ere "spam" egin zuen. asko, arazorik sortu gabe.onura handia.
Irtenbide zuzena akats mota horietako gehienak kudeatzea izango litzateke, haien larritasuna doitzea eta soilik alertak gaitzea.
Horrela, akats berriak edo garrantzitsuak soilik argitaratuko lirateke Slack-en. Besterik gabe, ez zegoen denbora nahikorik halako konfigurazio baterako epe estuak ikusita.
autentifikazio
Aipatzekoa da Chronograf-ek OAuth eta OIDC onartzen dituela autentifikazio gisa.
Hau oso erosoa da, zerbitzariari erraz erantsi eta SSO osoa sortzeko aukera ematen baitu.
Gure kasuan zerbitzaria zen β monitorizaziora konektatzeko erabiltzen zen, baina zerbitzari bera ere erabiltzen zen scooter-ak eta back-end-erako eskaerak autentifikatzeko.
"Administratzailea"
Deskribatuko dudan azken osagaia Vue-n norberak idatzitako "administrazio panela" da.
Funtsean, gure datu-baseetako, mikrozerbitzuetako eta InfluxDBko datu-neurrien datuak aldi berean bistaratzen dituen scooter-en informazioa bistaratzen duen zerbitzu autonomo bat da.
Horrez gain, administrazio-funtzio asko hara eraman ziren, hala nola, larrialdiko berrabiaraztea edo laguntza-taldearen blokeoa urrunetik irekitzea.
Mapak ere bazeuden. Dagoeneko aipatu dut Chronograf-en ordez Grafanarekin hasi ginela - Grafanarako mapak plugin moduan eskuragarri daudelako, eta horietan scooterren koordenatuak ikus genitzake. Zoritxarrez, Grafanarako mapen widgeten gaitasunak oso mugatuak dira, eta, ondorioz, askoz errazagoa izan zen zure web aplikazioa mapekin idaztea egun gutxitan, momentuan koordenatuak ikusteko ez ezik, bistaratzeko. scooter-ak egindako ibilbidea, mapan datuak iragazteko gai izatea, etab. (Arbel soil batean konfiguratu ezin izan dugun funtzionaltasun hori guztia).
Dagoeneko Influx-en abantailetako bat zure neurriak erraz sortzeko gaitasuna da.
Horri esker, hainbat eszenatokitarako erabil daiteke.
Bertan informazio baliagarri guztia erregistratzen saiatu gara: bateriaren karga, blokeoaren egoera, sentsoreen errendimendua, bluetooth, GPSa eta beste hainbat osasun egiaztapen.
Hori guztia administrazio panelean erakutsi dugu.
Jakina, guretzat irizpiderik garrantzitsuena scooterren funtzionamendu-egoera izan zen - hain zuzen ere, Influx-ek hori bera egiaztatzen du eta "argi berdeekin" erakusten du Nodoen atalean.
Hau funtzioak egiten du β gure kutxaren errendimendua ulertzeko eta Slack-era alerta horiek bidaltzeko erabili dugu.
Bide batez, patinetei The Simpsons-eko pertsonaien izenen arabera jarri genien izena - oso erosoa zen elkarrengandik bereiztea.
Eta, oro har, dibertigarriagoa izan zen horrela. βGuys, Smithers dead!β bezalako esaldiak etengabe entzuten ziren.
Kateen neurketak
Garrantzitsua da InfluxDB-k balio numerikoak ez ezik, Victoria Metrics-en kasua den bezala.
Badirudi hori ez dela hain garrantzitsua - azken finean, erregistroez gain, edozein metrika gorde daiteke zenbaki moduan (gehitu besterik ez egoera ezagunetarako mapak - enum moduko bat)?
Gure kasuan, gutxienez katearen neurketak oso erabilgarriak ziren eszenatoki bat zegoen.
Gertatu zen gure "kargagailu adimendunen" hornitzailea hirugarren bat zela, ez genuen garapen-prozesuaren eta kargagailu horiek eman zezaketen informazioaren gaineko kontrolik.
Ondorioz, kargatzeko APIa idealetik urrun zegoen, baina arazo nagusia beti ezin genuela haien egoera ulertu.
Horra etorri zen Influx erreskatatu. Besterik gabe, InfluxDB datu-basearen eremuan iritsi zaigun katearen egoera aldaketarik gabe idatzi dugu.
Denbora batez, "online" eta "offline" bezalako balioak bakarrik iritsi ziren, gure administrazio-panelean informazioa bistaratzen zen eta jakinarazpenak Slack-era bidali ziren. Hala ere, noizbait, "deskonektatua" bezalako balioak ere agertzen hasi ziren bertan.
Geroago ikusi zenez, egoera hau behin bidali zen konexioa galdu ondoren, kargatzaileak saiakera kopuru jakin baten ondoren zerbitzariarekin konexiorik ezarri ezin bazuen.
Horrela, balio-multzo finko bat bakarrik erabiliko bagenu, baliteke firmwarean aldaketa hauek momentu egokian ez ikustea.
Eta, oro har, kate-neurriek askoz ere aukera gehiago eskaintzen dituzte erabiltzeko; ia edozein informazio graba dezakezu bertan. Nahiz eta, noski, tresna hau kontu handiz erabili behar duzun.
Ohiko neurketez gain, GPS kokapenari buruzko informazioa ere erregistratu dugu InfluxDB-n. Hau oso erabilgarria izan zen gure administrazio panelean scooterren kokapena kontrolatzeko.
Izan ere, beti bagenekien non eta zein scooter zegoen behar genuen momentuan.
Hau oso baliagarria izan zitzaigun scooter baten bila geundela (ikus ondorioak amaieran).
Azpiegituren jarraipena
Scooterrez gain, gure azpiegitura osoa (zabal samarra) kontrolatu behar genuen.
Oso arkitektura orokorrak honelako itxura zuen:
Jarraipen-pila hutsa nabarmentzen badugu, honelakoa izango da:
Hodeian egiaztatu nahi genukeena hau da:
- Datu baseak
- giltza kapaia
- Mikrozerbitzuak
Gure hodeiko zerbitzu guztiak Kubernetesen daudenez, ondo legoke haren egoerari buruzko informazioa biltzea.
Zorionez, Telegraf-ek kutxatik kanpo Kubernetes klusterraren egoerari buruzko metrika ugari bil ditzake, eta Chronograf-ek berehala eskaintzen ditu horretarako panel ederrak.
Batez ere poden errendimendua eta memoria-kontsumoa kontrolatu ditugu. Erorketa izanez gero, alertak Slack-en.
Kubernetesen lekak jarraitzeko bi modu daude: DaemonSet eta Sidecar.
Bi metodoak zehatz-mehatz deskribatzen dira .
Telegraf Sidecar erabili dugu eta, metrikez gain, pod erregistroak bildu ditugu.
Gure kasuan, enborrak txikitu behar izan ditugu. Telegraf-ek Docker APItik erregistroak atera ditzakeen arren, gure amaierako gailuekin erregistro-bilduma uniforme bat izan nahi genuen eta horretarako edukiontzietarako syslog konfiguratu nahi genuen. Beharbada, irtenbide hau ez zen ederra, baina ez zen bere lanaren inguruko kexarik egon eta erregistroak ongi bistaratu ziren Chronograf-en.
Monitorearen jarraipena???
Azkenean, monitorizazio sistemen jarraipenaren galdera zaharra sortu zen, baina zorionez, edo zoritxarrez, ez genuen horretarako denbora nahikorik izan.
Telegraf-ek bere neurriak erraz bidal ditzakeen edo InfluxDB datu-basetik metrikak bil ditzakeen arren, Influx berera edo beste nonbaitera bidaltzeko.
Findings
Zein ondorio atera ditugu pilotuaren emaitzetatik?
Nola egin dezakezu jarraipena?
Lehenik eta behin, TICK pilak guztiz bete zituen gure itxaropenak eta hasieran espero genuena baino are aukera gehiago eman zizkigun.
Behar genituen funtzionalitate guztiak presente zeuden. Berarekin egiten genuen guztia arazorik gabe funtzionatu zuen.
produktibitatea
Doako bertsioan TICK pilaren arazo nagusia eskalatzeko gaitasunik eza da. Hau ez zen guretzat arazo bat.
Ez dugu karga datu/zifra zehatzak bildu, baina aldi berean 30 scooter ingururen datuak bildu ditugu.
Horietako bakoitzak hiru dozena metrika baino gehiago bildu zituen. Aldi berean, gailuen erregistroak bildu ziren. Datuen bilketa eta bidalketa 10 segundotan behin egin zen.
Garrantzitsua da aipatzea pilotuaren aste eta erdi igaro ondoren, "haurtzaroko arazoen" zatirik handiena zuzendu eta arazo garrantzitsuenak jada konponduta zeudenean, zerbitzariari datuak bidaltzeko maiztasuna murriztu behar izan genuela. 30 segundo. Hau beharrezkoa bihurtu zen gure LTE SIM txarteletako trafikoa azkar desagertzen hasi zelako.
Trafikoaren zatirik handiena erregistroek kontsumitzen zuten; neurketak berak, nahiz eta 10 segundoko tartea izan, ia ez zuten alferrik galdu.
Ondorioz, denbora pixka bat igaro ondoren, gailuetako erregistroen bilketa guztiz desgaitu genuen, arazo zehatzak jada nabariak baitziren etengabeko bilketarik gabe ere.
Zenbait kasutan, erregistroak ikustea oraindik beharrezkoa bazen, WireGuard bidez konektatu ginen VPN bidez.
Gainera, gehituko dut geneukan ingurune bakoitza elkarrengandik bereizita zegoela eta goian deskribatutako karga produkzio ingurunerako soilik zela garrantzitsua.
Garapen-ingurunean, 10 segundoz behin datuak biltzen jarraitu zuen InfluxDB instantzia bereizi bat sortu genuen eta ez genuen errendimendu-arazorik izan.
TICK - proiektu txiki eta ertainetarako aproposa
Informazio honetan oinarrituta, TICK pila aproposa dela HighLoad espero ez duten proiektu edo proiektu nahiko txikietarako.
Milaka pod edo ehunka makina ez badituzu, InfluxDB instantzia batek ere ondo kudeatuko du karga.
Zenbait kasutan, Influx Relay-rekin pozik egon zaitezke erabilgarritasun handiko soluzio primitibo gisa.
Eta, noski, inork ez zaitu eragozten eskalatze "bertikala" konfiguratzea eta zerbitzari desberdinak esleitzea neurketa mota desberdinetarako.
Monitorizazio-zerbitzuetan espero den kargaz ziur ez bazaude, edo arkitektura oso "astuna" izango duzula/izango duzula ziurtatzen baduzu, ez nuke gomendatuko TICK pilaren doako bertsioa erabiltzea.
Jakina, irtenbide sinple bat erostea izango litzateke - baina hemen ezin dut nolabait komentatu, nik neuk ez ditudalako sotiltasunekin ezagutzen. Gainera, oso garestia dela eta, zalantzarik gabe, ez da enpresa txikientzat egokia.
Kasu honetan, gaur, Victoria Metrics eta log-en bidez neurketak biltzea gomendatuko nuke Loki erabiliz.
Egia da, berriro ere erreserba bat egingo dut Loki/Grafana prest egindako TICK baino askoz erosoagoak direla (bere aldakortasun handiagoa dela eta), baina doakoak dira.
Garrantzitsua da: hemen deskribatutako informazio guztia garrantzitsua da Influx 1.8 bertsiorako, momentu honetan Influx 2.0 kaleratzear dago.
Borroka baldintzetan probatzeko aukerarik izan ez dudan arren eta hobekuntzei buruzko ondorioak ateratzea zaila den arren, interfazea zalantzarik gabe are hobea bihurtu da, arkitektura sinplifikatu egin da (kapacitor eta kronograforik gabe),
txantiloiak agertu ziren ("hiltzaile funtzioa" - ). Baina, zoritxarrez, momentuz, 2. bertsioak ez du lehen bertsioa aukeratu genuen gakoa - ez dago erregistro-bildumarik.
Funtzionalitate hau Influx 2.0-n ere agertuko da, baina ezin izan dugu eperik aurkitu, ezta gutxi gorabeherakoak ere.
Nola ez egin IoT plataformak (orain)
Azkenean, pilotua abiarazi ondoren, geuk muntatu genuen gure IoT pila osoa, gure estandarren arabera egokia den alternatibarik ezean.
Hala ere, duela gutxi Beta bertsioan dago eskuragarri β Pena da proiektua egiten hasi ginenean ez egotea.
Guztiz pozik gaude azken emaitzarekin eta guk geuk muntatu dugun Ansible + TICK + WireGuard-en oinarritutako plataformarekin. Baina gaur, Balena gertutik aztertzea gomendatuko nuke zure IoT plataforma zeure burua eraikitzen saiatu aurretik.
Azken finean guk egin dugunaren gehiengoa egin dezakeelako, eta OpenBalena doakoa eta kode irekikoa da.
Dagoeneko badaki eguneraketak bidaltzen ez ezik, VPN bat ere dagoeneko eraikita eta egokituta dago IoT ingurunean erabiltzeko.
Eta duela gutxi, berea ere kaleratu dute , haien ekosistemarekin erraz konektatzen dena.
Aizu, zer gertatzen da falta den patinetearekin?
Beraz, patinetea, "Ralph", arrastorik gabe desagertu zen.
Berehala korrika egin genuen gure "administrazio-panelean" mapa begiratzera, InfluxDB-ko GPS metrics datuekin.
Jarraipen datuei esker, erraz zehaztu genuen scooter-a joan den egunean 21:00ak aldera irten zela aparkalekutik, ordu erdi inguru ingurura joan zela eta goizeko 5ak arte aparkatu zuela Alemaniako etxe baten ondoan.
5:XNUMXetatik aurrera, ez zen monitorizazio-daturik jaso; horrek esan nahi zuen bateria osagarria guztiz deskargatuta zegoela edo erasotzaileak azkenean asmatu zuen scooterreko hardware adimenduna nola kendu.
Hala eta guztiz ere, Poliziari dei egin zioten oraindik scooter-a zegoen helbidera. Scooter ez zegoen han.
Hala ere, etxearen jabea ere harrituta geratu zen honek, bart gauean scooter hau bulegotik etxera joan baitzen.
Gertatu zenez, laguntza-langileetako bat goizean goiz iritsi zen eta scooter-a hartu zuen, bere bateria gehigarria guztiz deskargatuta zegoela ikusita eta (oinez) aparkalekuraino eraman zuen. Eta bateria gehigarriak huts egin zuen hezetasunaren ondorioz.
Patinetea lapurtu genion geure buruari. Bide batez, ez dakit nola eta nork konpondu zuen orduan polizia auziarekin arazoa, baina jarraipena primeran funtzionatu zuen...
Iturria: www.habr.com