Një vit më parë ne lançuam një version pilot të një projekti promovues për .
Fillimisht, projekti u quajt Road-To-Barcelona, më vonë u bë Road-To-Berlin (prandaj R2B në pamjet e ekranit), dhe në fund u quajt xRide.
Ideja kryesore e projektit ishte kjo: në vend që të kishim një shërbim të centralizuar të marrjes me qira të makinave ose skuterëve (po flasim për skuterë të njohur si motoçikleta elektrike, jo kickscooter/skuter) ne donim të krijonim një platformë për qira të decentralizuar. Për vështirësitë që kemi hasur .
Fillimisht, projekti u fokusua në makina, por për shkak të afateve, komunikimeve jashtëzakonisht të gjata me prodhuesit dhe një numri të madh të kufizimeve të sigurisë, skuterët elektrikë u zgjodhën për pilot.
Përdoruesi instaloi një aplikacion iOS ose Android në telefon, iu afrua skuterit që i pëlqente, pas së cilës telefoni dhe skuteri vendosën një lidhje peer-to-peer, ETH u shkëmbye dhe përdoruesi mund të fillonte udhëtimin duke ndezur skuterin nëpërmjet telefoni. Në fund të udhëtimit, ishte gjithashtu e mundur të paguani për udhëtimin duke përdorur Ethereum nga portofoli i përdoruesit në telefon.
Përveç skuterëve, përdoruesi pa në aplikacion edhe “karikues inteligjentë”, duke vizituar të cilët përdoruesi mund ta ndërronte vetë baterinë aktuale nëse ishte e ulët.
Kështu dukej në përgjithësi piloti ynë, i nisur në shtator të vitit të kaluar në dy qytete gjermane: Bon dhe Berlin.
Dhe pastaj, një ditë, në Bonn, herët në mëngjes, ekipi ynë mbështetës (i vendosur në vend për të mbajtur skuterët në gjendje pune) u alarmua: një nga skuterët ishte zhdukur pa lënë gjurmë.
Si ta gjeni dhe ta ktheni?
Në këtë artikull do të flas për këtë, por së pari - për mënyrën se si e ndërtuam platformën tonë IoT dhe si e monitoruam atë.
Çfarë dhe pse të monitoroni: skuterët, infrastruktura, stacionet e karikimit?
Pra, çfarë donim të monitoronim në projektin tonë?
Para së gjithash, këto janë vetë skuterët - vetë skuterët elektrikë janë mjaft të shtrenjtë, nuk mund të nisni një projekt të tillë pa u përgatitur mjaftueshëm; nëse është e mundur, dëshironi të grumbulloni sa më shumë informacion që të jetë e mundur për skuterët: për vendndodhjen e tyre, nivelin e karikimit , etj.
Për më tepër, unë do të doja të monitoroja gjendjen e infrastrukturës sonë të TI - bazat e të dhënave, shërbimet dhe gjithçka që u nevojitet për të punuar. Ishte gjithashtu e nevojshme të monitorohej statusi i "karikuesve inteligjentë", në rast se prisheshin ose mbaronin bateritë e plota.
Skuterë
Cilat ishin skuterat tanë dhe çfarë donim të dinim rreth tyre?
Gjëja e parë dhe më e rëndësishme janë koordinatat GPS, pasi falë tyre mund të kuptojmë se ku janë dhe ku po lëvizin.
Tjetra është ngarkimi i baterisë, falë së cilës mund të përcaktojmë që karikimi i skuterëve po i vjen fundi dhe të dërgojmë një shtrydhëse frutash ose të paktën të paralajmërojmë përdoruesin.
Sigurisht, është gjithashtu e nevojshme të kontrolloni se çfarë po ndodh me komponentët tanë të harduerit:
- funksionon bluetooth?
- a funksionon vetë moduli GPS?
- Ne gjithashtu patëm një problem me faktin se GPS mund të dërgonte koordinata të pasakta dhe të ngecte, dhe kjo mund të përcaktohet vetëm nga kontrolle shtesë në skuter,
dhe njoftoni mbështetjen sa më shpejt të jetë e mundur për të zgjidhur problemin
- Ne gjithashtu patëm një problem me faktin se GPS mund të dërgonte koordinata të pasakta dhe të ngecte, dhe kjo mund të përcaktohet vetëm nga kontrolle shtesë në skuter,
Dhe së fundi: kontrollet e softuerit, duke filluar me OS dhe procesorin, rrjetin dhe ngarkimin e diskut, duke përfunduar me kontrollet e moduleve tona që janë më specifike për ne (, ).
Hardware
Cila ishte pjesa jonë "e hekurt"?
Duke marrë parasysh kornizën kohore më të shkurtër të mundshme dhe nevojën për prototipim të shpejtë, ne zgjodhëm opsionin më të lehtë për zbatimin dhe përzgjedhjen e komponentëve - Raspberry Pi.
Përveç vetë Rpi, ne kishim një tabelë me porosi (të cilën ne vetë e zhvilluam dhe e porositëm nga Kina për të shpejtuar procesin e montimit të zgjidhjes përfundimtare) dhe një grup përbërësish - një stafetë (për të ndezur/fikur skuterin), një lexues ngarkimi baterie, një modem, antena. E gjithë kjo u paketua në mënyrë kompakte në një "kuti xRide" të veçantë.
Duhet të theksohet gjithashtu se e gjithë kutia ushqehej nga një bankë shtesë e energjisë, e cila nga ana e saj mundësohej nga bateria kryesore e skuterit.
Kjo bëri të mundur përdorimin e monitorimit dhe ndezjen e skuterit edhe pas përfundimit të udhëtimit, pasi bateria kryesore u fiket menjëherë pas kthimit të çelësit të ndezjes në pozicionin "off".
Doker? Linux i thjeshtë? dhe vendosjen
Le të kthehemi te monitorimi, pra Raspberry - çfarë kemi?
Një nga gjërat e para që donim të përdornim për të shpejtuar procesin e vendosjes, përditësimit dhe dërgimit të komponentëve në pajisjet fizike ishte Docker.
Fatkeqësisht, shpejt u bë e qartë se Docker në RPi, megjithëse funksionon, ka shumë shpenzime, veçanërisht për sa i përket konsumit të energjisë.
Dallimi në përdorimin e sistemit operativ "vendas", megjithëse jo aq i fortë, ishte ende i mjaftueshëm që ne të jemi të kujdesshëm ndaj mundësisë së humbjes së ngarkesës shumë shpejt.
Arsyeja e dytë ishte një nga bibliotekat tona partnere në Node.js (sic!) - i vetmi komponent i sistemit që nuk ishte shkruar në Go/C/C++.
Autorët e bibliotekës nuk patën kohë të siguronin një version pune në asnjë nga gjuhët "amtare".
Jo vetëm që vetë nyja nuk është zgjidhja më elegante për pajisjet me performancë të ulët, por vetë biblioteka ishte shumë e uritur për burime.
Ne e kuptuam se, edhe nëse do të donim, përdorimi i Docker do të ishte një shpenzim i tepërt për ne. Zgjedhja u bë në favor të sistemit operativ vendas dhe duke punuar drejtpërdrejt nën të.
OS
Si rezultat, ne, përsëri, zgjodhëm opsionin më të thjeshtë si OS dhe përdorëm Raspbian (ndërtimi i Debian për Pi).
Ne e shkruajmë të gjithë softuerin tonë në Go, kështu që ne kemi shkruar gjithashtu modulin kryesor të agjentit të harduerit në sistemin tonë në Go.
Është ai që është përgjegjës për të punuar me GPS, Bluetooth, leximin e karikimit, ndezjen e skuterit, etj.
Vendosni
Pyetja u ngrit menjëherë në lidhje me nevojën për të zbatuar një mekanizëm për dërgimin e përditësimeve në pajisjet (OTA) - si përditësimet për vetë agjentin/aplikacionin tonë, ashtu edhe përditësimet në vetë OS/firmware (pasi versionet e reja të agjentit mund të kërkojnë përditësime në kernel ose komponentët e sistemit, bibliotekat, etj.) .
Pas një analize mjaft të gjatë të tregut, doli se ka mjaft zgjidhje për dërgimin e përditësimeve në pajisje.
Nga programe relativisht të thjeshta, kryesisht të orientuara drejt përditësimit/boot-it të dyfishtë si swupd/SWUpdate/OSTree deri te platformat e plota si Mender dhe Balena.
Para së gjithash, vendosëm që ishim të interesuar për zgjidhje nga fundi në fund, kështu që zgjedhja ra menjëherë në platforma.
vetë u përjashtua për shkak të faktit se në fakt përdor të njëjtin Docker brenda balenaEngine-it të tij.
Por unë vërej se pavarësisht kësaj, ne përfunduam duke përdorur vazhdimisht produktin e tyre për firmware flash në kartat SD - një mjet i thjeshtë dhe jashtëzakonisht i përshtatshëm për këtë.
Prandaj, në fund zgjedhja ra . Mender është një platformë e plotë për montimin, dërgimin dhe instalimin e firmuerit.
Në përgjithësi, platforma duket e mrekullueshme, por na u deshën rreth një javë e gjysmë vetëm për të ndërtuar versionin e saktë të firmuerit tonë duke përdorur ndërtuesin mender.
Dhe sa më shumë të zhytemi në ndërlikimet e përdorimit të tij, aq më shumë u bë e qartë se për ta vendosur plotësisht atë do të na duhej shumë më tepër kohë nga sa kishim.
Mjerisht, afatet tona të ngushta bënë që ne u detyruam të braktisnim përdorimin e Mender dhe të zgjidhnim një edhe më të thjeshtë.
Ansible
Zgjidhja më e thjeshtë në situatën tonë ishte përdorimi i Ansible. Mjaftojnë disa libra lojërash për të filluar.
Thelbi i tyre ishte se ne thjesht u lidhëm nga hosti (serveri CI) përmes ssh me mjedrat tona dhe u shpërndamë atyre përditësime.
Në fillim gjithçka ishte e thjeshtë - duhej të ishe në të njëjtin rrjet me pajisjet, derdhja bëhej përmes Wi-Fi.
Në zyrë kishte thjesht një duzinë mjedra testuese të lidhura në të njëjtin rrjet, çdo pajisje kishte një adresë IP statike të specifikuar gjithashtu në Inventarin Ansible.
Ishte Ansible që dërgoi agjentin tonë të monitorimit tek pajisjet fundore
3G / LTE
Fatkeqësisht, ky rast përdorimi për Ansible mund të funksiononte vetëm në modalitetin e zhvillimit përpara se të kishim skuterë aktualë.
Sepse skuterët, siç e kuptoni, nuk ulen të lidhur me një ruter Wi-Fi, duke pritur vazhdimisht për përditësime përmes rrjetit.
Në realitet, skuterët nuk mund të kenë asnjë lidhje tjetër përveç celularit 3G/LTE (edhe atëherë jo gjatë gjithë kohës).
Kjo menjëherë imponon shumë probleme dhe kufizime, si shpejtësia e ulët e lidhjes dhe komunikimi i paqëndrueshëm.
Por gjëja më e rëndësishme është se në një rrjet 3G/LTE nuk mund të mbështetemi thjesht në një IP statike të caktuar në rrjet.
Kjo zgjidhet pjesërisht nga disa ofrues të kartave SIM; madje ka karta SIM speciale të dizajnuara për pajisjet IoT me adresa IP statike. Por ne nuk kishim akses në karta të tilla SIM dhe nuk mund të përdornim adresat IP.
Natyrisht, kishte ide për të bërë një lloj regjistrimi të adresave IP ose zbulimi i shërbimit diku si Konsulli, por ne duhej të braktisnim ide të tilla, pasi në testet tona adresa IP mund të ndryshonte shumë shpesh, gjë që çoi në paqëndrueshmëri të madhe.
Për këtë arsye, përdorimi më i përshtatshëm për dërgimin e metrikës nuk do të ishte përdorimi i modelit të tërheqjes, ku do të shkonim te pajisjet për matjet e nevojshme, por do të shtynim, duke dërguar metrikë nga pajisja direkt në server.
VPN
Si zgjidhje për këtë problem, ne zgjodhëm VPN - në mënyrë specifike .
Klientët (skuterët) në fillim të sistemit u lidhën me serverin VPN dhe mundën të lidhen me ta. Ky tunel u përdor për të dhënë përditësime.
Në teori, i njëjti tunel mund të përdorej për monitorim, por një lidhje e tillë ishte më e ndërlikuar dhe më pak e besueshme sesa shtytja e thjeshtë.
Burimet e resë
Së fundmi, është e nevojshme të monitorohen shërbimet tona cloud dhe bazat e të dhënave, pasi ne përdorim Kubernetes për to, në mënyrë ideale që vendosja e monitorimit në grup të jetë sa më e thjeshtë. Në mënyrë ideale, duke përdorur , pasi për vendosje, ne e përdorim atë në shumicën e rasteve. Dhe, sigurisht, për të monitoruar renë, duhet të përdorni të njëjtat zgjidhje si për vetë skuterët.
E dhënë
Phew, duket se e kemi rregulluar përshkrimin, le të bëjmë një listë të asaj që na duheshin në fund:
- Një zgjidhje e shpejtë, pasi monitorimi është i nevojshëm tashmë gjatë procesit të zhvillimit
- Vëllimi/sasia – nevojiten shumë metrikë
- Kërkohet mbledhja e regjistrave
- Besueshmëria - të dhënat janë kritike për të nisur suksesin
- Ju nuk mund të përdorni modelin e tërheqjes - keni nevojë për shtytje
- Ne kemi nevojë për monitorim të unifikuar jo vetëm të harduerit, por edhe të cloud
Imazhi përfundimtar dukej diçka si kjo
Zgjedhja e stivës
Pra, ne u përballëm me pyetjen e zgjedhjes së një pirg monitorimi.
Para së gjithash, ne po kërkonim zgjidhjen më të plotë gjithëpërfshirëse që do të mbulonte njëkohësisht të gjitha kërkesat tona, por në të njëjtën kohë do të ishte mjaft fleksibël për të përshtatur përdorimin e saj sipas nevojave tona. Megjithatë, ne kishim shumë kufizime të vendosura mbi ne nga hardueri, arkitektura dhe afatet.
Ka një larmi të madhe zgjidhjesh monitorimi, duke filluar me sisteme të plota si , ose dhe duke përfunduar me zgjidhje të gatshme për menaxhimin e Flotës.
Fillimisht, kjo e fundit dukej si një zgjidhje ideale për ne, por disa nuk kishin monitorim të plotë, të tjerë kishin aftësi shumë të kufizuara të versioneve falas dhe të tjerët thjesht nuk mbulonin “dëshirat” tona ose nuk ishin mjaft fleksibël për t'iu përshtatur skenarëve tanë. Disa janë thjesht të vjetëruara.
Pas analizimit të një numri zgjidhjesh të ngjashme, shpejt arritëm në përfundimin se do të ishte më e lehtë dhe më e shpejtë të mblidhnim vetë një pirg të ngjashëm. Po, do të jetë pak më e komplikuar sesa vendosja e një platforme plotësisht të gatshme të menaxhimit të Flotës, por ne nuk do të kemi nevojë të bëjmë kompromise.
Pothuajse me siguri, në të gjithë bollëkun e madh të zgjidhjeve, ekziston tashmë një e gatshme që do të na përshtatej plotësisht, por në rastin tonë ishte shumë më e shpejtë të mblidhnim vetë një pirg të caktuar dhe ta personalizonim "për veten" sesa testimi i produkteve të gatshme.
Me gjithë këtë, ne nuk u përpoqëm të mblidhnim vetë një platformë të tërë monitorimi, por po kërkonim pirgjet më funksionale "të gatshme", vetëm me aftësinë për t'i konfiguruar ato në mënyrë fleksibël.
(B) ELK?
Zgjidhja e parë që u konsiderua në të vërtetë ishte rafti i mirënjohur ELK.
Në fakt duhet të quhet BELK, sepse gjithçka fillon me Beats -
Sigurisht, ELK është një nga zgjidhjet më të famshme dhe më të fuqishme në fushën e monitorimit, e aq më tepër në mbledhjen dhe përpunimin e regjistrave.
Ne synonim që ELK të përdoret për të mbledhur regjistrat dhe si dhe për ruajtjen afatgjatë të matjeve të marra nga Prometheus.
Për vizualizim mund të përdorni Grafan.
Në fakt, grupi i ri ELK mund të mbledhë metrikë në mënyrë të pavarur (metricbeat), dhe Kibana gjithashtu mund t'i shfaqë ato.
Por megjithatë, ELK fillimisht u rrit nga regjistrat dhe deri më tani funksionaliteti i metrikës ka një numër të metash serioze:
- Shumë më i ngadalshëm se Prometeu
- Integrohet në shumë më pak vende se Prometheus
- Është e vështirë të vendosësh sinjalizime për ta
- Metrikat zënë shumë hapësirë
- Vendosja e tabelave të kontrollit me metrikë në Kiban është shumë më e ndërlikuar sesa në Grafan
Në përgjithësi, metrikat në ELK janë të rënda dhe ende jo aq të përshtatshme sa në zgjidhjet e tjera, nga të cilat tani ka shumë më tepër sesa thjesht Prometheus: TSDB, Victoria Metrics, Cortex, etj., etj. Sigurisht, do të doja të kisha menjëherë një zgjidhje të plotë gjithëpërfshirëse, por në rastin e metricbeat kishte shumë kompromise.
Dhe vetë pirgja ELK ka një numër momentesh të vështira:
- Është e rëndë, ndonjëherë edhe shumë e rëndë nëse mbledh një sasi mjaft të madhe të dhënash
- Ju duhet të "dini si ta gatuani" - duhet ta shkallëzoni, por kjo nuk është e parëndësishme për ta bërë
- Versioni falas i zhveshur - versioni falas nuk ka alarm normal dhe në kohën e përzgjedhjes nuk kishte asnjë vërtetim
Duhet të them që kohët e fundit pika e fundit është bërë më e mirë dhe përveç kësaj (përfshirë vërtetimin) vetë modeli i çmimeve filloi të ndryshojë.
Por në kohën kur do të vendosnim këtë zgjidhje, nuk kishte fare alarm.
Ndoshta mund të kishim provuar të ndërtonim diçka duke përdorur ElastAlert ose zgjidhje të tjera të komunitetit, por megjithatë vendosëm të konsideronim alternativa të tjera.
Loki - Grafana - Prometeu
Për momentin, një zgjidhje e mirë mund të jetë ndërtimi i një grupi monitorimi të bazuar thjesht në Prometheus si ofrues metrikë, Loki për regjistrat dhe për vizualizim mund të përdorni të njëjtën Grafana.
Fatkeqësisht, në kohën e fillimit të pilotit të shitjeve të projektit (shtator-tetor 19), Loki ishte ende në versionin beta 0.3-0.4, dhe në kohën e fillimit të zhvillimit nuk mund të konsiderohej si një zgjidhje prodhimi fare.
Unë nuk kam ende përvojë në përdorimin e vërtetë të Loki-t në projekte serioze, por mund të them se Promtail (një agjent për mbledhjen e trungjeve) funksionon shkëlqyeshëm si për podet metalike të zhveshur ashtu edhe për kubernetes.
TIKONI
Ndoshta alternativa më e denjë (e vetmja?) me funksione të plota për pirgun ELK tani mund të quhet vetëm rafte TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Unë do t'i përshkruaj të gjithë komponentët më poshtë në më shumë detaje, por ideja e përgjithshme është kjo:
- Telegraf - agjent për mbledhjen e metrikës
- InfluxDB - baza e të dhënave metrike
- Kapacitor - procesor metrikë në kohë reale për sinjalizimin
- Chronograf - panel web për vizualizim
Për InfluxDB, Kapacitor dhe Chronograf ka tabela zyrtare të drejtimit që kemi përdorur për t'i vendosur ato.
Duhet të theksohet se në versionin e fundit të Influx 2.0 (beta), Kapacitor dhe Chronograf u bënë pjesë e InfluxDB dhe nuk ekzistojnë më veçmas
Telegrafi
është një agjent shumë i lehtë për mbledhjen e metrikës në një makinë shtetërore.
Ai mund të monitorojë një sasi të madhe të gjithçkaje, nga tek
server .
Ka një numër avantazhesh të lezetshme:
- I shpejtë dhe i lehtë (i shkruar në Go)
- Ha një sasi minimale të burimeve
- Metrikat e shtytjes si parazgjedhje
- Mblidh të gjitha matjet e nevojshme
- Metrikat e sistemit pa asnjë cilësim
- Metrikat e harduerit si informacioni nga sensorët
- Është shumë e lehtë të shtoni metrikat tuaja
- Shumë shtojca jashtë kutisë
- Grumbullon shkrimet
Meqenëse metrikat e shtytjes ishin të nevojshme për ne, të gjitha avantazhet e tjera ishin më shumë se shtesa të këndshme.
Mbledhja e regjistrave nga vetë agjenti është gjithashtu shumë i përshtatshëm, pasi nuk ka nevojë të lidhni shërbime shtesë për regjistrimin e regjistrave.
Influx ofron përvojën më të përshtatshme për të punuar me regjistrat nëse përdorni .
Telegraf në përgjithësi është një agjent i shkëlqyeshëm për mbledhjen e metrikave, edhe nëse nuk e përdorni pjesën tjetër të grupit të ICK.
Shumë njerëz e kalojnë atë me ELK dhe baza të të dhënave të tjera të serive kohore për lehtësi, pasi mund të shkruajë metrikë pothuajse kudo.
InfluxDB
InfluxDB është thelbi kryesor i pirgut TICK, përkatësisht një bazë të dhënash e serive kohore për metrikat.
Përveç metrikës, Influx gjithashtu mund të ruajë regjistrat, megjithëse, në thelb, regjistrat për të janë të njëjtat metrika, vetëm në vend të treguesve të zakonshëm numerikë, funksioni kryesor kryhet nga një rresht teksti regjistri.
InfluxDB është shkruar gjithashtu në Go dhe duket se funksionon shumë më shpejt në krahasim me ELK në grupin tonë (jo më të fuqishëm).
Një nga avantazhet e lezetshme të Influx do të përfshinte gjithashtu një API shumë të përshtatshme dhe të pasur për pyetjet e të dhënave, të cilën ne e përdorëm në mënyrë shumë aktive.
Disavantazhet - $$$ apo shkallëzim?
Stacki TICK ka vetëm një pengesë që zbuluam - atë i dashur. Edhe me shume.
Çfarë ka versioni me pagesë që nuk ka versioni falas?
Me sa mundëm të kuptonim, ndryshimi i vetëm midis versionit të paguar të stivës TICK dhe atij falas janë aftësitë e shkallëzimit.
Gjegjësisht, ju mund të ngrini një grup me Disponueshmëri të lartë vetëm në .
Nëse dëshironi HA të plotë, ose duhet të paguani ose të përdorni disa paterica. Ka disa zgjidhje komunitare - për shembull duket si një zgjidhje kompetente, por shkruhet se nuk është e përshtatshme për prodhim, si dhe
- një zgjidhje e thjeshtë me pompimin e të dhënave përmes NATS (ajo gjithashtu do të duhet të shkallëzohet, por kjo mund të zgjidhet).
Është për të ardhur keq, por të dy duket se janë braktisur - nuk ka angazhime të reja, supozoj se çështja është lëshimi i pritshëm së shpejti i versionit të ri të Influx 2.0, në të cilin shumë gjëra do të jenë ndryshe (nuk ka informacion për duke u shkallëzuar në të ende).
Zyrtarisht ekziston një version falas - në fakt, ky është një HA primitiv, por vetëm përmes balancimit,
pasi të gjitha të dhënat do të shkruhen në të gjitha instancat e InfluxDB prapa balancuesit të ngarkesës.
Ai ka disa si problemet e mundshme me pikat e mbishkrimit dhe nevoja për të krijuar bazat për metrikë paraprakisht
(që ndodh automatikisht gjatë punës normale me InfluxDB).
Përveç kësaj , kjo do të thotë shpenzime shtesë për metrikat e dyfishta (si përpunimi ashtu edhe ruajtja) që mund të mos ju duhen, por nuk ka asnjë mënyrë për t'i ndarë ato.
Victoria Metrics?
Si rezultat, përkundër faktit se ishim plotësisht të kënaqur me grupin TICK në gjithçka tjetër përveç shkallëzimit me pagesë, vendosëm të shohim nëse kishte ndonjë zgjidhje falas që mund të zëvendësonte bazën e të dhënave InfluxDB, duke lënë përbërësit e mbetur T_CK.
Ka shumë baza të të dhënave të serive kohore, por më premtuesja është Victoria Metrics, ajo ka një sërë avantazhesh:
- Shpejt dhe lehtë, të paktën sipas rezultateve
- Ekziston një version grupor, për të cilin ka edhe vlerësime të mira tani
- Ajo mund të copëtojë
- Mbështet protokollin InfluxDB
Ne nuk kishim ndërmend të ndërtonim një pirg plotësisht të personalizuar bazuar në Victoria dhe shpresa kryesore ishte që ne mund ta përdorim atë si një zëvendësim për InfluxDB.
Fatkeqësisht, kjo nuk është e mundur, përkundër faktit që protokolli InfluxDB mbështetet, ai funksionon vetëm për regjistrimin e metrikës - vetëm Prometheus API është i disponueshëm "jashtë", që do të thotë se nuk do të jetë e mundur të vendosni Chronograf në të.
Për më tepër, vetëm vlerat numerike mbështeten për metrikat (ne kemi përdorur vlerat e vargut për metrikat e personalizuara - më shumë për këtë në seksion ).
Natyrisht, për të njëjtën arsye, VM nuk mund të ruajë regjistrat siç bën Influx.
Gjithashtu, duhet të theksohet se në kohën e kërkimit për zgjidhjen optimale, Victoria Metrics nuk ishte ende aq popullore, dokumentacioni ishte shumë më i vogël dhe funksionaliteti ishte më i dobët.
(Nuk mbaj mend një përshkrim të detajuar të versionit të grupit dhe ndarjes).
Zgjedhja e bazës
Si rezultat, u vendos që për pilotin ne ende do të kufizoheshim në një nyje të vetme InfluxDB.
Kishte disa arsye kryesore për këtë zgjedhje:
- Na pëlqeu shumë i gjithë funksionaliteti i pirgut TICK
- Tashmë kemi arritur ta vendosim atë dhe funksionoi shkëlqyeshëm
- Afatet po mbaronin dhe nuk kishte shumë kohë për të testuar opsionet e tjera.
- Nuk e prisnim një ngarkesë kaq të rëndë
Ne nuk kishim shumë skuter për fazën e parë të pilotimit dhe testimi gjatë zhvillimit nuk zbuloi ndonjë problem të performancës.
Prandaj, vendosëm që për këtë projekt të na mjaftonte një nyje Influx pa pasur nevojë për shkallëzim (shiko përfundimet në fund).
Ne kemi vendosur për pirgun dhe bazën - tani për përbërësit e mbetur të pirgut TICK.
Kapacitor
Kapacitor është pjesë e stakut TICK, një shërbim që mund të monitorojë metrikat që hyjnë në bazën e të dhënave në kohë reale dhe të kryejë veprime të ndryshme bazuar në rregulla.
Në përgjithësi, ai pozicionohet si një mjet për gjurmimin e anomalive të mundshme dhe mësimin e makinerive (nuk jam i sigurt që këto funksione janë të kërkuara), por rasti më i popullarizuar i përdorimit të tij është më i zakonshëm - alarmi.
Kështu e përdorëm për njoftime. Ne vendosëm sinjalizimet Slack kur një skuter i caktuar dilte jashtë linje dhe e njëjta gjë u bë për karikuesit inteligjentë dhe komponentët e rëndësishëm të infrastrukturës.
Kjo bëri të mundur reagimin e shpejtë ndaj problemeve, si dhe marrjen e njoftimeve se gjithçka ishte kthyer në normalitet.
Një shembull i thjeshtë: një bateri shtesë për të fuqizuar "kutinë" tonë është prishur ose për ndonjë arsye ka mbaruar energjia; thjesht duke instaluar një të re, pas një kohe duhet të marrim një njoftim se funksionimi i skuterit është rikthyer.
Në Influx 2.0 Kapacitor u bë pjesë e DB
Kronograf
Kam parë shumë zgjidhje të ndryshme UI për monitorim, por mund të them se për sa i përket funksionalitetit dhe UX, asgjë nuk krahasohet me Chronograf.
Ne filluam të përdorim grupin TICK, çuditërisht, me Grafan si një ndërfaqe në internet.
Nuk do ta përshkruaj funksionalitetin e tij; të gjithë i dinë mundësitë e tij të gjera për të vendosur ndonjë gjë.
Sidoqoftë, Grafana është ende një instrument plotësisht universal, ndërsa Chronograf është krijuar kryesisht për përdorim me Influx.
Dhe sigurisht, falë kësaj, Chronograf mund të përballojë një funksionalitet shumë më të zgjuar ose të përshtatshëm.
Ndoshta komoditeti kryesor i punës me Chronograf është se ju mund të shikoni pjesët e brendshme të InfluxDB tuaj përmes Explore.
Duket se Grafana ka funksionalitet pothuajse identik, por në realitet, vendosja e një pulti në Chronograf mund të bëhet me disa klikime të mausit (në të njëjtën kohë duke parë vizualizimin atje), ndërsa në Grafana do të keni akoma herët a vonë për të modifikuar konfigurimin JSON (sigurisht Chronograf ju lejon të ngarkoni dasha-të tuaja të konfiguruara me dorë dhe t'i modifikoni ato si JSON nëse është e nevojshme - por kurrë nuk më është dashur t'i prek ato pasi i kam krijuar në UI).
Kibana ka aftësi shumë më të pasura për krijimin e paneleve dhe kontrolleve për to, por UX për operacione të tilla është shumë komplekse.
Do të duhet një kuptim i mirë për të krijuar një pult të përshtatshëm. Dhe megjithëse funksionaliteti i tabelave të Chronograf është më i vogël, bërja dhe përshtatja e tyre është shumë më e thjeshtë.
Vetë tabelat, përveç stilit të këndshëm vizual, në fakt nuk ndryshojnë nga tabelat në Grafana apo Kibana:
Kështu duket dritarja e pyetjes:
Është e rëndësishme të theksohet, ndër të tjera, se duke ditur llojet e fushave në bazën e të dhënave InfluxDB, vetë kronografi ndonjëherë mund t'ju ndihmojë automatikisht të shkruani një pyetje ose të zgjidhni funksionin e saktë të grumbullimit si mesatarja.
Dhe sigurisht, Chronograf është sa më i përshtatshëm për të parë regjistrat. Duket kështu:
Si parazgjedhje, regjistrat e Influx janë përshtatur për të përdorur syslog dhe për këtë arsye ata kanë një parametër të rëndësishëm - ashpërsinë.
Grafiku në krye është veçanërisht i dobishëm; në të mund të shihni gabimet që ndodhin dhe ngjyra menjëherë tregon qartë nëse ashpërsia është më e lartë.
Disa herë ne kapëm defekte të rëndësishme në këtë mënyrë, duke shkuar për të parë regjistrat për javën e fundit dhe duke parë një majë të kuqe.
Sigurisht, në mënyrë ideale do të ishte të vendosnim alarme për gabime të tilla, pasi ne kishim tashmë gjithçka për këtë.
Ne madje e aktivizuam këtë për njëfarë kohe, por në procesin e përgatitjes së pilotit doli që po merrnim mjaft gabime (përfshirë ato të sistemit si mosdisponueshmëria e rrjetit LTE), të cilat "e spamuan" edhe kanalin Slack shumë, pa shkaktuar asnjë problem, përfitim i madh.
Zgjidhja e saktë do të ishte trajtimi i shumicës së këtyre llojeve të gabimeve, rregullimi i ashpërsisë për to dhe vetëm atëherë aktivizimi i sinjalizimit.
Në këtë mënyrë, vetëm gabimet e reja ose të rëndësishme do të postohen në Slack. Thjesht nuk kishte kohë të mjaftueshme për një organizim të tillë duke pasur parasysh afatet e ngushta.
vërtetim
Vlen gjithashtu të përmendet se Chronograf mbështet OAuth dhe OIDC si vërtetim.
Kjo është shumë e përshtatshme, pasi ju lejon ta bashkëngjitni lehtësisht në serverin tuaj dhe të krijoni SSO të plotë.
Në rastin tonë, serveri ishte — u përdor për t'u lidhur me monitorimin, por i njëjti server u përdor gjithashtu për të vërtetuar skuterët dhe kërkesat në pjesën e pasme.
"Admin"
Komponenti i fundit që do të përshkruaj është "paneli i administratorit" i vetë-shkruar në Vue.
Në thelb, është thjesht një shërbim i pavarur që shfaq informacionin e skuterit nga bazat tona të të dhënave, mikroshërbimet dhe të dhënat metrikë nga InfluxDB njëkohësisht.
Përveç kësaj, shumë funksione administrative u zhvendosën atje, të tilla si një rindezje emergjente ose hapja nga distanca e një bllokimi për ekipin mbështetës.
Kishte edhe harta. Tashmë kam përmendur se kemi filluar me Grafana në vend të Chronograf - sepse për Grafana hartat janë të disponueshme në formën e shtojcave, në të cilat mund të shikonim koordinatat e skuterëve. Fatkeqësisht, aftësitë e miniaplikacioneve të hartave për Grafana janë shumë të kufizuara, dhe si rezultat, ishte shumë më e lehtë të shkruani aplikacionin tuaj në internet me harta brenda disa ditësh, në mënyrë që jo vetëm të shihni koordinatat për momentin, por edhe të shfaqni itinerarin e ndjekur nga skuteri, të jetë në gjendje të filtrojë të dhënat në hartë, etj.
Një nga avantazhet e përmendura tashmë të Influx është aftësia për të krijuar lehtësisht metrikat tuaja.
Kjo e lejon atë të përdoret për një larmi të madhe skenarësh.
Ne u përpoqëm të regjistronim të gjitha informacionet e dobishme atje: ngarkimin e baterisë, statusin e bllokimit, performancën e sensorit, bluetooth, GPS dhe shumë kontrolle të tjera shëndetësore.
Ne i shfaqëm të gjitha këto në panelin e administratorit.
Sigurisht, kriteri më i rëndësishëm për ne ishte gjendja e funksionimit të skuterit - në fakt, Influx e kontrollon vetë këtë dhe e tregon atë me "dritat jeshile" në seksionin "Nyjet".
Kjo bëhet nga funksioni — ne e përdorëm atë për të kuptuar performancën e kutisë sonë dhe për të dërguar të njëjtat sinjalizime te Slack.
Nga rruga, ne i emërtuam skuterët sipas emrave të personazheve nga The Simpsons - ishte aq e përshtatshme për t'i dalluar ato nga njëri-tjetri
Dhe në përgjithësi ishte më argëtuese në këtë mënyrë. Fraza si “Djema, Smithers ka vdekur!” dëgjoheshin vazhdimisht.
Metrika e vargut
Është e rëndësishme që InfluxDB t'ju lejojë të ruani jo vetëm vlera numerike, siç është rasti me Victoria Metrics.
Duket se kjo nuk është aq e rëndësishme - në fund të fundit, përveç regjistrave, çdo metrikë mund të ruhet në formën e numrave (thjesht shtoni hartën për gjendjet e njohura - një lloj enum)?
Në rastin tonë, kishte të paktën një skenar ku metrikat e vargut ishin shumë të dobishme.
Thjesht ndodhi që furnizuesi i "karikuesve tanë inteligjentë" ishte një palë e tretë, ne nuk kishim kontroll mbi procesin e zhvillimit dhe informacionin që mund të siguronin këta karikues.
Si rezultat, API-ja e tarifimit ishte larg idealit, por problemi kryesor ishte se ne nuk mund ta kuptonim gjithmonë gjendjen e tyre.
Këtu Fluksi erdhi në shpëtim. Ne thjesht shkruam statusin e vargut që na erdhi në fushën e bazës së të dhënave InfluxDB pa ndryshime.
Për ca kohë, vetëm vlerat si "online" dhe "offline" arritën atje, në bazë të të cilave informacioni u shfaq në panelin tonë të administratorit dhe njoftimet u dërguan në Slack. Sidoqoftë, në një moment, vlerat si "të shkëputura" gjithashtu filluan të shfaqen atje.
Siç doli më vonë, ky status u dërgua një herë pas një humbjeje të lidhjes, nëse ngarkuesi nuk mund të krijonte një lidhje me serverin pas një numri të caktuar përpjekjesh.
Kështu, nëse do të përdornim vetëm një grup fiks vlerash, mund të mos i shohim këto ndryshime në firmware në kohën e duhur.
Dhe në përgjithësi, metrikat e vargjeve ofrojnë shumë më tepër mundësi për përdorim; ju mund të regjistroni pothuajse çdo informacion në to. Edhe pse, sigurisht, ju gjithashtu duhet ta përdorni këtë mjet me kujdes.
Përveç matjeve të zakonshme, ne gjithashtu regjistruam informacionin e vendndodhjes GPS në InfluxDB. Kjo ishte jashtëzakonisht e dobishme për monitorimin e vendndodhjes së skuterëve në panelin tonë të administratorit.
Në fakt, ne gjithmonë e dinim se ku dhe cili skuter ishte në momentin që na duhej.
Kjo ishte shumë e dobishme për ne kur po kërkonim një skuter (shih përfundimet në fund).
Monitorimi i infrastrukturës
Përveç vetë skuterëve, na duhej gjithashtu të monitoronim të gjithë infrastrukturën tonë (mjaft të gjerë).
Një arkitekturë shumë e përgjithshme dukej diçka si kjo:
Nëse theksojmë një pirg të pastër monitorimi, duket kështu:
Ajo që do të donim të kontrollonim në re është:
- Bazat e të dhënave
- mantel çelësi
- Mikroshërbime
Meqenëse të gjitha shërbimet tona cloud janë të vendosura në Kubernetes, do të ishte mirë të mblidhnim informacione për gjendjen e tij.
Për fat të mirë, Telegraf jashtë kutisë mund të mbledhë një numër të madh metrikash në lidhje me gjendjen e grupit Kubernetes, dhe Chronograf ofron menjëherë panele të bukura për këtë.
Ne monitoruam kryesisht performancën e pods dhe konsumin e kujtesës. Në rast rënieje, alarmet në Slack.
Ka dy mënyra për të gjurmuar pods në Kubernetes: DaemonSet dhe Sidecar.
Të dyja metodat përshkruhen në detaje .
Ne përdorëm Telegraf Sidecar dhe, përveç metrikës, mblodhëm regjistrat e pod.
Në rastin tonë, na duhej të ndërhynim me shkrimet. Përkundër faktit që Telegraf mund të tërheqë regjistrat nga Docker API, ne donim të kishim një koleksion uniform të regjistrave me pajisjet tona fundore dhe të konfiguronim syslog për kontejnerët për këtë. Ndoshta kjo zgjidhje nuk ishte e bukur, por nuk kishte ankesa për punën e saj dhe shkrimet u shfaqën mirë në Chronograf.
Monitorimi i monitorimit???
Në fund, lindi çështja e vjetër e monitorimit të sistemeve të monitorimit, por për fat të mirë, ose për fat të keq, ne thjesht nuk kishim kohë të mjaftueshme për këtë.
Megjithëse Telegraf mund të dërgojë lehtësisht metrikat e veta ose të mbledhë metrikë nga baza e të dhënave InfluxDB për t'i dërguar ose në të njëjtin Influx ose diku tjetër.
Gjetjet
Çfarë përfundimesh kemi nxjerrë nga rezultatet e pilotit?
Si mund të bëni monitorim?
Para së gjithash, grupi TICK përmbushi plotësisht pritshmëritë tona dhe na dha edhe më shumë mundësi nga sa prisnim fillimisht.
I gjithë funksionaliteti që na nevojitej ishte i pranishëm. Gjithçka që bëmë me të funksionoi pa probleme.
prodhimtari
Problemi kryesor me pirgun TICK në versionin falas është mungesa e aftësive të shkallëzimit. Ky nuk ishte problem për ne.
Ne nuk kemi mbledhur të dhëna/shifra të sakta të ngarkesës, por kemi mbledhur të dhëna nga rreth 30 skuter në të njëjtën kohë.
Secili prej tyre mblodhi më shumë se tre duzina metrike. Në të njëjtën kohë, u mblodhën regjistrat nga pajisjet. Mbledhja dhe dërgimi i të dhënave ndodhte çdo 10 sekonda.
Është e rëndësishme të theksohet se pas një jave e gjysmë të pilotit, kur pjesa më e madhe e "problemeve të fëmijërisë" u korrigjuan dhe problemet më të rëndësishme ishin zgjidhur tashmë, ne duhej të reduktonim frekuencën e dërgimit të të dhënave në server në 30 sekonda. Kjo u bë e nevojshme sepse trafiku në kartat tona SIM LTE filloi të zhdukej shpejt.
Pjesa më e madhe e trafikut u konsumua nga shkrimet; vetë metrikat, edhe me një interval prej 10 sekondash, praktikisht nuk e humbën atë.
Si rezultat, pas ca kohësh ne çaktivizuam plotësisht mbledhjen e regjistrave në pajisje, pasi problemet specifike ishin tashmë të dukshme edhe pa mbledhje të vazhdueshme.
Në disa raste, nëse shikimi i regjistrave ishte ende i nevojshëm, ne thjesht u lidhëm përmes WireGuard përmes VPN.
Do të shtoj gjithashtu se çdo mjedis i veçantë ishte i ndarë nga njëri-tjetri, dhe ngarkesa e përshkruar më sipër ishte e rëndësishme vetëm për mjedisin e prodhimit.
Në mjedisin e zhvillimit, ne ngritëm një shembull të veçantë InfluxDB që vazhdoi të mblidhte të dhëna çdo 10 sekonda dhe nuk hasëm në asnjë problem performancës.
TICK - ideale për projekte të vogla dhe të mesme
Bazuar në këtë informacion, do të konkludoja se rafti TICK është ideal për projekte relativisht të vogla ose projekte që definitivisht nuk presin ndonjë HighLoad.
Nëse nuk keni mijëra pods ose qindra makineri, edhe një shembull InfluxDB do ta trajtojë mirë ngarkesën.
Në disa raste, mund të jeni të kënaqur me Influx Relay si një zgjidhje primitive me disponueshmëri të lartë.
Dhe, sigurisht, askush nuk po ju ndalon të vendosni shkallëzimin "vertikal" dhe thjesht të ndani serverë të ndryshëm për lloje të ndryshme metrikash.
Nëse nuk jeni të sigurt për ngarkesën e pritshme në shërbimet e monitorimit, ose jeni të garantuar se keni/do të keni një arkitekturë shumë "të rëndë", nuk do të rekomandoja përdorimin e versionit falas të stivës TICK.
Sigurisht, një zgjidhje e thjeshtë do të ishte blerja - por këtu nuk mund të komentoj disi, pasi unë vetë nuk jam i njohur me hollësitë. Përveç faktit që është shumë i shtrenjtë dhe definitivisht jo i përshtatshëm për kompanitë e vogla.
Në këtë rast, sot, unë do të rekomandoja të shikoni për mbledhjen e metrikave përmes Victoria Metrics dhe regjistrave duke përdorur Loki.
Vërtetë, unë do të bëj përsëri një rezervë që Loki/Grafana janë shumë më pak të përshtatshme (për shkak të shkathtësisë së tyre më të madhe) sesa TICK-i i gatshëm, por ato janë falas.
Është e rëndësishme: i gjithë informacioni i përshkruar këtu është i rëndësishëm për versionin Influx 1.8, për momentin Influx 2.0 është gati të dalë.
Ndërsa nuk kam pasur rastin ta provoj në kushte luftarake dhe është e vështirë të nxjerr përfundime rreth përmirësimeve, ndërfaqja është bërë padyshim edhe më e mirë, arkitektura është thjeshtuar (pa kapacitor dhe kronografi),
u shfaqën shabllone ("veçori vrasëse" - ). Por, për fat të keq, për momentin, versioni 2 nuk ka gjënë kryesore për të cilën zgjodhëm versionin e parë - nuk ka asnjë koleksion regjistrash.
Ky funksionalitet do të shfaqet edhe në Influx 2.0, por nuk gjetëm asnjë afat, qoftë edhe të përafërt.
Si të mos krijoni platforma IoT (tani)
Në fund, pasi kemi nisur pilotin, ne vetë mblodhëm pirgun tonë të plotë të IoT, në mungesë të një alternative të përshtatshme për standardet tona.
Megjithatë, kohët e fundit është në dispozicion në versionin Beta - është për të ardhur keq që ajo nuk ishte aty kur filluam të bënim projektin.
Ne jemi plotësisht të kënaqur me rezultatin përfundimtar dhe platformën e bazuar në Ansible + TICK + WireGuard që kemi montuar vetë. Por sot, unë do të rekomandoja të hidhni një vështrim më të afërt në Balena përpara se të përpiqeni të ndërtoni vetë platformën tuaj IoT.
Sepse në fund të fundit mund të bëjë pjesën më të madhe të asaj që bëmë ne, dhe OpenBalena është falas dhe me burim të hapur.
Ajo tashmë e di se si jo vetëm të dërgojë përditësime, por gjithashtu një VPN është ndërtuar tashmë dhe është përshtatur për t'u përdorur në një mjedis IoT.
Dhe vetëm kohët e fundit, ata madje e lëshuan të tyren , e cila lidhet lehtësisht me ekosistemin e tyre.
Hej, po në lidhje me skuterin që mungon?
Kështu skuteri “Ralph” u zhduk pa lënë gjurmë.
Ne vrapuam menjëherë për të parë hartën në "panelin tonë të administratorit", me të dhënat matëse GPS nga InfluxDB.
Falë të dhënave të monitorimit, ne përcaktuam lehtësisht se skuteri doli nga parkingu rreth orës 21:00 të ditës së kaluar, udhëtoi rreth gjysmë ore në një zonë dhe ishte parkuar deri në 5 të mëngjesit pranë një shtëpie gjermane.
Pas orës 5 të mëngjesit, nuk u morën të dhëna monitorimi - kjo do të thoshte ose bateria shtesë ishte shkarkuar plotësisht, ose sulmuesi më në fund kuptoi se si të hiqte pajisjen inteligjente nga skuteri.
Pavarësisht kësaj, policia është thirrur ende në adresën ku ndodhej skuteri. Skuteri nuk ishte aty.
Mirëpo, me këtë ka mbetur i befasuar edhe i zoti i shtëpisë, pasi në fakt ai mbrëmë ka hipur me këtë skuter nga zyra në shtëpi.
Siç doli, një nga punonjësit e ndihmës mbërriti herët në mëngjes dhe mori skuterin, duke parë që bateria shtesë e tij ishte shkarkuar plotësisht dhe e çoi (në këmbë) në parking. Dhe bateria shtesë dështoi për shkak të lagështirës.
Ne e vodhëm skuterin nga vetja. Meqë ra fjala, nuk e di se si dhe kush e zgjidhi më pas çështjen me çështjen e policisë, por monitorimi funksionoi në mënyrë perfekte...
Burimi: www.habr.com