Flwyddyn yn ôl lansiwyd fersiwn peilot o brosiect hyrwyddo ar gyfer .
I ddechrau, enw'r prosiect oedd Road-To-Barcelona, yn ddiweddarach daeth yn Road-To-Berlin (felly R2B yn y sgrinluniau), ac yn y diwedd fe'i gelwir yn xRide.
Prif syniad y prosiect oedd hyn: yn lle cael gwasanaeth rhentu car neu sgwteri canolog (rydym yn sôn am sgwteri fel beiciau modur trydan, nid cic-sgwteri/sgwteri) roeddem am wneud llwyfan ar gyfer rhentu datganoledig. Am yr anawsterau a gawsom .
I ddechrau, roedd y prosiect yn canolbwyntio ar geir, ond oherwydd terfynau amser, cyfathrebu hynod hir gyda gweithgynhyrchwyr a nifer enfawr o gyfyngiadau diogelwch, dewiswyd sgwteri trydan ar gyfer y peilot.
Gosododd y defnyddiwr gais iOS neu Android ar y ffôn, aeth at y sgwter yr oedd yn ei hoffi, ac ar ôl hynny sefydlodd y ffôn a'r sgwter gysylltiad rhwng cymheiriaid, cyfnewidwyd ETH a gallai'r defnyddiwr ddechrau'r daith trwy droi'r sgwter ymlaen trwy y ffôn. Ar ddiwedd y daith, roedd hefyd yn bosibl talu am y daith gan ddefnyddio Ethereum o waled y defnyddiwr ar y ffôn.
Yn ogystal â sgwteri, gwelodd y defnyddiwr “chargers smart” yn y cymhwysiad, trwy ymweld y gallai'r defnyddiwr newid y batri presennol ei hun pe bai'n isel.
Dyma sut olwg oedd ar ein cynllun peilot yn gyffredinol, a lansiwyd ym mis Medi y llynedd mewn dwy ddinas yn yr Almaen: Bonn a Berlin.
Ac yna, un diwrnod, yn Bonn, yn gynnar yn y bore, hysbyswyd ein tîm cymorth (a leolir ar y safle i gadw sgwteri yn gweithio): roedd un o'r sgwteri wedi diflannu heb unrhyw olrhain.
Sut i ddod o hyd iddo a'i ddychwelyd?
Yn yr erthygl hon byddaf yn siarad am hyn, ond yn gyntaf - am sut y gwnaethom adeiladu ein platfform IoT ein hunain a sut y gwnaethom ei fonitro.
Beth a pham i fonitro: sgwteri, seilwaith, gorsafoedd gwefru?
Felly, beth oeddem ni eisiau ei fonitro yn ein prosiect?
Yn gyntaf oll, dyma'r sgwteri eu hunain - mae sgwteri trydan eu hunain yn eithaf drud, ni allwch lansio prosiect o'r fath heb fod yn ddigon parod; os yn bosibl, rydych chi am gasglu cymaint o wybodaeth â phosibl am y sgwteri: am eu lleoliad, lefel y tâl , etc.
Yn ogystal, hoffwn fonitro cyflwr ein seilwaith TG ein hunain - cronfeydd data, gwasanaethau a phopeth sydd ei angen arnynt i weithio. Roedd hefyd yn angenrheidiol i fonitro statws y “chargers smart”, rhag ofn iddynt dorri i lawr neu redeg allan o fatris llawn.
Sgwteri
Beth oedd ein sgwteri a beth oedden ni eisiau gwybod amdanyn nhw?
Y peth cyntaf a phwysicaf yw cyfesurynnau GPS, oherwydd diolch iddyn nhw gallwn ddeall ble maen nhw a ble maen nhw'n symud.
Nesaf yw'r tâl batri, diolch y gallwn benderfynu bod codi tâl y sgwteri yn dod i ben ac anfon juicer neu o leiaf rybuddio'r defnyddiwr.
Wrth gwrs, mae hefyd angen gwirio beth sy'n digwydd gyda'n cydrannau Caledwedd:
- mae bluetooth yn gweithio?
- a yw'r modiwl GPS ei hun yn gweithio?
- Roedd gennym hefyd broblem gyda'r ffaith y gallai'r GPS anfon cyfesurynnau anghywir a mynd yn sownd, a dim ond trwy wiriadau ychwanegol ar y sgwter y gellid pennu hyn,
a hysbysu'r cymorth cyn gynted â phosibl i ddatrys y mater
- Roedd gennym hefyd broblem gyda'r ffaith y gallai'r GPS anfon cyfesurynnau anghywir a mynd yn sownd, a dim ond trwy wiriadau ychwanegol ar y sgwter y gellid pennu hyn,
Ac yn olaf: gwiriadau o'r feddalwedd, gan ddechrau gyda'r OS a'r prosesydd, rhwydwaith a llwyth disg, gan orffen gyda gwiriadau o'n modiwlau ein hunain sy'n fwy penodol i ni (, ).
caledwedd
Beth oedd ein rhan “haearn”?
Gan ystyried yr amserlen fyrraf bosibl a'r angen am brototeipio cyflym, fe wnaethom ddewis yr opsiwn hawsaf ar gyfer gweithredu a dewis cydrannau - Raspberry Pi.
Yn ogystal â'r Rpi ei hun, roedd gennym fwrdd arferiad (a ddatblygwyd gennym ni ein hunain a'i archebu o Tsieina i gyflymu'r broses o gydosod y datrysiad terfynol) a set o gydrannau - ras gyfnewid (i droi ymlaen / i ffwrdd y sgwter), darllenydd gwefr batri, modem, antenâu. Cafodd hyn i gyd ei becynnu'n gryno mewn “blwch xRide” arbennig.
Dylid nodi hefyd bod y blwch cyfan yn cael ei bweru gan fanc pŵer ychwanegol, a oedd yn ei dro yn cael ei bweru gan brif batri'r sgwter.
Roedd hyn yn ei gwneud hi'n bosibl defnyddio monitro a throi'r sgwter ymlaen hyd yn oed ar ôl diwedd y daith, gan fod y prif batri wedi'i ddiffodd yn syth ar ôl troi'r allwedd tanio i'r safle “diffodd”.
Dociwr? Linux plaen? a lleoli
Gadewch i ni ddychwelyd at fonitro, felly Mafon - beth sydd gennym ni?
Un o'r pethau cyntaf yr oeddem am ei ddefnyddio i gyflymu'r broses o leoli, diweddaru a dosbarthu cydrannau i ddyfeisiau corfforol oedd Docker.
Yn anffodus, daeth yn amlwg yn gyflym fod gan Docker ar RPi, er ei fod yn gweithio, lawer o orbenion, yn enwedig o ran y defnydd o ynni.
Roedd y gwahaniaeth gan ddefnyddio’r AO “brodorol”, er nad oedd mor gryf, yn dal yn ddigon i ni fod yn wyliadwrus o’r posibilrwydd o golli gwefr yn rhy gyflym.
Yr ail reswm oedd un o'n llyfrgelloedd partner ar Node.js (sic!) - yr unig gydran o'r system nad oedd wedi'i hysgrifennu yn Go/C/C++.
Nid oedd gan awduron y llyfrgell amser i ddarparu fersiwn weithredol yn unrhyw un o'r ieithoedd “brodorol”.
Nid yn unig nad y nod ei hun yw'r ateb mwyaf cain ar gyfer dyfeisiau perfformiad isel, ond roedd y llyfrgell ei hun yn newynog iawn o ran adnoddau.
Sylweddolon ni, hyd yn oed petaen ni eisiau, y byddai defnyddio Docker yn ormod o orbenion i ni. Gwnaethpwyd y dewis o blaid yr OS brodorol a gweithio'n uniongyrchol oddi tano.
OS
O ganlyniad, fe wnaethom ni, unwaith eto, ddewis yr opsiwn symlaf fel yr OS a defnyddio Raspbian (Debian build for Pi).
Rydyn ni'n ysgrifennu ein holl feddalwedd yn Go, felly fe wnaethon ni hefyd ysgrifennu'r prif fodiwl asiant caledwedd yn ein system yn Go.
Ef sy'n gyfrifol am weithio gyda GPS, Bluetooth, darllen y tâl, troi'r sgwter ymlaen, ac ati.
Defnyddio
Cododd y cwestiwn ar unwaith am yr angen i weithredu mecanwaith ar gyfer cyflwyno diweddariadau i ddyfeisiau (OTA) - diweddariadau i'n hasiant / cymhwysiad ei hun, a diweddariadau i'r OS / cadarnwedd ei hun (gan y gallai fersiynau newydd o'r asiant fod angen diweddariadau i'r cnewyllyn neu gydrannau system, llyfrgelloedd, ac ati).
Ar ôl dadansoddiad eithaf hir o'r farchnad, daeth yn amlwg bod yna lawer iawn o atebion ar gyfer cyflwyno diweddariadau i'r ddyfais.
O gyfleustodau gweddol syml, yn bennaf sy'n canolbwyntio ar ddiweddaru/cist ddeuol fel swupd/SWUpdate/OStree i lwyfannau llawn fel Mender a Balena.
Yn gyntaf oll, penderfynasom fod gennym ddiddordeb mewn atebion diwedd-i-ddiwedd, felly disgynnodd y dewis ar lwyfannau ar unwaith.
Eich Hun wedi'i eithrio oherwydd y ffaith ei fod mewn gwirionedd yn defnyddio'r un Dociwr y tu mewn i'w balenaEngine.
Ond nodaf, er gwaethaf hyn, inni ddefnyddio eu cynnyrch yn gyson yn y diwedd ar gyfer firmware fflach ar gardiau SD - cyfleustodau syml a hynod gyfleus ar gyfer hyn.
Felly, yn y diwedd disgynnodd y dewis ymlaen . Mae Mender yn llwyfan cyflawn ar gyfer cydosod, cyflwyno a gosod firmware.
Ar y cyfan mae'r platfform yn edrych yn wych, ond fe gymerodd tua wythnos a hanner i ni adeiladu'r fersiwn gywir o'n cadarnwedd gan ddefnyddio'r adeiladwr mender.
A pho fwyaf y byddwn yn ymgolli yn y cymhlethdodau o'i ddefnyddio, y mwyaf y daeth yn amlwg y byddai angen llawer mwy o amser nag oedd gennym i'w ddefnyddio'n llawn.
Ysywaeth, roedd ein terfynau amser tynn yn golygu ein bod yn cael ein gorfodi i roi'r gorau i ddefnyddio Mender a dewis un symlach fyth.
Ateb
Yr ateb symlaf yn ein sefyllfa ni oedd defnyddio Ansible. Roedd cwpl o lyfrau chwarae yn ddigon i ddechrau.
Eu hanfod oedd ein bod yn cysylltu o'r gwesteiwr (gweinydd CI) trwy ssh i'n mafon a dosbarthu diweddariadau iddynt.
Ar y cychwyn cyntaf, roedd popeth yn syml - roedd yn rhaid i chi fod ar yr un rhwydwaith â'r dyfeisiau, roedd arllwys yn cael ei wneud trwy Wi-Fi.
Yn y swyddfa, yn syml, roedd dwsin o fafon prawf wedi'u cysylltu â'r un rhwydwaith, roedd gan bob dyfais gyfeiriad IP sefydlog hefyd wedi'i nodi yn Ansible Inventory.
Ansible a ddanfonodd ein hasiant monitro i'r dyfeisiau terfynol
3G / LTE
Yn anffodus, dim ond yn y modd datblygu y gallai'r achos defnydd hwn ar gyfer Ansible weithio cyn i ni gael sgwteri gwirioneddol.
Oherwydd nad yw sgwteri, fel y deallwch, yn eistedd yn gysylltiedig ag un llwybrydd Wi-Fi, gan aros yn gyson am ddiweddariadau dros y rhwydwaith.
Mewn gwirionedd, ni all sgwteri gael unrhyw gysylltiad o gwbl heblaw am 3G/LTE symudol (a hyd yn oed wedyn nid drwy'r amser).
Mae hyn ar unwaith yn gosod llawer o broblemau a chyfyngiadau, megis cyflymder cysylltiad isel a chyfathrebu ansefydlog.
Ond y peth pwysicaf yw na allwn ddibynnu ar IP sefydlog a neilltuwyd i'r rhwydwaith mewn rhwydwaith 3G/LTE.
Mae hyn yn cael ei ddatrys yn rhannol gan rai darparwyr cardiau SIM; mae hyd yn oed cardiau SIM arbennig wedi'u cynllunio ar gyfer dyfeisiau IoT gyda chyfeiriadau IP sefydlog. Ond nid oedd gennym fynediad at gardiau SIM o'r fath ac ni allem ddefnyddio cyfeiriadau IP.
Wrth gwrs, roedd yna syniadau i wneud rhyw fath o gofrestru cyfeiriadau IP neu ddarganfod gwasanaeth yn rhywle fel Conswl, ond bu'n rhaid i ni roi'r gorau i syniadau o'r fath, oherwydd yn ein profion gallai'r cyfeiriad IP newid yn rhy aml, a arweiniodd at ansefydlogrwydd mawr.
Am y rheswm hwn, nid y defnydd mwyaf cyfleus ar gyfer cyflwyno metrigau fyddai defnyddio'r model tynnu, lle byddem yn mynd at ddyfeisiau ar gyfer y metrigau angenrheidiol, ond yn gwthio, gan ddosbarthu metrigau o'r ddyfais yn uniongyrchol i'r gweinydd.
VPN
Fel ateb i'r broblem hon, fe wnaethom ddewis VPN - yn benodol .
Roedd cleientiaid (sgwteri) ar ddechrau'r system wedi'u cysylltu â'r gweinydd VPN ac yn gallu cysylltu â nhw. Defnyddiwyd y twnnel hwn i gyflwyno diweddariadau.
Mewn egwyddor, gellid defnyddio'r un twnnel ar gyfer monitro, ond roedd cysylltiad o'r fath yn fwy cymhleth ac yn llai dibynadwy na gwthio syml.
Adnoddau cwmwl
Yn olaf, mae angen monitro ein gwasanaethau cwmwl a chronfeydd data, gan ein bod yn defnyddio Kubernetes ar eu cyfer, yn ddelfrydol fel bod defnyddio monitro yn y clwstwr mor syml â phosibl. Yn ddelfrydol, gan ddefnyddio , oherwydd ar gyfer defnydd, rydym yn ei ddefnyddio yn y rhan fwyaf o achosion. Ac, wrth gwrs, i fonitro'r cwmwl mae angen i chi ddefnyddio'r un atebion ag ar gyfer y sgwteri eu hunain.
Wedi rhoi
Phew, mae'n ymddangos ein bod wedi datrys y disgrifiad, gadewch i ni wneud rhestr o'r hyn yr oedd ei angen arnom yn y diwedd:
- Ateb cyflym, gan fod angen monitro eisoes yn ystod y broses ddatblygu
- Cyfaint/swm – angen llawer o fetrigau
- Mae angen casglu boncyffion
- Dibynadwyedd - mae data yn hanfodol i lansio llwyddiant
- Ni allwch ddefnyddio'r model tynnu - mae angen gwthio arnoch
- Mae angen monitro unedig nid yn unig caledwedd, ond hefyd cwmwl
Roedd y ddelwedd olaf yn edrych rhywbeth fel hyn
Dewis stac
Felly, roeddem yn wynebu’r cwestiwn o ddewis pentwr monitro.
Yn gyntaf oll, roeddem yn chwilio am yr ateb popeth-mewn-un mwyaf cyflawn a fyddai'n cwmpasu ein holl ofynion ar yr un pryd, ond ar yr un pryd yn ddigon hyblyg i deilwra ei ddefnydd i'n hanghenion. Eto i gyd, cawsom lawer o gyfyngiadau wedi'u gosod arnom gan galedwedd, pensaernïaeth a therfynau amser.
Mae yna amrywiaeth enfawr o atebion monitro, gan ddechrau gyda systemau llawn fel , neu ac yn gorffen gydag atebion parod ar gyfer rheoli Fflyd.
I ddechrau, roedd yr olaf yn ymddangos fel ateb delfrydol i ni, ond nid oedd gan rai fonitro llawn, roedd gan eraill alluoedd cyfyngedig iawn o'r fersiynau rhad ac am ddim, ac nid oedd eraill yn ymdrin â'n “heisiau” neu nid oeddent yn ddigon hyblyg i gyd-fynd â'n senarios. Mae rhai yn hen ffasiwn yn syml.
Ar ôl dadansoddi nifer o atebion tebyg, daethom i'r casgliad yn gyflym y byddai'n haws ac yn gyflymach i gydosod pentwr tebyg ein hunain. Bydd, bydd ychydig yn fwy cymhleth na defnyddio platfform rheoli Fflyd cwbl barod, ond ni fydd yn rhaid i ni gyfaddawdu.
Bron yn sicr, yn yr holl doreth enfawr o atebion, mae yna un parod eisoes a fyddai'n hollol addas i ni, ond yn ein hachos ni roedd yn llawer cyflymach ymgynnull pentwr penodol ar ein pennau ein hunain a'i addasu “i ni ein hunain” yn hytrach na profi cynhyrchion parod.
Gyda hyn oll, ni wnaethom ymdrechu i gydosod platfform monitro cyfan ein hunain, ond roeddem yn chwilio am y staciau “parod” mwyaf swyddogaethol, dim ond gyda'r gallu i'w ffurfweddu'n hyblyg.
(B)ELK?
Yr ateb cyntaf a ystyriwyd mewn gwirionedd oedd y pentwr ELK adnabyddus.
Mewn gwirionedd, dylid ei alw'n BELK, oherwydd mae'r cyfan yn dechrau gyda Beats -
Wrth gwrs, ELK yw un o'r atebion mwyaf enwog a phwerus ym maes monitro, a hyd yn oed yn fwy felly wrth gasglu a phrosesu logiau.
Ein bwriad oedd y byddai ELK yn cael ei ddefnyddio i gasglu boncyffion ac yn ogystal â storio metrigau a gafwyd gan Prometheus yn y tymor hir.
Ar gyfer delweddu gallwch ddefnyddio Grafan.
Mewn gwirionedd, gall y pentwr ELK newydd gasglu metrigau yn annibynnol (metricbeat), a gall Kibana hefyd eu harddangos.
Ond o hyd, tyfodd ELK allan o logiau i ddechrau a hyd yn hyn mae gan ymarferoldeb y metrigau nifer o anfanteision difrifol:
- Yn sylweddol arafach na Prometheus
- Yn integreiddio i lawer llai o leoedd na Prometheus
- Mae'n anodd gosod rhybuddion ar eu cyfer
- Mae metrigau'n cymryd llawer o le
- Mae sefydlu dangosfyrddau gyda metrigau yn Kiban yn llawer mwy cymhleth nag yn Grafan
Yn gyffredinol, mae'r metrigau yn ELK yn drwm ac nid ydynt eto mor gyfleus ag mewn datrysiadau eraill, y mae llawer mwy ohonynt bellach na Prometheus yn unig: TSDB, Victoria Metrics, Cortex, ac ati, ac ati. Wrth gwrs, hoffwn gael ateb popeth-mewn-un llawn ar unwaith, ond yn achos curiad metrig roedd gormod o gyfaddawdau.
Ac mae gan y pentwr ELK ei hun nifer o eiliadau anodd:
- Mae'n drwm, weithiau hyd yn oed yn drwm iawn os ydych chi'n casglu swm eithaf mawr o ddata
- Mae angen i chi "wybod sut i'w goginio" - mae angen i chi ei raddio, ond nid yw hyn yn ddibwys i'w wneud
- Fersiwn am ddim wedi'i thynnu i lawr - nid oes gan y fersiwn am ddim rybuddion arferol, ac ar adeg y dewis nid oedd unrhyw ddilysiad
Rhaid imi ddweud bod y pwynt olaf yn ddiweddar wedi dod yn well ac yn ychwanegol (gan gynnwys dilysu) dechreuodd y model prisio ei hun newid.
Ond ar yr adeg pan oeddem yn mynd i ddefnyddio'r ateb hwn, nid oedd unrhyw rybuddio o gwbl.
Efallai y gallem fod wedi ceisio adeiladu rhywbeth gan ddefnyddio ElastAlert neu atebion cymunedol eraill, ond fe wnaethom benderfynu ystyried dewisiadau eraill o hyd.
Loki - Grafana - Prometheus
Ar hyn o bryd, efallai mai ateb da fyddai adeiladu pentwr monitro yn seiliedig yn unig ar Prometheus fel darparwr metrigau, Loki ar gyfer boncyffion, ac ar gyfer delweddu gallwch ddefnyddio'r un Grafana.
Yn anffodus, ar adeg dechrau peilot gwerthiant y prosiect (Medi-Hydref 19), roedd Loki yn dal i fod yn fersiwn beta 0.3-0.4, ac ar adeg dechrau'r datblygiad ni ellid ei ystyried fel datrysiad cynhyrchu. o gwbl.
Nid oes gennyf brofiad eto o ddefnyddio Loki mewn prosiectau difrifol, ond gallaf ddweud bod Promtail (asiant ar gyfer casglu boncyffion) yn gweithio'n wych ar gyfer metel noeth a chodau mewn kubernetes.
TOCYN
Efallai mai dim ond y pentwr TICIWCH all alw'r dewis arall mwyaf teilwng (yr unig?) i'r pentwr ELK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Disgrifiaf yr holl gydrannau isod yn fanylach, ond y syniad cyffredinol yw hyn:
- Telegraf - asiant ar gyfer casglu metrigau
- InfluxDB - cronfa ddata metrigau
- Kapacitor - prosesydd metrigau amser real ar gyfer rhybuddio
- Chronograf - panel gwe ar gyfer delweddu
Ar gyfer InfluxDB, Kapacitor a Chronograf mae siartiau helm swyddogol yr oeddem yn eu defnyddio i'w defnyddio.
Dylid nodi, yn y fersiwn ddiweddaraf o Influx 2.0 (beta), daeth Kapacitor a Chronograf yn rhan o InfluxDB ac nad ydynt bellach yn bodoli ar wahân.
Telegraff
yn asiant ysgafn iawn ar gyfer casglu metrigau ar beiriant cyflwr.
Gall fonitro llawer iawn o bopeth, o i
gweinydd .
Mae ganddo nifer o fanteision cŵl:
- Cyflym ac ysgafn (wedi'i ysgrifennu yn Go)
- Yn bwyta lleiafswm o adnoddau
- Gwthio metrigau yn ddiofyn
- Yn casglu'r holl fetrigau angenrheidiol
- Metrigau system heb unrhyw osodiadau
- Metrigau caledwedd megis gwybodaeth o synwyryddion
- Mae'n hawdd iawn ychwanegu eich metrigau eich hun
- Llawer o ategion allan o'r bocs
- Yn casglu logiau
Gan fod metrigau gwthio yn angenrheidiol i ni, roedd yr holl fanteision eraill yn fwy nag ychwanegiadau dymunol.
Mae casglu boncyffion gan yr asiant ei hun hefyd yn gyfleus iawn, gan nad oes angen cysylltu cyfleustodau ychwanegol ar gyfer logio logiau.
Mae mewnlifiad yn cynnig y profiad mwyaf cyfleus ar gyfer gweithio gyda logiau os ydych chi'n defnyddio .
Yn gyffredinol, mae Telegraf yn asiant gwych ar gyfer casglu metrigau, hyd yn oed os nad ydych chi'n defnyddio gweddill y pentwr ICK.
Mae llawer o bobl yn ei groesi ag ELK a chronfeydd data cyfres amser amrywiol eraill er hwylustod, oherwydd gall ysgrifennu metrigau bron yn unrhyw le.
MewnlifDB
InfluxDB yw prif graidd y pentwr TICK, sef cronfa ddata cyfres amser ar gyfer metrigau.
Yn ogystal â metrigau, gall Mewnlifiad hefyd storio logiau, er, yn y bôn, dim ond yr un metrigau yw logiau ar ei gyfer, dim ond yn lle'r dangosyddion rhifiadol arferol, mae'r brif swyddogaeth yn cael ei chyflawni gan linell o destun log.
Mae InfluxDB hefyd wedi'i ysgrifennu yn Go ac mae'n ymddangos ei fod yn rhedeg yn llawer cyflymach o'i gymharu ag ELK ar ein clwstwr (nid y mwyaf pwerus).
Byddai un o fanteision cŵl Mewnlifiad hefyd yn cynnwys API cyfleus a chyfoethog iawn ar gyfer ymholiadau data, a ddefnyddiwyd gennym yn weithredol iawn.
Anfanteision - $$$ neu raddio?
Dim ond un anfantais a ddarganfuom sydd gan stac TICK - fe annwyl. Hyd yn oed yn fwy.
Beth sydd gan y fersiwn taledig nad oes gan y fersiwn am ddim?
Cyn belled ag yr oeddem yn gallu deall, yr unig wahaniaeth rhwng y fersiwn taledig o'r pentwr TICK a'r un am ddim yw'r galluoedd graddio.
Sef, gallwch godi clwstwr gydag argaeledd Uchel yn unig yn .
Os ydych chi eisiau HA llawn, mae angen i chi naill ai dalu neu ddefnyddio rhai baglau. Mae yna gwpl o atebion cymunedol - er enghraifft edrych fel ateb cymwys, ond mae'n ysgrifenedig nad yw'n addas ar gyfer cynhyrchu, yn ogystal â
- datrysiad syml gyda phwmpio data trwy NATS (bydd yn rhaid ei raddio hefyd, ond gellir datrys hyn).
Mae'n drueni, ond mae'n ymddangos bod y ddau ohonyn nhw wedi'u gadael - nid oes unrhyw ymrwymiadau newydd, rwy'n cymryd mai'r mater yw'r datganiad a ddisgwylir yn fuan o'r fersiwn newydd o Influx 2.0, lle bydd llawer o bethau'n wahanol (nid oes unrhyw wybodaeth am graddio ynddo eto).
Yn swyddogol mae fersiwn am ddim - mewn gwirionedd, mae hwn yn HA cyntefig, ond dim ond trwy gydbwyso,
gan y bydd yr holl ddata'n cael ei ysgrifennu at bob achos InfluxDB y tu ôl i'r balans llwyth.
Mae ganddo rai megis problemau posibl gyda phwyntiau trosysgrifo a'r angen i greu seiliau ar gyfer metrigau ymlaen llaw
(sy'n digwydd yn awtomatig yn ystod gwaith arferol gydag InfluxDB).
Eithr , mae hyn yn golygu gorbenion ychwanegol ar gyfer metrigau dyblyg (prosesu a storio) efallai na fydd eu hangen arnoch, ond nid oes unrhyw ffordd i'w gwahanu.
Victoria Metrics?
O ganlyniad, er gwaethaf y ffaith ein bod yn gwbl fodlon â'r stack TICK ym mhopeth heblaw graddio â thâl, penderfynasom weld a oedd unrhyw atebion am ddim a allai ddisodli cronfa ddata InfluxDB, tra'n gadael y cydrannau T_CK sy'n weddill.
Mae yna lawer o gronfeydd data cyfres amser, ond yr un mwyaf addawol yw Victoria Metrics, mae ganddo nifer o fanteision:
- Cyflym a hawdd, o leiaf yn ôl y canlyniadau
- Mae yna fersiwn clwstwr, y mae hyd yn oed adolygiadau da amdano nawr
- Mae hi'n gallu darnio
- Yn cefnogi protocol InfluxDB
Nid oeddem yn bwriadu adeiladu pentwr cwbl bwrpasol yn seiliedig ar Victoria a'r prif obaith oedd y gallem ei ddefnyddio yn lle galw heibio InfluxDB.
Yn anffodus, nid yw hyn yn bosibl, er gwaethaf y ffaith bod y protocol InfluxDB yn cael ei gefnogi, dim ond ar gyfer cofnodi metrigau y mae'n gweithio - dim ond yr API Prometheus sydd ar gael “y tu allan”, sy'n golygu na fydd yn bosibl gosod Chronograf arno.
Ar ben hynny, dim ond gwerthoedd rhifol sy'n cael eu cefnogi ar gyfer metrigau (fe wnaethom ddefnyddio gwerthoedd llinynnol ar gyfer metrigau arfer - mwy ar hynny yn yr adran ).
Yn amlwg, am yr un rheswm, ni all y VM storio logiau fel y mae Influx yn ei wneud.
Hefyd, dylid nodi, ar adeg chwilio am yr ateb gorau posibl, nad oedd Victoria Metrics mor boblogaidd eto, roedd y ddogfennaeth yn llawer llai ac roedd y swyddogaeth yn wannach.
(Dydw i ddim yn cofio disgrifiad manwl o'r fersiwn clwstwr a'r darnio).
Dewis sylfaen
O ganlyniad, penderfynwyd ar gyfer y peilot y byddem yn dal i gyfyngu ein hunain i un nod InfluxDB.
Roedd sawl prif reswm dros y dewis hwn:
- Roeddem yn hoff iawn o holl ymarferoldeb y pentwr TICK
- Rydym eisoes wedi llwyddo i'w ddefnyddio ac fe weithiodd yn wych
- Roedd y dyddiadau cau yn dod i ben ac nid oedd llawer o amser ar ôl i brofi opsiynau eraill.
- Nid oeddem yn disgwyl llwyth mor drwm
Nid oedd gennym lawer o sgwteri ar gyfer cam cyntaf y peilot, ac ni ddatgelodd profion yn ystod y datblygiad unrhyw faterion perfformiad.
Felly, fe wnaethom benderfynu ar gyfer y prosiect hwn y byddai un nod Mewnlifiad yn ddigon i ni heb fod angen graddio (gweler y casgliadau ar y diwedd).
Rydyn ni wedi penderfynu ar y pentwr a'r sylfaen - nawr am y cydrannau sy'n weddill o'r stack TICK.
Capacitor
Mae Kapacitor yn rhan o'r stack TICK, gwasanaeth sy'n gallu monitro metrigau sy'n mynd i mewn i'r gronfa ddata mewn amser real a chyflawni amrywiol gamau gweithredu yn seiliedig ar reolau.
Yn gyffredinol, fe'i lleolir fel offeryn ar gyfer olrhain anghysondebau posibl a dysgu peiriannau (nid wyf yn siŵr bod galw am y swyddogaethau hyn), ond mae'r achos mwyaf poblogaidd o'i ddefnyddio yn fwy cyffredin - rhybuddio.
Dyna sut y gwnaethom ei ddefnyddio ar gyfer hysbysiadau. Fe wnaethom sefydlu rhybuddion Slack pan aeth sgwter penodol oddi ar-lein, a gwnaed yr un peth ar gyfer chargers smart a chydrannau seilwaith pwysig.
Roedd hyn yn ei gwneud hi'n bosibl ymateb yn gyflym i broblemau, yn ogystal â derbyn hysbysiadau bod popeth yn ôl i normal.
Enghraifft syml: mae batri ychwanegol i bweru ein “blwch” wedi torri i lawr neu am ryw reswm wedi rhedeg allan o bŵer; dim ond trwy osod un newydd, ar ôl ychydig dylem dderbyn hysbysiad bod ymarferoldeb y sgwter wedi'i adfer.
Yn Mewnlifiad 2.0 daeth Kapacitor yn rhan o DB
Cronograf
Rwyf wedi gweld llawer o wahanol atebion UI ar gyfer monitro, ond gallaf ddweud, o ran ymarferoldeb ac UX, nad oes dim yn cymharu â Chronograf.
Dechreuon ni ddefnyddio'r pentwr TICK, yn rhyfedd ddigon, gyda Grafan fel rhyngwyneb gwe.
Ni fyddaf yn disgrifio ei ymarferoldeb; mae pawb yn gwybod ei bosibiliadau eang ar gyfer sefydlu unrhyw beth.
Fodd bynnag, mae Grafana yn dal i fod yn offeryn cwbl gyffredinol, tra bod Chronograf wedi'i gynllunio'n bennaf i'w ddefnyddio gyda Mewnlifiad.
Ac wrth gwrs, diolch i hyn, gall Chronograf fforddio ymarferoldeb llawer mwy clyfar neu gyfleus.
Efallai mai prif gyfleustra gweithio gyda Chronograf yw y gallwch weld y tu mewn i'ch InfluxDB trwy Explore.
Mae'n ymddangos bod gan Grafana ymarferoldeb bron yn union yr un fath, ond mewn gwirionedd, gellir sefydlu dangosfwrdd yn Chronograf gydag ychydig o gliciau llygoden (ar yr un pryd yn edrych ar y delweddu yno), tra yn Grafana byddwch yn dal i gael yn hwyr neu'n hwyrach. i olygu'r cyfluniad JSON (wrth gwrs mae Chronograf yn caniatáu uwchlwytho'ch dashas wedi'i ffurfweddu â llaw a'u golygu fel JSON os oes angen - ond ni fu'n rhaid i mi erioed eu cyffwrdd ar ôl eu creu ar yr UI).
Mae gan Kibana alluoedd llawer cyfoethocach ar gyfer creu dangosfyrddau a rheolyddion ar eu cyfer, ond mae'r UX ar gyfer gweithrediadau o'r fath yn gymhleth iawn.
Bydd angen rhywfaint o ddealltwriaeth dda i greu dangosfwrdd cyfleus. Ac er bod ymarferoldeb dangosfyrddau Chronograf yn llai, mae eu gwneud a'u haddasu yn llawer symlach.
Nid yw'r dangosfyrddau eu hunain, ar wahân i'r arddull weledol ddymunol, yn wahanol i'r dangosfyrddau yn Grafana neu Kibana:
Dyma sut olwg sydd ar y ffenestr ymholiad:
Mae'n bwysig nodi, ymhlith pethau eraill, y gall gwybod y mathau o feysydd yn y gronfa ddata InfluxDB, y chronograff ei hun weithiau eich helpu'n awtomatig i ysgrifennu Ymholiad neu ddewis y swyddogaeth agregu gywir fel cymedr.
Ac wrth gwrs, mae Chronograf mor gyfleus â phosibl ar gyfer gwylio logiau. Mae'n edrych fel hyn:
Yn ddiofyn, mae logiau Influx wedi'u teilwra i ddefnyddio syslog ac felly mae ganddyn nhw baramedr pwysig - difrifoldeb.
Mae'r graff ar y brig yn arbennig o ddefnyddiol; arno gallwch weld y gwallau sy'n digwydd ac mae'r lliw yn dangos yn glir ar unwaith a yw'r difrifoldeb yn uwch.
Cwpl o weithiau fe ddalion ni chwilod pwysig fel hyn, mynd i weld y boncyffion am yr wythnos ddiwethaf a gweld pigyn coch.
Wrth gwrs, yn ddelfrydol byddai'n gosod rhybuddion ar gyfer gwallau o'r fath, gan fod gennym ni bopeth ar gyfer hyn eisoes.
Fe wnaethon ni hyd yn oed droi hyn ymlaen am ychydig, ond yn y broses o baratoi'r peilot, daeth yn amlwg ein bod yn cael cryn dipyn o wallau (gan gynnwys rhai system fel nad oedd rhwydwaith LTE ar gael), a oedd yn “spamio” sianel Slack. gormod, heb achosi unrhyw broblemau, budd mawr.
Yr ateb cywir fyddai ymdrin â'r rhan fwyaf o'r mathau hyn o wallau, addasu'r difrifoldeb ar eu cyfer, a dim ond wedyn galluogi rhybuddio.
Fel hyn, dim ond gwallau newydd neu bwysig fyddai'n cael eu postio i Slack. Yn syml, nid oedd digon o amser ar gyfer trefniant o'r fath o ystyried y terfynau amser tynn.
Dilysu
Mae'n werth nodi hefyd bod Chronograf yn cefnogi OAuth ac OIDC fel dilysiad.
Mae hyn yn gyfleus iawn, gan ei fod yn caniatáu ichi ei gysylltu'n hawdd â'ch gweinydd a chreu SSO llawn.
Yn ein hachos ni, roedd y gweinydd — fe'i defnyddiwyd i gysylltu â monitro, ond defnyddiwyd yr un gweinydd hefyd i ddilysu sgwteri a cheisiadau i'r pen ôl.
“Gweinyddol”
Y gydran olaf y byddaf yn ei disgrifio yw ein “panel gweinyddol” hunan-ysgrifenedig yn Vue.
Yn y bôn, dim ond gwasanaeth annibynnol ydyw sy'n arddangos gwybodaeth sgwteri o'n cronfeydd data ein hunain, microwasanaethau, a data metrigau gan InfluxDB ar yr un pryd.
Yn ogystal, symudwyd llawer o swyddogaethau gweinyddol yno, megis ailgychwyn brys neu agor clo o bell ar gyfer y tîm cymorth.
Roedd mapiau hefyd. Soniais eisoes ein bod wedi dechrau gyda Grafana yn lle Chronograf - oherwydd ar gyfer Grafana mae mapiau ar gael ar ffurf ategion, y gallem weld cyfesurynnau sgwteri arnynt. Yn anffodus, mae galluoedd teclynnau map Grafana yn gyfyngedig iawn, ac o ganlyniad, roedd yn llawer haws ysgrifennu eich cymhwysiad gwe eich hun gyda mapiau mewn ychydig ddyddiau, er mwyn nid yn unig weld y cyfesurynnau ar hyn o bryd, ond hefyd arddangos y llwybr a gymerwyd gan y sgwter, gallu hidlo'r data ar fap, ac ati (yr holl swyddogaethau na allem eu ffurfweddu mewn dangosfwrdd syml).
Un o fanteision Mewnlifiad a grybwyllwyd eisoes yw'r gallu i greu eich metrigau eich hun yn hawdd.
Mae hyn yn caniatáu iddo gael ei ddefnyddio ar gyfer amrywiaeth enfawr o senarios.
Fe wnaethom geisio cofnodi'r holl wybodaeth ddefnyddiol yno: tâl batri, statws clo, perfformiad synhwyrydd, bluetooth, GPS, a llawer o wiriadau iechyd eraill.
Fe wnaethon ni arddangos hyn i gyd ar y panel gweinyddol.
Wrth gwrs, y maen prawf pwysicaf i ni oedd cyflwr gweithredu'r sgwter - mewn gwirionedd, mae Mewnlifiad yn gwirio hyn ei hun ac yn ei ddangos gyda “goleuadau gwyrdd” yn yr adran Nodes.
Gwneir hyn gan y swyddogaeth - fe wnaethom ei ddefnyddio i ddeall perfformiad ein blwch ac anfon yr un rhybuddion hynny at Slack.
Gyda llaw, fe wnaethon ni enwi'r sgwteri ar ôl enwau cymeriadau The Simpsons - roedd hi mor gyfleus eu gwahaniaethu oddi wrth ei gilydd
Ac yn gyffredinol roedd yn fwy o hwyl fel hyn. Roedd ymadroddion fel “Guys, Smithers is dead!” yn cael eu clywed yn gyson.
Mesuryddion llinyn
Mae'n bwysig bod InfluxDB yn caniatáu ichi storio nid yn unig gwerthoedd rhifol, fel yn achos Victoria Metrics.
Mae'n ymddangos nad yw hyn mor bwysig - wedi'r cyfan, ar wahân i logiau, gellir storio unrhyw fetrigau ar ffurf rhifau (dim ond ychwanegu mapio ar gyfer gwladwriaethau hysbys - math o enum)?
Yn ein hachos ni, roedd o leiaf un senario lle roedd metrigau llinynnol yn ddefnyddiol iawn.
Yn union fel y digwyddodd bod cyflenwr ein “chargers smart” yn drydydd parti, nid oedd gennym unrhyw reolaeth dros y broses ddatblygu a'r wybodaeth y gallai'r gwefrwyr hyn ei darparu.
O ganlyniad, roedd yr API codi tâl ymhell o fod yn ddelfrydol, ond y brif broblem oedd na allem ddeall eu cyflwr bob amser.
Dyma lle daeth Mewnlifiad i'r adwy. Yn syml, fe wnaethom ni ysgrifennu'r statws llinyn a ddaeth atom ni i faes cronfa ddata InfluxDB heb newidiadau.
Am beth amser, dim ond gwerthoedd fel “ar-lein” ac “all-lein” a gyrhaeddodd yno, yn seiliedig ar ba wybodaeth a arddangoswyd yn ein panel gweinyddol, ac anfonwyd hysbysiadau at Slack. Fodd bynnag, ar ryw adeg, dechreuodd gwerthoedd fel “datgysylltu” ymddangos yno hefyd.
Fel y digwyddodd yn ddiweddarach, anfonwyd y statws hwn unwaith ar ôl colli cysylltiad, os na allai'r charger sefydlu cysylltiad â'r gweinydd ar ôl nifer penodol o ymdrechion.
Felly, pe baem ond yn defnyddio set sefydlog o werthoedd, efallai na fyddwn yn gweld y newidiadau hyn yn y firmware ar yr amser iawn.
Ac yn gyffredinol, mae metrigau llinynnol yn darparu llawer mwy o bosibiliadau i'w defnyddio; gallwch chi gofnodi bron unrhyw wybodaeth ynddynt. Er, wrth gwrs, mae angen i chi hefyd ddefnyddio'r offeryn hwn yn ofalus.
Yn ogystal â'r metrigau arferol, fe wnaethom hefyd gofnodi gwybodaeth am leoliad GPS yn InfluxDB. Roedd hyn yn hynod ddefnyddiol ar gyfer monitro lleoliad sgwteri yn ein panel gweinyddol.
Yn wir, roeddem bob amser yn gwybod ble a pha sgwter oedd ar hyn o bryd yr oedd ei angen arnom.
Roedd hyn yn ddefnyddiol iawn i ni pan oeddem yn chwilio am sgwter (gweler y casgliadau ar y diwedd).
Monitro seilwaith
Yn ogystal â'r sgwteri eu hunain, roedd angen i ni hefyd fonitro ein seilwaith cyfan (braidd yn helaeth).
Roedd pensaernïaeth gyffredinol iawn yn edrych fel hyn:
Os ydym yn tynnu sylw at bentwr monitro pur, mae'n edrych fel hyn:
Yr hyn yr hoffem ei wirio yn y cwmwl yw:
- Cronfeydd data
- clogyn
- Microwasanaethau
Gan fod ein holl wasanaethau cwmwl wedi'u lleoli yn Kubernetes, byddai'n braf casglu gwybodaeth am ei gyflwr.
Yn ffodus, gall Telegraf allan o'r bocs gasglu nifer enfawr o fetrigau am gyflwr clwstwr Kubernetes, ac mae Chronograf ar unwaith yn cynnig dangosfyrddau hardd ar gyfer hyn.
Fe wnaethom fonitro perfformiad y codennau a'r defnydd o gof yn bennaf. Mewn achos o gwymp, rhybuddion yn Slack.
Mae dwy ffordd i olrhain codennau yn Kubernetes: DaemonSet a Sidecar.
Disgrifir y ddau ddull yn fanwl .
Fe wnaethom ddefnyddio Telegraf Sidecar ac, yn ogystal â metrigau, casglwyd logiau pod.
Yn ein hachos ni, roedd yn rhaid i ni tincian gyda'r boncyffion. Er gwaethaf y ffaith y gall Telegraf dynnu logiau o'r API Docker, roeddem am gael casgliad unffurf o logiau gyda'n dyfeisiau diwedd a syslog wedi'i ffurfweddu ar gyfer cynwysyddion ar gyfer hyn. Efallai nad oedd yr ateb hwn yn brydferth, ond ni chafwyd unrhyw gwynion am ei waith ac roedd y boncyffion wedi'u harddangos yn dda yn Chronograf.
Monitro monitro???
Yn y diwedd, cododd y cwestiwn oesol o fonitro systemau monitro, ond yn ffodus, neu’n anffodus, yn syml iawn, nid oedd gennym ddigon o amser ar gyfer hyn.
Er y gall Telegraf anfon ei fetrigau ei hun yn hawdd neu gasglu metrigau o gronfa ddata InfluxDB i'w hanfon naill ai i'r un Mewnlifiad neu i rywle arall.
Canfyddiadau
Pa gasgliadau y daethom iddynt o ganlyniadau'r peilot?
Sut allwch chi wneud monitro?
Yn gyntaf oll, roedd pentwr TICK yn cwrdd â'n disgwyliadau yn llawn ac yn rhoi hyd yn oed mwy o gyfleoedd i ni na'r hyn yr oeddem yn ei ddisgwyl i ddechrau.
Roedd yr holl ymarferoldeb yr oedd ei angen arnom yn bresennol. Roedd popeth a wnaethom ag ef yn gweithio heb broblemau.
Cynhyrchiant
Y brif broblem gyda'r pentwr TICK yn y fersiwn am ddim yw diffyg galluoedd graddio. Nid oedd hyn yn broblem i ni.
Ni wnaethom gasglu data/ffigurau llwyth union, ond casglwyd data o tua 30 o sgwteri ar y tro.
Casglodd pob un ohonynt fwy na thri dwsin o fetrigau. Ar yr un pryd, casglwyd logiau o'r dyfeisiau. Roedd data'n cael ei gasglu a'i anfon bob 10 eiliad.
Mae'n bwysig nodi, ar ôl wythnos a hanner o'r peilot, pan gafodd y rhan fwyaf o'r “briwiau plentyndod” eu cywiro a'r problemau pwysicaf eisoes wedi'u datrys, bu'n rhaid i ni leihau amlder anfon data i'r gweinydd i 30 eiliad. Daeth hyn yn angenrheidiol oherwydd dechreuodd y traffig ar ein cardiau SIM LTE ddiflannu'n gyflym.
Roedd mwyafrif y traffig yn cael ei ddefnyddio gan foncyffion; yn ymarferol nid oedd y metrigau eu hunain, hyd yn oed gydag egwyl o 10 eiliad, yn ei wastraffu.
O ganlyniad, ar ôl peth amser fe wnaethom analluogi'r casgliad o logiau ar ddyfeisiau yn llwyr, gan fod problemau penodol eisoes yn amlwg hyd yn oed heb eu casglu'n gyson.
Mewn rhai achosion, os oedd angen edrych ar y logiau o hyd, fe wnaethom gysylltu trwy WireGuard trwy VPN.
Byddaf hefyd yn ychwanegu bod pob amgylchedd ar wahân wedi'i wahanu oddi wrth ei gilydd, a bod y llwyth a ddisgrifir uchod yn berthnasol i'r amgylchedd cynhyrchu yn unig.
Yn yr amgylchedd datblygu, codwyd enghraifft InfluxDB ar wahân a oedd yn parhau i gasglu data bob 10 eiliad ac ni aethom i unrhyw broblemau perfformiad.
TICIWCH - delfrydol ar gyfer prosiectau bach a chanolig
Yn seiliedig ar y wybodaeth hon, byddwn yn dod i'r casgliad bod y stack TICK yn ddelfrydol ar gyfer prosiectau neu brosiectau cymharol fach nad ydynt yn bendant yn disgwyl unrhyw HighLoad.
Os nad oes gennych filoedd o godennau neu gannoedd o beiriannau, bydd hyd yn oed un enghraifft InfluxDB yn trin y llwyth yn iawn.
Mewn rhai achosion, efallai y byddwch yn fodlon ar Gyfnewid Mewnlifiad fel ateb Argaeledd Uchel cyntefig.
Ac, wrth gwrs, nid oes unrhyw un yn eich atal rhag sefydlu graddio “fertigol” a dim ond dyrannu gwahanol weinyddion ar gyfer gwahanol fathau o fetrigau.
Os nad ydych chi'n siŵr am y llwyth disgwyliedig ar y gwasanaethau monitro, neu os ydych chi'n sicr o gael / y bydd gennych chi bensaernïaeth “drwm” iawn, ni fyddwn yn argymell defnyddio'r fersiwn am ddim o'r stack TICK.
Wrth gwrs, ateb syml fyddai prynu - ond yma ni allaf wneud sylw rhywsut, gan nad wyf fy hun yn gyfarwydd â'r cynnil. Heblaw am y ffaith ei fod yn ddrud iawn ac yn bendant nid yw'n addas ar gyfer cwmnïau bach.
Yn yr achos hwn, heddiw, byddwn yn argymell edrych tuag at gasglu metrigau trwy Victoria Metrics a logiau gan ddefnyddio Loki.
Yn wir, byddaf yn gwneud amheuaeth eto bod Loki/Grafana yn llawer llai cyfleus (oherwydd eu bod yn fwy amlbwrpas) na'r TICIWCH parod, ond maen nhw'n rhad ac am ddim.
Mae'n bwysig: mae'r holl wybodaeth a ddisgrifir yma yn berthnasol i fersiwn Mewnlif 1.8, ar hyn o bryd mae Mewnlifiad 2.0 ar fin cael ei ryddhau.
Er nad wyf wedi cael cyfle i roi cynnig arno mewn amodau ymladd ac mae'n anodd dod i gasgliadau am welliannau, mae'r rhyngwyneb yn bendant wedi dod yn well fyth, mae'r bensaernïaeth wedi'i symleiddio (heb kapacitor a chronograf),
ymddangosodd templedi (“nodwedd lladdwr” - ). Ond, yn anffodus, ar hyn o bryd, nid oes gan fersiwn 2 y peth allweddol y dewisom y fersiwn gyntaf ar ei gyfer - nid oes casgliad o logiau.
Bydd y swyddogaeth hon hefyd yn ymddangos yn Mewnlif 2.0, ond ni allem ddod o hyd i unrhyw derfynau amser, hyd yn oed rhai bras.
Sut i beidio â gwneud llwyfannau IoT (nawr)
Yn y diwedd, ar ôl lansio'r cynllun peilot, fe wnaethom ni ein hunain ymgynnull ein pentwr IoT llawn ein hunain, yn absenoldeb dewis arall sy'n addas yn ôl ein safonau.
Fodd bynnag, yn ddiweddar mae ar gael mewn fersiwn Beta — mae'n drueni nad oedd hi yno pan ddechreuon ni wneud y prosiect.
Rydym yn gwbl fodlon â'r canlyniad terfynol a'r platfform yn seiliedig ar Ansible + TICK + WireGuard y gwnaethom ei ymgynnull ein hunain. Ond heddiw, byddwn yn argymell edrych yn agosach ar Balena cyn ceisio adeiladu eich platfform IoT eich hun eich hun.
Oherwydd yn y pen draw gall wneud y rhan fwyaf o'r hyn a wnaethom, ac mae OpenBalena yn ffynhonnell agored am ddim.
Mae eisoes yn gwybod sut i anfon diweddariadau nid yn unig, ond hefyd mae VPN eisoes wedi'i ymgorffori a'i deilwra i'w ddefnyddio mewn amgylchedd IoT.
Ac yn ddiweddar, fe wnaethon nhw hyd yn oed ryddhau eu , sy'n cysylltu'n hawdd â'u hecosystem.
Hei, beth am y sgwter coll?
Felly diflannodd y sgwter, "Ralph", heb unrhyw olrhain.
Aethom ati ar unwaith i edrych ar y map yn ein “panel gweinyddol”, gyda data metrigau GPS gan InfluxDB.
Diolch i ddata monitro, fe wnaethom benderfynu'n hawdd bod y sgwter wedi gadael y maes parcio tua 21:00 y diwrnod diwethaf, wedi gyrru tua hanner awr i ryw ardal ac wedi'i barcio tan 5 am wrth ymyl tŷ Almaeneg.
Ar ôl 5 am, ni dderbyniwyd unrhyw ddata monitro - roedd hyn yn golygu naill ai bod y batri ychwanegol wedi'i ryddhau'n llwyr, neu fe wnaeth yr ymosodwr ddarganfod o'r diwedd sut i dynnu'r caledwedd smart o'r sgwter.
Er gwaethaf hyn, roedd yr heddlu'n dal i gael eu galw i'r cyfeiriad lle roedd y sgwter wedi'i leoli. Nid oedd y sgwter yno.
Fodd bynnag, roedd perchennog y tŷ hefyd wedi'i synnu gan hyn, gan ei fod mewn gwirionedd yn marchogaeth y sgwter hwn adref o'r swyddfa neithiwr.
Fel y digwyddodd, cyrhaeddodd un o'r gweithwyr cymorth yn gynnar yn y bore a chodi'r sgwter, gan weld bod ei batri ychwanegol wedi'i ollwng yn llwyr a'i gludo (ar droed) i'r maes parcio. A methodd y batri ychwanegol oherwydd lleithder.
Fe wnaethon ni ddwyn y sgwter oddi wrth ein hunain. Gyda llaw, nid wyf yn gwybod sut a phwy a ddatrysodd y mater gydag achos yr heddlu, ond fe weithiodd y monitro yn berffaith...
Ffynhonnell: hab.com