Fyrir ári síðan hófum við tilraunaútgáfu af kynningarverkefni fyrir .
Upphaflega hét verkefnið Road-To-Barcelona, síðar varð það Road-To-Berlin (þess vegna R2B í skjámyndunum), og á endanum var það kallað xRide.
Meginhugmynd verkefnisins var þessi: í stað þess að vera með miðlæga bíla- eða vespuleiguþjónustu (við erum að tala um vespur aka rafmótorhjól, ekki sparkvespur/vesp) vildum við búa til vettvang fyrir dreifða leigu. Um erfiðleikana sem við lentum í .
Upphaflega snerist verkefnið um bíla en vegna tímafresta, gífurlega langra samskipta við framleiðendur og gífurlegs fjölda öryggistakmarkana voru rafvespur valin í tilraunaverkefnið.
Notandinn setti upp iOS eða Android forrit á símann, nálgaðist vespuna sem honum líkaði, eftir það komust síminn og vespan á jafningjasambandi, skipt var um ETH og notandinn gat hafið ferðina með því að kveikja á vespu í gegnum síminn. Í lok ferðarinnar var einnig hægt að greiða fyrir ferðina með Ethereum úr veski notandans í símanum.
Auk hlaupahjóla sá notandinn „snjallhleðslutæki“ í forritinu, með því að heimsækja þar sem notandinn gæti sjálfur skipt um núverandi rafhlöðu ef hún var lítil.
Svona leit flugmaðurinn okkar út, sem var hleypt af stokkunum í september á síðasta ári í tveimur þýskum borgum: Bonn og Berlín.
Og svo, einn daginn, í Bonn, snemma morguns, var stuðningsteymi okkar (staðsett á staðnum til að halda vespunum í lagi) gert viðvart: ein vespanna var horfin sporlaust.
Hvernig á að finna það og skila því?
Í þessari grein mun ég tala um þetta, en fyrst - um hvernig við byggðum okkar eigin IoT vettvang og hvernig við fylgdumst með því.
Hvað og hvers vegna á að fylgjast með: Hlaupahjólum, innviðum, hleðslustöðvum?
Svo, hvað vildum við fylgjast með í verkefninu okkar?
Í fyrsta lagi eru þetta vespurnar sjálfar - rafmagnsvespurnar sjálfar eru frekar dýrar, þú getur ekki sett slíkt verkefni af stað án þess að vera nægilega undirbúinn; ef mögulegt er, viltu safna eins miklum upplýsingum og mögulegt er um vespurnar: um staðsetningu þeirra, hleðslustig , o.s.frv.
Auk þess langar mig að fylgjast með stöðu okkar eigin upplýsingatækniinnviða - gagnagrunna, þjónustu og allt sem þeir þurfa til að virka. Einnig var nauðsynlegt að fylgjast með stöðu „snjallhleðslutækjanna“ ef þau biluðu eða klárast fullar rafhlöður.
Hlaupahjól
Hverjar voru vespurnar okkar og hvað vildum við vita um þær?
Það fyrsta og mikilvægasta er GPS hnit, þar sem þökk sé þeim getum við skilið hvar þau eru og hvert þau eru á hreyfingu.
Næst er rafhlaðan hleðsla, þökk sé henni getum við komist að því að hleðslu vespanna sé að ljúka og sent safapressu eða að minnsta kosti varað notandann við.
Auðvitað er líka nauðsynlegt að athuga hvað er að gerast með vélbúnaðarhlutina okkar:
- virkar bluetooth?
- virkar GPS einingin sjálf?
- Við áttum líka í vandræðum með að GPS gæti sent röng hnit og festist og það var aðeins hægt að ákvarða það með viðbótarskoðun á vespu,
og tilkynna þjónustudeild eins fljótt og auðið er til að leysa málið
- Við áttum líka í vandræðum með að GPS gæti sent röng hnit og festist og það var aðeins hægt að ákvarða það með viðbótarskoðun á vespu,
Og að lokum: athuganir á hugbúnaðinum, byrjar á stýrikerfinu og örgjörvanum, net- og diskaálagi, endar með athugunum á eigin einingum sem eru sértækari fyrir okkur (, ).
Vélbúnaður
Hver var "járn" hluti okkar?
Að teknu tilliti til stystu mögulegu tímaramma og þörf fyrir hraða frumgerð, völdum við auðveldasta kostinn fyrir útfærslu og val á íhlutum - Raspberry Pi.
Auk Rpi sjálfrar vorum við með sérsniðið borð (sem við sjálf þróuðum og pöntuðum frá Kína til að flýta fyrir samsetningarferli lokalausnarinnar) og sett af íhlutum - gengi (til að kveikja/slökkva á vespu), rafhlöðuhleðslulesari, mótald, loftnet. Allt þetta var þétt pakkað í sérstakan „xRide kassa“.
Það skal líka tekið fram að allur kassinn var knúinn af aukarafbanka, sem aftur var knúinn af aðalrafhlöðu vespunnar.
Þetta gerði það að verkum að hægt var að nota eftirlit og kveikja á vespu jafnvel eftir að ferðinni lauk, þar sem slökkt var á aðalrafhlöðunni strax eftir að kveikjulyklinum var snúið í „slökkt“ stöðu.
Hafnarmaður? Venjulegur Linux? og dreifing
Snúum okkur aftur að eftirliti, svo Raspberry - hvað höfum við?
Eitt af því fyrsta sem við vildum nota til að flýta fyrir því að dreifa, uppfæra og afhenda íhluti í líkamleg tæki var Docker.
Því miður varð fljótt ljóst að Docker á RPi, þó að það virki, hefur mikla kostnað, sérstaklega hvað varðar orkunotkun.
Munurinn á því að nota „innfædda“ stýrikerfið, þó ekki svo sterkt, var samt nægjanlegt til að við gætum verið á varðbergi gagnvart möguleikanum á að missa hleðslu of fljótt.
Önnur ástæðan var eitt af samstarfssöfnum okkar á Node.js (sic!) - eini hluti kerfisins sem var ekki skrifaður í Go/C/C++.
Höfundar bókasafnsins höfðu ekki tíma til að útvega vinnuútgáfu á neinu „móðurmáli“.
Ekki aðeins er hnúturinn sjálfur ekki glæsilegasta lausnin fyrir afkastamikil tæki, heldur var bókasafnið sjálft mjög auðlindasnautt.
Við gerðum okkur grein fyrir því að jafnvel þótt við vildum, þá væri of mikil kostnaður fyrir okkur að nota Docker. Valið var gert í þágu innfædda stýrikerfisins og að vinna beint undir því.
OS
Fyrir vikið völdum við aftur einfaldasta valkostinn sem stýrikerfið og notuðum Raspbian (Debian smíðar fyrir Pi).
Við skrifum allan hugbúnaðinn okkar í Go, svo við skrifuðum líka aðalbúnaðarbúnaðareininguna í kerfið okkar í Go.
Það er hann sem ber ábyrgð á því að vinna með GPS, Bluetooth, lesa hleðsluna, kveikja á vespu o.fl.
Dreifa
Spurningin vaknaði strax um nauðsyn þess að innleiða kerfi til að koma uppfærslum á tæki (OTA) - bæði uppfærslur á umboðsmanninum/forritinu sjálfu og uppfærslur á stýrikerfinu/fastbúnaðinum sjálfum (þar sem nýjar útgáfur umboðsmannsins gætu krafist uppfærslu á kjarnanum eða kerfishlutar, bókasöfn o.s.frv.).
Eftir nokkuð langa greiningu á markaðnum kom í ljós að það eru til talsvert margar lausnir til að koma uppfærslum á tækið.
Frá tiltölulega einföldum, aðallega uppfærslu-/tvístígvélastillum tólum eins og swupd/SWUpdate/OSTree til fullgildra kerfa eins og Mender og Balena.
Í fyrsta lagi ákváðum við að við hefðum áhuga á end-to-end lausnum, svo valið féll strax á palla.
Mjög var útilokað vegna þess að það notar í raun sama Docker inni í balenaEngine.
En ég tek það fram að þrátt fyrir þetta enduðum við á því að nota vöruna þeirra stöðugt fyrir flash fastbúnað á SD-kortum - einfalt og einstaklega þægilegt tól fyrir þetta.
Þess vegna féll valið á endanum . Mender er fullkominn vettvangur til að setja saman, afhenda og setja upp fastbúnað.
Á heildina litið lítur pallurinn vel út, en það tók okkur um eina og hálfa viku bara að smíða rétta útgáfu af fastbúnaðinum okkar með því að nota mender smiðinn.
Og því meira sem við sökktum okkur niður í ranghala notkun þess, því betur varð ljóst að til að dreifa því að fullu þyrftum við miklu meiri tíma en við höfðum.
Því miður, þröngir frestir okkar gerðu það að verkum að við neyddumst til að hætta að nota Mender og velja enn einfaldari.
Ansible
Einfaldasta lausnin í okkar aðstæðum var að nota Ansible. Nokkrar leikbækur voru nóg til að byrja.
Kjarni þeirra var sá að við tengdumst einfaldlega frá gestgjafanum (CI miðlara) í gegnum ssh við rasberin okkar og dreifðum uppfærslum til þeirra.
Strax í upphafi var allt einfalt - þú þurftir að vera á sama neti og tækin, upphelling fór fram í gegnum Wi-Fi.
Á skrifstofunni voru einfaldlega tugir hindberjaprófa tengdir sama neti, hvert tæki var með kyrrstæða IP tölu sem einnig er tilgreind í Ansible Inventory.
Það var Ansible sem afhenti eftirlitsaðila okkar til lokatækjanna
3G / LTE
Því miður gat þetta notkunartilfelli fyrir Ansible aðeins virkað í þróunarham áður en við áttum raunverulegar vespur.
Vegna þess að vespu, eins og þú skilur, sitja ekki tengd við eina Wi-Fi bein, og bíða stöðugt eftir uppfærslum á netinu.
Í raun og veru geta hlaupahjól alls ekki haft neina tengingu nema farsíma 3G/LTE (og jafnvel þá ekki allan tímann).
Þetta skapar strax mörg vandamál og takmarkanir, svo sem lágan tengihraða og óstöðug samskipti.
En það mikilvægasta er að í 3G/LTE neti getum við ekki einfaldlega treyst á kyrrstöðu IP sem er úthlutað til netsins.
Þetta er að hluta til leyst af sumum SIM-kortaveitum; það eru jafnvel sérstök SIM-kort hönnuð fyrir IoT tæki með kyrrstæðum IP tölum. En við höfðum ekki aðgang að slíkum SIM-kortum og gátum ekki notað IP tölur.
Auðvitað voru uppi hugmyndir um að gera einhvers konar skráningu á IP-tölum aka þjónustuuppgötvun einhvers staðar eins og Consul, en við urðum að hætta við slíkar hugmyndir, þar sem í prófunum okkar gat IP-talan breyst of oft, sem leiddi til mikils óstöðugleika.
Af þessum sökum væri þægilegasta notkunin til að afhenda mæligildi ekki að nota pull líkanið, þar sem við myndum fara í tæki fyrir nauðsynlegar mæligildi, heldur ýta, skila mæligildum frá tækinu beint á netþjóninn
VPN
Sem lausn á þessu vandamáli völdum við VPN - sérstaklega .
Viðskiptavinir (vespur) í upphafi kerfisins tengdust VPN netþjóninum og gátu tengst þeim. Þessi göng voru notuð til að skila uppfærslum.
Fræðilega séð væri hægt að nota sömu göng til vöktunar, en slík tenging var flóknari og áreiðanlegri en einföld ýta.
Skýjaauðlindir
Að lokum er nauðsynlegt að fylgjast með skýjaþjónustunni okkar og gagnagrunnum, þar sem við notum Kubernetes fyrir þær, helst svo að uppsetning eftirlits í klasanum sé eins einföld og mögulegt er. Helst að nota , þar sem við notum það í flestum tilfellum til dreifingar. Og auðvitað, til að fylgjast með skýinu þarftu að nota sömu lausnir og fyrir vespurnar sjálfar.
Gefið
Púff, við virðumst vera búin að redda lýsingunni, við skulum búa til lista yfir það sem við þurftum á endanum:
- Fljótleg lausn þar sem eftirlit er nauðsynlegt þegar á meðan á þróun stendur
- Rúmmál/magn – þarf margar mælikvarðar
- Söfnun annála er nauðsynleg
- Áreiðanleiki - gögn eru mikilvæg til að ná árangri
- Þú getur ekki notað pull líkanið - þú þarft að ýta
- Við þurfum samræmt eftirlit með ekki aðeins vélbúnaði, heldur einnig skýi
Lokamyndin leit einhvern veginn svona út
Stafla val
Þannig að við stóðum frammi fyrir spurningunni um að velja vöktunarstafla.
Í fyrsta lagi vorum við að leita að fullkomnustu allt-í-einni lausninni sem myndi samtímis uppfylla allar kröfur okkar, en á sama tíma vera nógu sveigjanleg til að sníða notkun hennar að þörfum okkar. Samt höfðum við margar takmarkanir settar á okkur með vélbúnaði, arkitektúr og fresti.
Það er mikið úrval af vöktunarlausnum, byrjað á fullkomnum kerfum eins og , eða og endar með tilbúnum lausnum fyrir flotastjórnun.
Upphaflega virtist hið síðarnefnda vera tilvalin lausn fyrir okkur, en sumir höfðu ekki fullt eftirlit, aðrir höfðu mjög takmarkaða getu ókeypis útgáfunnar og aðrir einfaldlega náðu ekki til „vilja“ okkar eða voru ekki nógu sveigjanlegir til að passa við aðstæður okkar. Sumt er einfaldlega úrelt.
Eftir að hafa greint fjölda svipaðra lausna komumst við fljótt að þeirri niðurstöðu að það væri auðveldara og fljótlegra að setja saman svipaðan stafla sjálf. Já, það verður aðeins flóknara en að beita algjörlega tilbúnum flotastjórnunarvettvangi, en við þurfum ekki að gera málamiðlanir.
Nánast vissulega, í öllu því mikla gnægð af lausnum, er nú þegar til tilbúin lausn sem myndi henta okkur algjörlega, en í okkar tilviki var miklu fljótlegra að setja saman ákveðinn stafla á eigin spýtur og sérsníða hann „fyrir okkur“ frekar en prófa tilbúnar vörur.
Með allt þetta leituðumst við ekki við að setja saman heilan vöktunarvettvang sjálf, heldur vorum við að leita að hagnýtustu „tilbúnum“ staflanum, aðeins með getu til að stilla þá á sveigjanlegan hátt.
(B)ELK?
Fyrsta lausnin sem raunverulega kom til greina var hinn þekkti ELK stafla.
Reyndar ætti þetta að heita BELK, því þetta byrjar allt á Beats -
ELK er auðvitað ein frægasta og öflugasta lausnin á sviði vöktunar og enn frekar í söfnun og vinnslu logs.
Við ætluðum okkur að ELK yrði notað til að safna logum og sem og langtíma geymslu mæligilda sem fengin eru frá Prometheus.
Fyrir sjónmynd er hægt að nota Grafan.
Reyndar getur nýi ELK staflan safnað mælingum sjálfstætt (metricbeat) og Kibana getur líka sýnt þær.
En samt, ELK ólst upphaflega upp úr annálum og hingað til hefur virkni mæligildanna ýmsa alvarlega galla:
- Verulega hægari en Prometheus
- Samlagast mun færri stöðum en Prometheus
- Það er erfitt að setja upp viðvaranir fyrir þá
- Mælingar taka mikið pláss
- Að setja upp mælaborð með mæligildum í Kiban er mun flóknara en í Grafanum
Almennt séð eru mælingarnar í ELK þungar og ekki enn eins hentugar og í öðrum lausnum, sem nú eru til miklu fleiri en bara Prometheus: TSDB, Victoria Metrics, Cortex o.s.frv., o.fl. Auðvitað myndi ég vilja fá fullgilda allt-í-einn lausn strax, en þegar um metricbeat var að ræða voru of margar málamiðlanir.
Og ELK staflan sjálfur hefur fjölda erfiðra augnablika:
- Það er þungt, stundum jafnvel mjög þungt ef þú safnar frekar miklu magni af gögnum
- Þú þarft að "vita hvernig á að elda" það - þú þarft að skala það, en þetta er ekki léttvægt að gera
- Fjarlægð ókeypis útgáfa - ókeypis útgáfan hefur ekki venjulega viðvörun og þegar valið var var engin auðkenning
Ég verð að segja að nýlega hefur síðasti liðurinn orðið betri og til viðbótar (þar á meðal auðkenning) fór sjálft verðlagningarlíkanið að breytast.
En á þeim tíma þegar við ætluðum að dreifa þessari lausn var engin viðvörun.
Kannski hefðum við getað reynt að byggja eitthvað með ElastAlert eða öðrum samfélagslausnum, en við ákváðum samt að íhuga aðra valkosti.
Loki - Grafana - Prómeþeifur
Í augnablikinu gæti góð lausn verið að smíða vöktunarstafla eingöngu sem byggist eingöngu á Prometheus sem mælikvarða, Loki fyrir logs, og fyrir sjónmynd geturðu notað sömu Grafana.
Því miður, þegar sölutilraun verkefnisins hófst (september-október 19), var Loki enn í beta útgáfu 0.3-0.4 og þegar þróunin hófst var ekki hægt að líta á það sem framleiðslulausn yfirleitt.
Ég hef ekki ennþá reynslu af því að nota Loka í alvarlegum verkefnum, en ég get sagt að Promtail (umboðsaðili til að safna trjábolum) virkar frábærlega fyrir bæði berum málm og fræbelg í kubernetes.
MERKIÐ
Kannski er verðugasta (eina?) valkosturinn við ELK stafla nú aðeins hægt að kalla TICK stafla - Telegraf, InfluxDB, Chronograf, Kapacitor.
Ég mun lýsa öllum íhlutunum hér að neðan nánar, en almenna hugmyndin er þessi:
- Telegraf - umboðsmaður til að safna mæligildum
- InfluxDB - mælingagagnagrunnur
- Kapacitor - rauntíma mælingar örgjörva fyrir viðvörun
- Chronograf - vefspjald fyrir sjónmynd
Fyrir InfluxDB, Kapacitor og Chronograf eru opinber stýrikort sem við notuðum til að dreifa þeim.
Það skal tekið fram að í nýjustu útgáfunni af Influx 2.0 (beta) urðu Kapacitor og Chronograf hluti af InfluxDB og eru ekki lengur til sérstaklega.
Telegraph
er mjög léttur umboðsmaður til að safna mæligildum á ríkisvél.
Hann getur fylgst með miklu magni af öllu, frá í
miðlara .
Það hefur marga flotta kosti:
- Hratt og létt (skrifað í Go)
- Borðar lágmarks magn af auðlindum
- Push mæligildi sjálfgefið
- Safnar öllum nauðsynlegum mælingum
- Kerfismælingar án nokkurra stillinga
- Vélbúnaðarmælingar eins og upplýsingar frá skynjurum
- Það er mjög auðvelt að bæta við eigin mælingum
- Fullt af viðbótum úr kassanum
- Safnar annálum
Þar sem þrýstingsmælingar voru nauðsynlegar fyrir okkur voru allir aðrir kostir meira en skemmtilegar viðbætur.
Söfnun á annálum af umboðsmanninum sjálfum er líka mjög þægilegt, þar sem engin þörf er á að tengja viðbótartól til að skrá logs.
Influx býður upp á þægilegustu upplifunina til að vinna með logs ef þú notar .
Telegraf er almennt frábær umboðsmaður til að safna mælingum, jafnvel þótt þú notir ekki restina af ICK staflanum.
Margir krossa það við ELK og ýmsa aðra tímaraðar gagnagrunna til hægðarauka, þar sem það getur skrifað mæligildi nánast hvar sem er.
InnstreymiDB
InfluxDB er aðalkjarni TICK staflans, nefnilega tímaraðar gagnagrunnur fyrir mælikvarða.
Til viðbótar við mælikvarða getur Influx einnig geymt annála, þó að í meginatriðum séu annálar fyrir það bara sömu mælikvarðar, aðeins í stað venjulegra töluvísa er aðalaðgerðin framkvæmd með línu af annálatexta.
InfluxDB er líka skrifað í Go og virðist keyra mun hraðar miðað við ELK á (ekki öflugasta) klasanum okkar.
Einn af flottu kostunum við Influx myndi einnig innihalda mjög þægilegt og ríkt API fyrir gagnafyrirspurnir, sem við notuðum mjög virkan.
Ókostir - $$$ eða stigstærð?
TICK staflan hefur aðeins einn galla sem við uppgötvuðum - hann elskan. Jafnvel meira.
Hvað hefur greidda útgáfan sem ókeypis útgáfan hefur ekki?
Eftir því sem við gátum skilið er eini munurinn á greiddu útgáfunni af TICK staflanum og þeirri ókeypis stærðarmöguleikinn.
Það er nefnilega hægt að ala upp klasa með Hár framboði aðeins í .
Ef þú vilt fullgilda HA þarftu annað hvort að borga eða nota hækjur. Það eru nokkrar samfélagslausnir - til dæmis lítur út eins og hæf lausn, en það er skrifað að það sé ekki hentugur til framleiðslu, sem og
- einföld lausn með gagnadælingu í gegnum NATS (það verður líka að kvarða hana, en þetta er hægt að leysa).
Það er leitt, en báðar virðast vera yfirgefnar - það eru engar ferskar skuldbindingar, ég geri ráð fyrir að málið sé bráðlega væntanleg útgáfa af nýju útgáfunni af Influx 2.0, þar sem margt verður öðruvísi (það eru engar upplýsingar um mælikvarði í það ennþá).
Opinberlega er til ókeypis útgáfa - í raun er þetta frumstætt HA, en aðeins í gegnum jafnvægi,
þar sem öll gögn verða skrifuð á öll InfluxDB tilvik á bak við álagsjafnarann.
Hann á nokkrar eins og hugsanleg vandamál með að skrifa yfir punkta og þörfina á að búa til grunn fyrir mælikvarða fyrirfram
(sem gerist sjálfkrafa við venjulega vinnu með InfluxDB).
Að auki , þetta þýðir viðbótarkostnaður fyrir tvítekna mælikvarða (bæði vinnslu og geymslu) sem þú gætir ekki þurft, en það er engin leið að aðskilja þær.
Victoria Metrics?
Fyrir vikið, þrátt fyrir að við værum fullkomlega sátt við TICK staflan í öllu öðru en greiddum mælikvarða, ákváðum við að athuga hvort það væru einhverjar ókeypis lausnir sem gætu komið í stað InfluxDB gagnagrunnsins, en skildu eftir T_CK íhlutina.
Það eru til fullt af tímaraðar gagnagrunnum, en sá efnilegasti er Victoria Metrics, hann hefur marga kosti:
- Hratt og auðvelt, að minnsta kosti samkvæmt niðurstöðunum
- Það er til klasaútgáfa sem það eru meira að segja góðar umsagnir um núna
- Hún getur rifið
- Styður InfluxDB samskiptareglur
Við ætluðum ekki að smíða alveg sérsniðna stafla sem byggir á Victoria og helsta vonin var að við gætum notað hann sem drop-in staðgengill fyrir InfluxDB.
Því miður er þetta ekki mögulegt, þrátt fyrir að InfluxDB samskiptareglur séu studdar, virkar hún aðeins til að taka upp mæligildi - aðeins Prometheus API er fáanlegt „utan“, sem þýðir að það verður ekki hægt að stilla Chronograf á það.
Þar að auki eru aðeins tölugildi studd fyrir mæligildi (við notuðum strengjagildi fyrir sérsniðnar mæligildi - meira um það í kaflanum ).
Augljóslega, af sömu ástæðu, getur VM ekki geymt annála eins og Influx gerir.
Einnig skal tekið fram að á þeim tíma sem leitað var að bestu lausninni var Victoria Metrics ekki enn svo vinsæl, skjölin voru mun minni og virknin var veikari
(Ég man ekki nákvæma lýsingu á klasaútgáfunni og sundrun).
Grunnval
Í kjölfarið var ákveðið að fyrir flugmanninn myndum við enn takmarka okkur við einn InfluxDB hnút.
Það voru nokkrar helstu ástæður fyrir þessu vali:
- Okkur líkaði mjög vel við alla virkni TICK staflasins
- Okkur tókst nú þegar að dreifa því og það virkaði frábærlega
- Frestarnir voru að renna út og það var ekki mikill tími eftir til að prófa aðra valkosti.
- Við áttum ekki von á svona miklu álagi
Við áttum ekki margar hlaupahjól í fyrsta áfanga tilraunarinnar og prófun á meðan á þróun stóð leiddi ekki í ljós nein frammistöðuvandamál.
Þess vegna ákváðum við að fyrir þetta verkefni væri einn innflæðishnútur nóg fyrir okkur án þess að þörf væri á mælikvarða (sjá niðurstöður aftast).
Við höfum ákveðið staflann og grunninn - nú um þá hluti sem eftir eru af TICK-staflanum.
Þéttir
Kapacitor er hluti af TICK staflanum, þjónustu sem getur fylgst með mæligildum sem fara inn í gagnagrunninn í rauntíma og framkvæmt ýmsar aðgerðir út frá reglum.
Almennt séð er það staðsett sem tæki til að fylgjast með frávikum og vélanámi (ég er ekki viss um að þessar aðgerðir séu eftirsóttar), en vinsælasta tilvikið um notkun þess er algengara - viðvörun.
Þannig notuðum við það fyrir tilkynningar. Við settum upp Slack viðvaranir þegar tiltekin vespu fór utan nets og það sama var gert fyrir snjallhleðslutæki og mikilvæga innviðahluta.
Þetta gerði það mögulegt að bregðast fljótt við vandamálum, auk þess að fá tilkynningar um að allt væri aftur í eðlilegt horf.
Einfalt dæmi: aukarafhlaða til að knýja „kassann“ okkar hefur bilað eða af einhverjum ástæðum orðið rafmagnslaus; einfaldlega með því að setja upp nýjan, eftir smá stund ættum við að fá tilkynningu um að virkni vespuns hafi verið endurheimt.
Í Influx 2.0 varð Kapacitor hluti af DB
Tímaskrá
Ég hef séð margar mismunandi UI lausnir fyrir eftirlit, en ég get sagt að hvað varðar virkni og UX, jafnast ekkert á við Chronograf.
Við byrjuðum að nota TICK stafla, einkennilega nóg, með Grafan sem vefviðmót.
Ég mun ekki lýsa virkni þess; allir þekkja víðtæka möguleika þess til að setja upp hvað sem er.
Hins vegar er Grafana enn algjörlega alhliða hljóðfæri á meðan Chronograf er aðallega hannað til notkunar með Influx.
Og auðvitað, þökk sé þessu, hefur Chronograf efni á miklu snjallari eða þægilegri virkni.
Kannski er helsta þægindin við að vinna með Chronograf að þú getur skoðað innra hluta InfluxDB í gegnum Explore.
Svo virðist sem Grafana hafi næstum sömu virkni, en í raun er hægt að setja upp mælaborð í Chronograf með nokkrum músarsmellum (á sama tíma skoða sjónmyndina þar), en í Grafana muntu samt fyrr eða síðar hafa til að breyta JSON stillingunum (að sjálfsögðu leyfir Chronograf að hlaða upp handstilltu strikatöflunum þínum og breyta þeim sem JSON ef þörf krefur - en ég þurfti aldrei að snerta þau eftir að hafa búið þau til í notendaviðmótinu).
Kibana hefur miklu ríkari möguleika til að búa til mælaborð og stýringar fyrir þau, en notendaviðmótið fyrir slíkar aðgerðir er mjög flókið.
Það þarf góðan skilning til að búa til þægilegt mælaborð. Og þó að virkni Chronograf mælaborða sé minni, þá er það miklu einfaldara að búa til og sérsníða þau.
Mælaborðin sjálf, fyrir utan skemmtilega sjónrænan stíl, eru í raun ekkert frábrugðin mælaborðunum í Grafana eða Kibana:
Svona lítur fyrirspurnarglugginn út:
Það er mikilvægt að hafa í huga, meðal annars, að með því að þekkja tegundir reita í InfluxDB gagnagrunninum getur tímatalningurinn sjálfur stundum hjálpað þér sjálfkrafa við að skrifa fyrirspurn eða velja rétta samsöfnunaraðgerð eins og meðaltal.
Og auðvitað er Chronograf eins þægilegt og mögulegt er til að skoða logs. Það lítur svona út:
Sjálfgefið er að Influx logs eru sérsniðnar til að nota syslog og því hafa þeir mikilvæga breytu - alvarleika.
Línuritið efst er sérstaklega gagnlegt, á því má sjá villurnar sem eiga sér stað og liturinn sýnir strax greinilega hvort alvarleikinn er meiri.
Nokkrum sinnum náðum við mikilvægum pöddum á þennan hátt, fórum að skoða annálana fyrir síðustu viku og sáum rauðan gadda.
Auðvitað væri best að setja upp viðvaranir fyrir slíkar villur, þar sem við höfum nú þegar allt fyrir þetta.
Við kveiktum meira að segja á þessu í smá stund, en í því ferli að undirbúa tilraunina kom í ljós að við fengum töluvert af villum (þar á meðal kerfisvillur eins og óaðgengi LTE netsins), sem „spammaðu“ Slack rásina. of mikið, án þess að valda neinum vandræðum. mikill ávinningur.
Rétta lausnin væri að meðhöndla flestar af þessum tegundum villna, stilla alvarleika þeirra og aðeins þá virkja viðvörun.
Þannig yrðu aðeins nýjar eða mikilvægar villur settar á Slack. Það var einfaldlega ekki nægur tími fyrir slíka uppsetningu miðað við þröngan tíma.
Auðkenning
Þess má líka geta að Chronograf styður OAuth og OIDC sem auðkenningu.
Þetta er mjög þægilegt þar sem það gerir þér kleift að tengja það auðveldlega við netþjóninn þinn og búa til fullgildan SSO.
Í okkar tilviki var þjónninn — það var notað til að tengjast eftirliti, en sami þjónninn var einnig notaður til að auðkenna vespur og beiðnir til bakendans.
„Stjórnandi“
Síðasti hluti sem ég mun lýsa er sjálfskrifað „stjórnborð“ okkar í Vue.
Í grundvallaratriðum er þetta bara sjálfstæð þjónusta sem sýnir upplýsingar um vespu úr okkar eigin gagnagrunnum, örþjónustum og mælikvarðagögnum frá InfluxDB samtímis.
Að auki voru margar stjórnunaraðgerðir fluttar þangað, svo sem neyðarendurræsingu eða fjaropnun á lás fyrir stuðningsteymið.
Það voru líka kort. Ég hef þegar nefnt að við byrjuðum með Grafana í stað Chronograf - vegna þess að fyrir Grafana eru kort fáanleg í formi viðbóta, þar sem við gætum skoðað hnit vespu. Því miður eru möguleikar kortagræja fyrir Grafana mjög takmarkaðir og þar af leiðandi var miklu auðveldara að skrifa eigið vefforrit með kortum á nokkrum dögum, til að sjá ekki aðeins hnitin í augnablikinu, heldur einnig sýna leiðina sem vespun tekur, geta síað gögnin á korti o.s.frv. (allur þessi virkni sem við gátum ekki stillt í einföldu mælaborði).
Einn af áðurnefndum kostum innflæðis er hæfileikinn til að búa til þínar eigin mælikvarða auðveldlega.
Þetta gerir það að verkum að hægt er að nota það fyrir gríðarstór fjölbreytni af atburðarás.
Við reyndum að skrá allar gagnlegar upplýsingar þar: rafhlöðuhleðslu, læsingarstöðu, afköst skynjara, Bluetooth, GPS og margar aðrar heilsufarsskoðanir.
Við birtum þetta allt á stjórnborðinu.
Auðvitað var mikilvægasta viðmiðið fyrir okkur rekstrarástand vespunnar - reyndar athugar Influx þetta sjálft og sýnir það með „grænum ljósum“ í hlutanum „Nodes“.
Þetta er gert með aðgerðinni — við notuðum það til að skilja frammistöðu kassans okkar og sendum sömu viðvaranir til Slack.
Við the vegur, við kölluðum vespurnar eftir nöfnum persóna úr Simpsons - það var svo þægilegt að greina þær frá hvor öðrum
Og almennt var þetta skemmtilegra svona. Setningar eins og „Strákar, Smithers er dáinn!“ heyrðust stöðugt.
Strengjamælingar
Það er mikilvægt að InfluxDB gerir þér kleift að geyma ekki aðeins töluleg gildi, eins og raunin er með Victoria Metrics.
Það virðist sem þetta sé ekki svo mikilvægt - þegar allt kemur til alls, fyrir utan logs, er hægt að geyma hvaða mælikvarða sem er í formi talna (bara bæta við kortlagningu fyrir þekkt ríki - eins konar upptalning)?
Í okkar tilviki var að minnsta kosti ein atburðarás þar sem strengjamælingar voru mjög gagnlegar.
Það gerðist bara þannig að birgir „snjallhleðslutækjanna“ okkar var þriðji aðili, við höfðum enga stjórn á þróunarferlinu og þeim upplýsingum sem þessi hleðslutæki gætu veitt.
Fyrir vikið var hleðsluforritið langt frá því að vera tilvalið, en aðalvandamálið var að við gátum ekki alltaf skilið ástand þeirra.
Þetta er þar sem Influx kom til bjargar. Við skrifuðum einfaldlega strengjastöðuna sem kom til okkar í InfluxDB gagnagrunnsreitinn án breytinga.
Í nokkurn tíma komust aðeins gildi eins og „á netinu“ og „ótengdur“ þangað, byggt á því hvaða upplýsingar voru birtar á stjórnborðinu okkar og tilkynningar voru sendar til Slack. Hins vegar, á einhverjum tímapunkti, fóru gildi eins og „aftengt“ líka að birtast þar.
Eins og síðar kom í ljós var þessi staða send einu sinni eftir að tenging rofnaði, ef hleðslutækið gat ekki komið á tengingu við netþjóninn eftir ákveðinn fjölda tilrauna.
Þannig að ef við notuðum aðeins fast sett af gildum gætum við ekki séð þessar breytingar á fastbúnaðinum á réttum tíma.
Og almennt veita strengjamælingar miklu fleiri möguleika til notkunar; þú getur skráð nánast allar upplýsingar í þeim. Þó að auðvitað þurfið þið líka að nota þetta tól vandlega.
Til viðbótar við venjulega mælikvarða, skráðum við einnig GPS staðsetningarupplýsingar í InfluxDB. Þetta var ótrúlega gagnlegt til að fylgjast með staðsetningu vespur á stjórnborðinu okkar.
Reyndar vissum við alltaf hvar og hvaða vespa var í augnablikinu sem við þurftum.
Þetta kom okkur mjög vel þegar við vorum að leita að vespu (sjá niðurstöður í lokin).
Innviðaeftirlit
Fyrir utan vespurnar sjálfar þurftum við líka að fylgjast með öllu (frekar umfangsmiklu) innviði okkar.
Mjög almenn arkitektúr leit einhvern veginn svona út:
Ef við auðkennum hreinan vöktunarstafla lítur hann svona út:
Það sem við viljum athuga í skýinu er:
- Gagnagrunna
- lyklaklæði
- Örþjónusta
Þar sem öll skýjaþjónusta okkar er staðsett í Kubernetes væri gaman að safna upplýsingum um ástand hennar.
Sem betur fer getur Telegraf út úr kassanum safnað miklum fjölda mælikvarða um ástand Kubernetes klasans og Chronograf býður strax upp á falleg mælaborð fyrir þetta.
Við fylgdumst aðallega með frammistöðu belganna og minnisnotkun. Ef um fall er að ræða, tilkynnir í Slack.
Það eru tvær leiðir til að fylgjast með fræbelgjum í Kubernetes: DaemonSet og Sidecar.
Báðum aðferðunum er lýst í smáatriðum .
Við notuðum Telegraf Sidecar og, auk mæligilda, söfnuðum við belgdagbókum.
Í okkar tilfelli þurftum við að fikta í stokkunum. Þrátt fyrir þá staðreynd að Telegraf geti dregið annála úr Docker API, vildum við hafa samræmt safn af annálum með endatækjunum okkar og stilla syslog fyrir gáma fyrir þetta. Kannski var þessi lausn ekki falleg, en ekki var kvartað yfir verkum hennar og annálarnir birtust vel í Chronograf.
Fylgjast með eftirliti???
Á endanum kom upp hin ævaforna spurning um eftirlit með vöktunarkerfum, en sem betur fer, eða því miður, höfðum við einfaldlega ekki nægan tíma til þess.
Þó að Telegraf geti auðveldlega sent eigin mælikvarða eða safnað mæligildum úr InfluxDB gagnagrunninum til að senda annað hvort á sama innflæði eða einhvers staðar annars staðar.
Niðurstöður
Hvaða ályktanir drógum við af niðurstöðum tilraunarinnar?
Hvernig geturðu gert eftirlit?
Í fyrsta lagi stóð TICK staflan fyllilega undir væntingum okkar og gaf okkur enn fleiri tækifæri en við bjuggumst við í upphafi.
Öll virkni sem við þurftum var til staðar. Allt sem við gerðum við það virkaði án vandræða.
Framleiðni
Helsta vandamálið með TICK stafla í ókeypis útgáfunni er skortur á stærðargetu. Þetta var ekki vandamál fyrir okkur.
Við söfnuðum ekki nákvæmum hleðslugögnum/tölum, heldur söfnuðum við gögnum frá um 30 vespum í einu.
Hver þeirra safnaði meira en þremur tugum mæligilda. Á sama tíma var annálum úr tækjunum safnað. Gagnasöfnun og sending átti sér stað á 10 sekúndna fresti.
Það er mikilvægt að hafa í huga að eftir eina og hálfa viku af tilrauninni, þegar meginhluti „barnavandamálanna“ var leiðréttur og mikilvægustu vandamálin höfðu þegar verið leyst, urðum við að draga úr tíðni sendingar gagna á netþjóninn til að 30 sekúndur. Þetta varð nauðsynlegt vegna þess að umferðin á LTE SIM-kortunum okkar fór að hverfa fljótt.
Megnið af umferðinni var neytt af logum; mælikvarðarnir sjálfir, jafnvel með 10 sekúndna millibili, sóuðu henni nánast ekki.
Fyrir vikið slökkvum við algjörlega á söfnun annála á tækjum eftir nokkurn tíma, þar sem sérstök vandamál voru þegar augljós jafnvel án stöðugrar söfnunar.
Í sumum tilfellum, ef það var samt nauðsynlegt að skoða annálana, tengdumst við einfaldlega í gegnum WireGuard í gegnum VPN.
Ég bæti líka við að hvert aðskilið umhverfi var aðskilið frá hvort öðru og álagið sem lýst er hér að ofan átti aðeins við um framleiðsluumhverfið.
Í þróunarumhverfinu bjuggum við til sérstakt InfluxDB tilvik sem hélt áfram að safna gögnum á 10 sekúndna fresti og við lentum ekki í neinum frammistöðuvandamálum.
TICK - tilvalið fyrir lítil og meðalstór verkefni
Byggt á þessum upplýsingum myndi ég álykta að TICK staflan sé tilvalin fyrir tiltölulega lítil verkefni eða verkefni sem búast örugglega ekki við neinni HighLoad.
Ef þú ert ekki með þúsundir belg eða hundruð véla, mun jafnvel eitt InfluxDB tilvik höndla álagið ágætlega.
Í sumum tilfellum gætir þú verið ánægður með Influx Relay sem frumstæða High Availability lausn.
Og auðvitað er enginn að hindra þig í að setja upp „lóðrétta“ mælikvarða og einfaldlega úthluta mismunandi netþjónum fyrir mismunandi gerðir mæligilda.
Ef þú ert ekki viss um væntanlegt álag á vöktunarþjónustuna, eða þú ert viss um að hafa/verður með mjög „þungan“ arkitektúr, myndi ég ekki mæla með því að nota ókeypis útgáfuna af TICK staflanum.
Auðvitað væri einföld lausn að kaupa - en hér get ég ekki tjáð mig einhvern veginn, þar sem ég sjálfur er ekki kunnugur fínleikunum. Fyrir utan þá staðreynd að það er mjög dýrt og hentar örugglega ekki litlum fyrirtækjum.
Í þessu tilviki, í dag, myndi ég mæla með því að leita að því að safna mælingum í gegnum Victoria Metrics og logs með Loki.
Að vísu ætla ég aftur að gera fyrirvara um að Loki/Grafana séu mun óþægilegri (vegna meiri fjölhæfni þeirra) en tilbúinn TICK, en þeir eru ókeypis.
Það er mikilvægt: allar upplýsingar sem lýst er hér eiga við um útgáfu Influx 1.8, í augnablikinu er Influx 2.0 að koma út.
Þó að ég hafi ekki haft tækifæri til að prófa það í bardagaaðstæðum og það er erfitt að draga ályktanir um endurbætur, hefur viðmótið örugglega orðið enn betra, arkitektúrinn hefur verið einfaldaður (án kapacitor og chronograf),
sniðmát birtust ("killer feature" - ). En því miður, í augnablikinu, hefur útgáfa 2 ekki lykilatriðið sem við völdum fyrstu útgáfuna fyrir - það er ekkert annálasafn.
Þessi virkni mun einnig birtast í Influx 2.0, en við gátum ekki fundið neina fresti, jafnvel áætlaða.
Hvernig á ekki að búa til IoT vettvang (nú)
Að lokum, eftir að hafa hleypt af stokkunum tilraunaverkefninu, settum við sjálf saman okkar eigin IoT stafla, þar sem ekki var valkostur sem hentaði samkvæmt okkar stöðlum.
Hins vegar nýlega er það fáanlegt í Beta útgáfu — það er leitt að hún var ekki til staðar þegar við byrjuðum að gera verkefnið.
Við erum fullkomlega sátt við lokaútkomuna og vettvang sem byggist á Ansible + TICK + WireGuard sem við settum saman sjálf. En í dag myndi ég mæla með því að skoða Balena betur áður en þú reynir að byggja upp þinn eigin IoT vettvang sjálfur.
Vegna þess að á endanum getur það gert flest af því sem við gerðum og OpenBalena er ókeypis og opinn uppspretta.
Það veit nú þegar hvernig á að senda ekki aðeins uppfærslur, heldur er VPN þegar innbyggt og sniðið til notkunar í IoT umhverfi.
Og nýlega gáfu þeir jafnvel út sína , sem tengist auðveldlega vistkerfi þeirra.
Hey, hvað með vespu sem saknað er?
Svo vespun, "Ralph", hvarf sporlaust.
Við hlupum strax til að skoða kortið í „stjórnborðinu“ okkar með GPS mæligildum frá InfluxDB.
Þökk sé eftirlitsgögnum komumst við auðveldlega að því að vespan fór af bílastæðinu um klukkan 21:00 síðasta dag, keyrði um hálftíma að einhverju svæði og var lagt til klukkan 5 að morgni við hlið þýskrar húss.
Eftir klukkan 5:XNUMX bárust engin eftirlitsgögn - þetta þýddi annað hvort að viðbótarrafhlaðan væri alveg tæmd eða að árásarmaðurinn fann loksins út hvernig ætti að fjarlægja snjallbúnaðinn úr vespu.
Þrátt fyrir það var lögreglan enn kölluð á heimilisfangið þar sem vespan var staðsett. Hlaupahjólið var ekki þar.
Eigandi hússins kom þó líka á óvart þar sem hann ók þessari vespu heim af skrifstofunni í gærkvöldi.
Eins og kom í ljós kom einn af stuðningsstarfsmönnum snemma morguns og sótti vespuna, sá að aukarafhlaðan hennar var algjörlega tæmd og fór með hana (gangandi) á bílastæðið. Og viðbótarrafhlaðan bilaði vegna raka.
Við stálum vespu af okkur sjálfum. Við the vegur, ég veit ekki hvernig og hver þá leysti málið með lögreglumálinu, en eftirlitið virkaði fullkomlega...
Heimild: www.habr.com