Antaŭ unu jaro ni lanĉis pilotversion de varba projekto por .
Komence, la projekto nomiĝis Road-To-Barcelona, poste ĝi iĝis Road-To-Berlin (tial R2B en la ekrankopioj), kaj finfine ĝi nomiĝis xRide.
La ĉefa ideo de la projekto estis ĉi tio: anstataŭ havi centralizitan aŭton aŭ skoter-luoservon (ni parolas pri skoteroj alinome elektraj motorcikloj, ne piedskuteroj/skoteroj) ni volis fari platformon por malcentralizita luo. Pri la malfacilaĵoj, kiujn ni renkontis .
Komence, la projekto temigis aŭtojn, sed pro templimoj, ekstreme longaj komunikadoj kun produktantoj kaj grandega nombro da sekurecaj limigoj, elektraj skoteroj estis elektitaj por la piloto.
La uzanto instalis iOS aŭ Android-aplikaĵon sur la telefono, alproksimiĝis al la skotero kiun li ŝatis, post kio la telefono kaj la skotero establis kunulan konekton, ETH estis interŝanĝita kaj la uzanto povis komenci la veturon enŝaltante la skoteron per la telefonon. Ĉe la fino de la vojaĝo, ankaŭ eblis pagi la vojaĝon uzante Ethereum de la monujo de la uzanto en la telefono.
Aldone al skoteroj, la uzanto vidis "inteligentajn ŝargilojn" en la aplikaĵo, vizitante kiujn la uzanto povus ŝanĝi la nunan baterion mem se ĝi estis malalta.
Ĝenerale tiel aspektis nia piloto, lanĉita en septembro pasintjare en du germanaj urboj: Bonn kaj Berlino.
Kaj tiam, iun tagon, en Bonn, frumatene, nia subtena teamo (situanta surloke por konservi skoterojn en funkciado) estis atentigita: unu el la skoteroj malaperis senspuro.
Kiel trovi ĝin kaj redoni ĝin?
En ĉi tiu artikolo mi parolos pri tio, sed unue - pri kiel ni konstruis nian propran IoT-platformon kaj kiel ni monitoris ĝin.
Kion kaj kial monitori: skoterojn, infrastrukturojn, ŝarĝajn staciojn?
Do, kion ni volis kontroli en nia projekto?
Antaŭ ĉio, ĉi tiuj estas la skoteroj mem - elektraj skoteroj mem estas sufiĉe multekostaj, vi ne povas lanĉi tian projekton sen esti sufiĉe preparita; se eble, vi volas kolekti kiel eble plej multe da informoj pri la skoteroj: pri ilia loko, ŝargnivelo. , ktp.
Krome, mi ŝatus kontroli la staton de nia propra IT-infrastrukturo - datumbazoj, servoj kaj ĉio, kion ili bezonas por funkcii. Necesis ankaŭ kontroli la staton de la "inteligentaj ŝargiloj", en la okazo, se ili rompiĝis aŭ elĉerpigis plenajn kuirilarojn.
Skoteroj
Kio estis niaj skoteroj kaj kion ni volis scii pri ili?
La unua kaj plej grava afero estas GPS-koordinatoj, ĉar danke al ili ni povas kompreni kie ili estas kaj kien ili moviĝas.
Tuj poste estas la kuirilaro, dank' al kiu ni povas determini, ke la ŝarĝo de la skoteroj finiĝas kaj sendi sukigilon aŭ almenaŭ averti la uzanton.
Kompreneble, ankaŭ necesas kontroli kio okazas kun niaj Aparataj komponantoj:
- ĉu bluetooth funkcias?
- ĉu la GPS-modulo mem funkcias?
- Ni ankaŭ havis problemon kun la fakto, ke la GPS povis sendi malĝustajn koordinatojn kaj blokiĝi, kaj ĉi tio povus esti determinita nur per pliaj kontroloj sur la skotero,
kaj sciigu subtenon kiel eble plej baldaŭ por solvi la problemon
- Ni ankaŭ havis problemon kun la fakto, ke la GPS povis sendi malĝustajn koordinatojn kaj blokiĝi, kaj ĉi tio povus esti determinita nur per pliaj kontroloj sur la skotero,
Kaj laste: kontroloj de la programaro, komencante per la OS kaj procesoro, reto kaj disko-ŝarĝo, finiĝante per kontroloj de niaj propraj moduloj kiuj estas pli specifaj por ni (, ).
aparataro
Kio estis nia "fera" parto?
Konsiderante la plej mallongan eblan tempokadron kaj la bezonon de rapida prototipado, ni elektis la plej facilan opcion por efektivigo kaj elekto de komponantoj - Raspberry Pi.
Krom la Rpi mem, ni havis kutiman tabulon (kiun ni mem evoluigis kaj mendis el Ĉinio por akceli la muntan procezon de la fina solvo) kaj aron da komponantoj - relajso (por ŝalti/malŝalti la skoteron), leganto de kuirilaro, modemo, antenoj. Ĉio ĉi estis kompakte pakita en speciala "xRide-skatolo".
Oni devas ankaŭ rimarki, ke la tuta skatolo estis funkciigita de plia elektra banko, kiu siavice estis funkciigita de la ĉefa baterio de la skotero.
Ĉi tio ebligis uzi monitoradon kaj ŝalti la skoteron eĉ post la fino de la vojaĝo, ĉar la ĉefa kuirilaro estis malŝaltita tuj post turnado de la ŝaltilo al la "for" pozicio.
Docker? Simpla Linukso? kaj deplojo
Ni revenu al monitorado, do Frambo - kion ni havas?
Unu el la unuaj aferoj, kiujn ni volis uzi por akceli la procezon de deplojado, ĝisdatigo kaj liverado de komponantoj al fizikaj aparatoj estis Docker.
Bedaŭrinde, rapide evidentiĝis, ke Docker sur RPi, kvankam ĝi funkcias, havas multe da ŝarĝo, precipe rilate al elektrokonsumo.
La diferenco uzanta la "denaskan" OS, kvankam ne tiom forta, tamen sufiĉis por ke ni zorgu pri la ebleco perdi ŝargon tro rapide.
La dua kialo estis unu el niaj partneraj bibliotekoj en Node.js (sic!) - la sola komponanto de la sistemo, kiu ne estis skribita en Go/C/C++.
La aŭtoroj de la biblioteko ne havis tempon por disponigi funkciantan version en iu ajn el la "denaskaj" lingvoj.
Ne nur la nodo mem ne estas la plej eleganta solvo por malaltefikecaj aparatoj, sed la biblioteko mem estis tre rimeda.
Ni rimarkis, ke, eĉ se ni volus, uzi Docker estus tro da superkosto por ni. La elekto estis farita en favoro de la indiĝena OS kaj laboranta rekte sub ĝi.
OS
Kiel rezulto, ni denove elektis la plej simplan opcion kiel la OS kaj uzis Raspbian (Debian-konstruaĵo por Pi).
Ni skribas nian tutan programaron en Go, do ni ankaŭ skribis la ĉefan aparatan agenmodulon en nia sistemo en Go.
Estas li, kiu respondecas pri laboro kun GPS, Bluetooth, legado de la ŝarĝo, ŝaltado de la skotero ktp.
Deploji
La demando tuj ekestis pri la bezono efektivigi mekanismon por liveri ĝisdatigojn al aparatoj (OTA) - kaj ĝisdatigojn al nia agento/aplikaĵo mem, kaj ĝisdatigojn al la OS/firmvaro mem (ĉar novaj versioj de la agento povus postuli ĝisdatigojn al la kerno). aŭ sistemkomponentoj, bibliotekoj, ktp.).
Post sufiĉe longa analizo de la merkato, montriĝis, ke ekzistas sufiĉe multaj solvoj por liveri ĝisdatigojn al la aparato.
De relative simplaj, plejparte ĝisdatigaj/du-botigaj orientitaj utilecoj kiel swupd/SWUpdate/OSTree ĝis plenrajtaj platformoj kiel Mender kaj Balena.
Antaŭ ĉio, ni decidis, ke ni interesiĝas pri finfinaj solvoj, do la elekto tuj falis sur platformojn.
Ŝi mem estis ekskludita pro la fakto ke ĝi efektive uzas la saman Docker ene de sia balenaEngine.
Sed mi rimarkas, ke malgraŭ tio, ni finis konstante uzi ilian produkton por fulmfirmvaro sur SD-kartoj - simpla kaj ege oportuna ilo por tio.
Tial finfine la elekto falis . Mender estas kompleta platformo por kunmeti, liveri kaj instali firmware.
Ĝenerale la platformo aspektas bonege, sed ni bezonis proksimume semajnon kaj duonon por konstrui la ĝustan version de nia firmvaro uzante la riparilon.
Kaj ju pli ni mergis nin en la komplikaĵojn de ĝia uzo, des pli evidentiĝis, ke por plene deploji ĝin ni bezonos multe pli da tempo ol ni havis.
Ve, niaj striktaj templimoj signifis, ke ni estis devigitaj forlasi la uzon de Mender kaj elekti eĉ pli simplan.
Respondema
Самым простым решением в нашей ситуации оказалось использование Ansible. Пары playbook’ов для начала было вполне достаточно.
Ilia esenco estis, ke ni simple konektis de la gastiganto (CI-servilo) per ssh al niaj framboj kaj distribuis ĝisdatigojn al ili.
Ĉe la komenco, ĉio estis simpla - vi devis esti en la sama reto kun la aparatoj, verŝado estis farita per Wi-Fi.
En la oficejo estis simple dekduo da provaj framboj konektitaj al la sama reto, ĉiu aparato havis statikan IP-adreson ankaŭ specifitan en Ansible Inventory.
Estis Ansible, kiu liveris nian monitoran agenton al la finaj aparatoj
3G / LTE
Bedaŭrinde, ĉi tiu uzkazo por Ansible povus funkcii nur en disvolva reĝimo antaŭ ol ni havis realajn skoterojn.
Ĉar skoteroj, kiel vi komprenas, ne sidas konektitaj al unu Wi-Fi-enkursigilo, konstante atendante ĝisdatigojn tra la reto.
En realeco, skoteroj tute ne povas havi ajnan konekton krom movebla 3G/LTE (kaj eĉ tiam ne ĉiam).
Ĉi tio tuj trudas multajn problemojn kaj limigojn, kiel malaltan konektan rapidon kaj malstabila komunikado.
Sed la plej grava afero estas, ke en reto 3G/LTE ni ne povas simple fidi al statika IP asignita al la reto.
Ĉi tio estas parte solvita de kelkaj SIM-kartprovizantoj; ekzistas eĉ specialaj SIM-kartoj dizajnitaj por IoT-aparatoj kun senmovaj IP-adresoj. Sed ni ne havis aliron al tiaj SIM-kartoj kaj ne povis uzi IP-adresojn.
Kompreneble, estis ideoj por fari ian registradon de IP-adresoj alinome servo-malkovro ie kiel Konsulo, sed ni devis forlasi tiajn ideojn, ĉar en niaj testoj la IP-adreso povus tro ofte ŝanĝiĝi, kio kondukis al granda malstabileco.
Tial, la plej oportuna uzo por liverado de metrikoj ne estus uzi la tiran modelon, kie ni irus al aparatoj por la necesaj metrikoj, sed puŝus, liverante metrikojn de la aparato rekte al la servilo.
VPN
Kiel solvo al ĉi tiu problemo, ni elektis VPN - specife .
Klientoj (skuteroj) ĉe la komenco de la sistemo konektita al la VPN-servilo kaj povis konekti al ili. Ĉi tiu tunelo estis uzata por liveri ĝisdatigojn.
En teorio, la sama tunelo povus esti uzata por monitorado, sed tia ligo estis pli komplika kaj malpli fidinda ol simpla puŝo.
Nubaj rimedoj
Laste, necesas monitori niajn nubajn servojn kaj datumbazojn, ĉar ni uzas Kubernetes por ili, ideale por ke disfaldi monitoradon en la areto estu kiel eble plej simpla. Ideale, uzante , ĉar por deplojo, ni uzas ĝin en la plej multaj kazoj. Kaj, kompreneble, por monitori la nubon vi devas uzi la samajn solvojn kiel por la skoteroj mem.
Donita
Huf, ŝajnas, ke ni ordigis la priskribon, ni faru liston de tio, kion ni bezonis finfine:
- Rapida solvo, ĉar monitorado estas necesa jam dum la disvolva procezo
- Volumo/kvanto - multaj metrikoj necesas
- Registrokolekto estas postulata
- Fidindeco - datumoj estas kritikaj por lanĉi sukceson
- Vi ne povas uzi la tiran modelon - vi bezonas puŝon
- Ni bezonas unuecan monitoradon de ne nur aparataro, sed ankaŭ de nubo
La fina bildo aspektis io tiel
Elekto de stako
Do, ni alfrontis la demandon pri elekto de monitora stako.
Antaŭ ĉio, ni serĉis la plej kompletan tut-en-unuan solvon, kiu samtempe kovrus ĉiujn niajn postulojn, sed samtempe estus sufiĉe fleksebla por adapti ĝian uzon al niaj bezonoj. Tamen, ni havis multajn limigojn truditaj al ni de aparataro, arkitekturo kaj limdatoj.
Estas grandega vario de monitoraj solvoj, komencante per plenrajtaj sistemoj kiel , aŭ kaj finiĝante kun pretaj solvoj por Flota administrado.
Komence, ĉi-lasta ŝajnis ideala solvo por ni, sed iuj ne havis plenan monitoradon, aliaj havis severe limigitajn kapablojn de la senpagaj versioj, kaj aliaj simple ne kovris niajn "dezirojn" aŭ ne estis sufiĉe flekseblaj por konveni niajn scenarojn. Iuj estas simple malmodernaj.
Analizinte kelkajn similajn solvojn, ni rapide venis al la konkludo, ke estus pli facile kaj rapide kunmeti mem similan stakon. Jes, ĝi estos iom pli komplika ol disfaldi tute pretan Fleet-administradplatformon, sed ni ne devos fari kompromisojn.
Preskaŭ certe, en la tuta grandega abundo da solvoj, ekzistas jam preta, kiu tute konvenus al ni, sed en nia kazo estis multe pli rapide kunmeti certan stakon memstare kaj personecigi ĝin "por ni mem" prefere ol. provante pretajn produktojn.
Kun ĉio ĉi, ni ne strebis mem kunmeti tutan monitoran platformon, sed serĉis la plej funkciajn "pretajn" stakojn, nur kun la kapablo flekseble agordi ilin.
(B)ELK?
La unua solvo kiu estis fakte pripensita estis la konata ELK-stako.
Fakte, ĝi devus nomi BELK, ĉar ĉio komenciĝas per Beats -
Kompreneble, ELK estas unu el la plej famaj kaj potencaj solvoj en la kampo de monitorado, kaj eĉ pli en kolektado kaj prilaborado de ŝtipoj.
Ni intencis ke ELK estus uzata por kolekti tagalojn kaj ankaŭ longdaŭran konservadon de metrikoj akiritaj de Prometheus.
Por bildigo vi povas uzi Grafan.
Fakte, la nova ELK-stako povas kolekti metrikojn sendepende (metricbeat), kaj Kibana ankaŭ povas montri ilin.
Sed tamen, ELK komence kreskis el protokoloj kaj ĝis nun la funkcieco de la metrikoj havas kelkajn gravajn malavantaĝojn:
- Signife pli malrapida ol Prometeo
- Integriĝas en multe malpli da lokoj ol Prometeo
- Estas malfacile agordi atentigojn por ili
- Metriko okupas multe da spaco
- Agordi panelojn kun metrikoj en Kiban estas multe pli komplika ol en Grafan
Ĝenerale, la metrikoj en ELK estas pezaj kaj ankoraŭ ne tiel oportunaj kiel en aliaj solvoj, el kiuj estas nun multe pli ol nur Prometeo: TSDB, Victoria Metrics, Cortex, ktp., ktp. Kompreneble, mi vere ŝatus havi plenrajtan tut-en-unuan solvon tuj, sed en la kazo de metricbeat estis tro multaj kompromisoj.
Kaj la ELK-stako mem havas kelkajn malfacilajn momentojn:
- Ĝi estas peza, foje eĉ tre peza se vi kolektas sufiĉe grandan kvanton da datumoj
- Vi devas "scii kiel kuiri" ĝin - vi devas skali ĝin, sed ĉi tio ne estas bagatela fari.
- Senpaga versio senpaga - la senpaga versio ne havas normalan atentigon, kaj dum la elekto ne estis aŭtentikigo
Mi devas diri, ke lastatempe la lasta punkto pliboniĝis kaj krome (inkluzive de aŭtentigo) la prezmodelo mem komencis ŝanĝiĝi.
Sed en la momento, kiam ni estis disfaldi ĉi tiun solvon, tute ne estis atentigo.
Eble ni povus esti provinta konstrui ion uzante ElastAlert aŭ aliajn komunumajn solvojn, sed ni tamen decidis konsideri aliajn alternativojn.
Lokio - Grafana - Prometeo
Nuntempe, bona solvo povus esti konstrui monitoran stakon bazitan nur sur Prometheus kiel metrika provizanto, Loki por protokoloj, kaj por bildigo vi povas uzi la saman Grafana.
Bedaŭrinde, en la momento de la komenco de la vendopiloto de la projekto (septembro-oktobro 19), Loki ankoraŭ estis en beta-versio 0.3-0.4, kaj en la momento de la komenco de evoluo ĝi ne povus esti konsiderata kiel produktada solvo. entute.
Mi ankoraŭ ne havas sperton efektive uzi Lokion en seriozaj projektoj, sed mi povas diri, ke Promtail (agento por kolektado de ŝtipoj) bonege funkcias kaj por nuda metalo kaj balgoj en kubernetoj.
TIKTO
Eble la plej inda (la nura?) plentaŭga alternativo al la ELK-stako nun povas nur esti nomita la TICK-stako - Telegraf, InfluxDB, Chronograf, Kapacitor.
Mi priskribos ĉiujn komponantojn sube pli detale, sed la ĝenerala ideo estas jena:
- Telegraf - agento por kolektado de metrikoj
- InfluxDB - metrika datumbazo
- Kapacitor - realtempa metrika procesoro por atentigo
- Chronograf - retejo panelo por bildigo
Por InfluxDB, Kapacitor kaj Chronograf ekzistas oficialaj stirilaj leteroj, kiujn ni uzis por deploji ilin.
Notu, ke en la plej nova versio de Influx 2.0 (beta), Kapacitor kaj Chronograf fariĝis parto de InfluxDB kaj ne plu ekzistas aparte.
Telegrafo
estas tre malpeza agento por kolekti metrikojn sur ŝtatmaŝino.
Li povas monitori grandegan kvanton de ĉio, de por
servilo .
Ĝi havas kelkajn bonegajn avantaĝojn:
- Rapida kaj malpeza (skribita en Go)
- Manĝas minimuman kvanton da rimedoj
- Puŝu metrikojn defaŭlte
- Kolektas ĉiujn necesajn metrikojn
- Sistemaj metrikoj sen iuj agordoj
- Aparataj metrikoj kiel informoj de sensiloj
- Estas tre facile aldoni viajn proprajn metrikojn
- Multaj kromprogramoj el la skatolo
- Kolektas ŝtipojn
Ĉar puŝaj metrikoj estis necesaj por ni, ĉiuj aliaj avantaĝoj estis pli ol agrablaj aldonoj.
Kolekto de protokoloj fare de la agento mem ankaŭ estas tre oportuna, ĉar ne necesas konekti pliajn ilojn por registri protokolojn.
Influx ofertas la plej oportunan sperton por labori kun ŝtipoj se vi uzas .
Telegraf estas ĝenerale bonega agento por kolekti metrikojn, eĉ se vi ne uzas la reston de la ICK-stako.
Multaj homoj krucas ĝin kun ELK kaj diversaj aliaj temp-seriaj datumbazoj por oportuno, ĉar ĝi povas skribi metrikojn preskaŭ ie ajn.
InfluxDB
InfluxDB estas la ĉefa kerno de la TICK-stako, nome temp-seria datumbazo por metrikoj.
Krom metrikoj, Influx ankaŭ povas stoki protokolojn, kvankam, esence, protokoloj por ĝi estas nur la samaj metrikoj, nur anstataŭ la kutimaj nombraj indikiloj, la ĉefa funkcio estas plenumita per linio de protokolo-teksto.
InfluxDB ankaŭ estas skribita en Go kaj ŝajnas funkcii multe pli rapide kompare kun ELK sur nia (ne la plej potenca) areto.
Unu el la bonegaj avantaĝoj de Influx ankaŭ inkluzivus tre oportunan kaj riĉan API por datumdemandoj, kiun ni uzis tre aktive.
Malavantaĝoj - $$$ aŭ skalo?
La TICK-stako havas nur unu malavantaĝon, kiun ni malkovris - ĝi multekosta. Eĉ pli.
Kion havas la pagita versio, ke la senpaga versio ne havas?
Kiom ni povis kompreni, la nura diferenco inter la pagita versio de la TICK-stako kaj la senpaga estas la skalaj kapabloj.
Nome, vi povas kreskigi areton kun Alta havebleco nur en .
Se vi volas plenrajtan HA, vi aŭ devas pagi aŭ uzi kelkajn lambastonojn. Estas kelkaj komunumaj solvoj - ekzemple aspektas kiel kompetenta solvo, sed estas skribite, ke ĝi ne taŭgas por produktado, same kiel
- simpla solvo kun datumpumpado per NATS (ĝi ankaŭ devos esti skaligita, sed tio povas esti solvita).
Estas domaĝe, sed ambaŭ ŝajnas forlasitaj - ne estas freŝaj komitaĵoj, mi supozas, ke la afero estas la baldaŭ atendata eldono de la nova versio de Influx 2.0, en kiu multaj aferoj estos malsamaj (ne ekzistas informoj pri grimpi en ĝi ankoraŭ).
Oficiale ekzistas senpaga versio - fakte, ĉi tio estas primitiva HA, sed nur per ekvilibro,
ĉar ĉiuj datumoj estos skribitaj al ĉiuj InfluxDB-instancoj malantaŭ la ŝarĝbalancilo.
Li havas kelkajn kiel eblaj problemoj kun anstataŭigaj punktoj kaj la bezono krei bazojn por metrikoj anticipe
(kio okazas aŭtomate dum normala laboro kun InfluxDB).
Cetere , ĉi tio signifas plian superkoston por duplikataj metrikoj (kaj prilaborado kaj stokado), kiujn vi eble ne bezonas, sed ne ekzistas maniero apartigi ilin.
Viktoria Metriko?
Kiel rezulto, malgraŭ la fakto, ke ni estis tute kontentaj pri la TICK-stako en ĉio krom pagita grimpado, ni decidis vidi ĉu ekzistas senpagaj solvoj, kiuj povus anstataŭigi la datumbazon de InfluxDB, lasante la ceterajn T_CK-komponentojn.
Estas multaj temp-seriaj datumbazoj, sed la plej promesplena estas Victoria Metrics, ĝi havas kelkajn avantaĝojn:
- Rapida kaj facila, almenaŭ laŭ la rezultoj
- Ekzistas cluster-versio, pri kiu estas eĉ bonaj recenzoj nun
- Ŝi povas fragmentiĝi
- Subtenas InfluxDB-protokolon
Ni ne intencis konstrui tute laŭmendan stakon bazitan sur Viktorio kaj la ĉefa espero estis, ke ni povus uzi ĝin kiel anstataŭan anstataŭaĵon por InfluxDB.
Bedaŭrinde, tio ne eblas, malgraŭ la fakto, ke la protokolo InfluxDB estas subtenata, ĝi nur funkcias por registri metrikojn - nur la Prometheus API estas disponebla "ekstere", kio signifas, ke ne eblos agordi Chronograf sur ĝi.
Krome, nur nombraj valoroj estas subtenataj por metrikoj (ni uzis kordvalorojn por kutimaj metrikoj - pli pri tio en la sekcio ).
Evidente, pro la sama kialo, la VM ne povas stoki protokolojn kiel Influx faras.
Ankaŭ oni devas rimarki, ke ĉe la serĉado de la optimuma solvo, Victoria Metrics ankoraŭ ne estis tiel populara, la dokumentado estis multe pli malgranda kaj la funkcieco estis pli malforta.
(Mi ne memoras detalan priskribon de la cluster-versio kaj sharding).
Baza elekto
Kiel rezulto, estis decidite ke por la piloto ni ankoraŭ limigos nin al ununura InfluxDB-nodo.
Estis pluraj ĉefaj kialoj por ĉi tiu elekto:
- Ni tre ŝatis la tutan funkcion de la TICK-stako
- Ni jam sukcesis deploji ĝin kaj ĝi bonege funkciis
- La limdatoj finiĝis kaj ne restis multe da tempo por provi aliajn eblojn.
- Ni ne atendis tian pezan ŝarĝon
Ni ne havis multajn skoterojn por la unua fazo de la piloto, kaj testado dum evoluo ne malkaŝis ajnajn rendimentajn problemojn.
Tial ni decidis, ke por ĉi tiu projekto unu Influx-nodo sufiĉus por ni sen neceso de skalo (vidu konkludojn ĉe la fino).
Ni decidis pri la stako kaj bazo - nun pri la ceteraj komponantoj de la TICK-stako.
Kapacitor
Kapacitor estas parto de la TICK-stako, servo kiu povas monitori metrikojn enirantajn la datumbazon en reala tempo kaj plenumi diversajn agojn bazitajn sur reguloj.
Ĝenerale, ĝi estas poziciigita kiel ilo por ebla anomalio-spurado kaj maŝinlernado (mi ne certas, ke ĉi tiuj funkcioj estas postulataj), sed la plej populara kazo de ĝia uzo estas pli kutima - atentigo.
Tiel ni uzis ĝin por sciigoj. Ni starigis Slack-atentigojn kiam aparta skotero malkonektas, kaj la sama estis farita por inteligentaj ŝargiloj kaj gravaj infrastrukturaj komponantoj.
Ĉi tio ebligis rapide respondi al problemoj, kaj ankaŭ ricevi sciigojn, ke ĉio normaliĝis.
Simpla ekzemplo: plia baterio por funkciigi nian "skatolon" paneis aŭ ial elĉerpiĝis; simple instalante novan, ni devus ricevi sciigon, ke la funkcieco de la skotero estas restarigita.
En Enfluo 2.0 Kapacitor iĝis parto de DB
Kronograf
Mi vidis multajn malsamajn UI-solvojn por monitorado, sed mi povas diri, ke laŭ funkcieco kaj UX, nenio komparas al Chronograf.
Ni komencis uzi la TICK-stakon, sufiĉe strange, kun Grafan kiel retinterfaco.
Mi ne priskribos ĝian funkciecon; ĉiuj konas ĝiajn larĝajn eblecojn por agordi ion ajn.
Tamen, Grafana daŭre estas tute universala instrumento, dum Chronograf estas plejparte dizajnita por uzo kun Influx.
Kaj kompreneble, danke al ĉi tio, Chronograf povas pagi multe pli lertan aŭ oportunan funkciecon.
Eble la ĉefa oportuno labori kun Chronograf estas, ke vi povas vidi la internojn de via InfluxDB per Esploro.
Ŝajnus, ke Grafana havas preskaŭ identan funkciecon, sed fakte, instali panelon en Chronograf povas esti farita per kelkaj musklakoj (samtempe rigardante la tiean videbligon), dum en Grafana vi ankoraŭ pli aŭ malpli frue havos. redakti la JSON-agordon (kompreneble Chronograf permesas alŝuti viajn mane agorditajn daŝaojn kaj redakti ilin kiel JSON se necese - sed mi neniam devis tuŝi ilin post kreado de ili sur la UI).
Kibana havas multe pli riĉajn kapablojn por krei instrumentpanelojn kaj kontrolojn por ili, sed la UX por tiaj operacioj estas tre kompleksa.
Necesos iom da bona kompreno por krei oportunan panelon. Kaj kvankam la funkcieco de Chronograf paneloj estas malpli, fari kaj personecigi ilin estas multe pli simpla.
La paneloj mem, krom la agrabla vida stilo, fakte ne diferencas de la paneloj en Grafana aŭ Kibana:
Jen kiel aspektas la demanda fenestro:
Gravas noti, interalie, ke sciante la specojn de kampoj en la datumbazo InfluxDB, la kronografo mem foje povas aŭtomate helpi vin skribi Demandon aŭ elekti la ĝustan agregan funkcion kiel signifas.
Kaj kompreneble Chronograf estas kiel eble plej oportuna por vidi protokolojn. Ĝi aspektas jene:
Defaŭlte, Influx-protokoloj estas adaptitaj por uzi syslog kaj tial ili havas gravan parametron - severecon.
La grafikaĵo ĉe la supro estas speciale utila; sur ĝi vi povas vidi la erarojn kiuj okazas kaj la koloro tuj klare montras ĉu la severeco estas pli alta.
Kelkfoje ni kaptis gravajn cimojn tiamaniere, rigardante la protokolojn dum la lasta semajno kaj vidante ruĝan pikilon.
Kompreneble, ideale estus agordi atentigojn por tiaj eraroj, ĉar ni jam havis ĉion por ĉi tio.
Ni eĉ ŝaltis ĉi tion dum iom da tempo, sed dum la procezo de preparado de la piloto montriĝis, ke ni ricevis sufiĉe da eraroj (inkluzive de sistemaj kiel la nehavebleco de la LTE-reto), kiuj ankaŭ "spamis" la Slack-kanalon. multe, sen kaŭzi problemojn.granda profito.
La ĝusta solvo estus trakti la plej multajn el ĉi tiuj specoj de eraroj, ĝustigi la severecon por ili, kaj nur tiam ebligi atentigon.
Tiel, nur novaj aŭ gravaj eraroj estus afiŝitaj al Slack. Simple ne estis sufiĉe da tempo por tia aranĝo pro la mallarĝaj templimoj.
Aŭtentigo
Menciindas ankaŭ, ke Chronograf subtenas OAuth kaj OIDC kiel aŭtentikigon.
Ĉi tio estas tre oportuna, ĉar ĝi ebligas al vi facile kunligi ĝin al via servilo kaj krei plenan SSO.
En nia kazo, la servilo estis — ĝi estis uzata por konekti al monitorado, sed la sama servilo ankaŭ estis uzata por aŭtentikigi skoterojn kaj petojn al la malantaŭa fino.
"Administranto"
La lasta komponanto, kiun mi priskribos, estas nia memskribita "administra panelo" en Vue.
Esence ĝi estas nur memstara servo, kiu montras skoterinformojn de niaj propraj datumbazoj, mikroservoj kaj metrikaj datumoj de InfluxDB samtempe.
Krome, multaj administraj funkcioj estis movitaj tien, kiel kriza rekomenco aŭ malproksime malfermi seruron por la subtena teamo.
Estis ankaŭ mapoj. Mi jam menciis, ke ni komencis per Grafana anstataŭ Chronograf - ĉar por Grafana mapoj estas disponeblaj en formo de kromaĵoj, sur kiuj ni povus vidi la koordinatojn de skoteroj. Bedaŭrinde, la kapabloj de mapfenestraĵoj por Grafana estas tre limigitaj, kaj kiel rezulto, estis multe pli facile verki vian propran TTT-aplikaĵon kun mapoj en kelkaj tagoj, por ne nur vidi la koordinatojn nuntempe, sed ankaŭ montri. la itinero prenita de la skotero, povi filtri la datumojn sur mapo, ktp (ĉiu tiu funkcio, kiun ni ne povis agordi en simpla panelo).
Unu el la jam menciitaj avantaĝoj de Influx estas la kapablo facile krei viajn proprajn metrikojn.
Ĉi tio permesas ĝin esti uzata por grandega gamo da scenaroj.
Ni provis registri ĉiujn utilajn informojn tie: ŝargo de la kuirilaro, stato de ŝlosilo, rendimento de sensiloj, bluetooth, GPS kaj multaj aliaj sankontroloj.
Ni montris ĉion ĉi sur la administra panelo.
Kompreneble, la plej grava kriterio por ni estis la funkcianta kondiĉo de la skotero - fakte, Influx kontrolas tion mem kaj montras ĝin per "verdaj lumoj" en la sekcio Nodoj.
Ĉi tio estas farita per la funkcio — ni uzis ĝin por kompreni la agadon de nia skatolo kaj sendi tiujn samajn atentigojn al Slack.
Cetere, ni nomis la skoterojn laŭ la nomoj de roluloj de La Simpsonoj - estis tiel oportune distingi ilin unu de la alia.
Kaj ĝenerale estis pli amuza ĉi tiu maniero. Frazoj kiel "Uloj, Smithers mortis!" estis konstante aŭditaj.
String-metriko
Gravas, ke InfluxDB ebligas al vi stoki ne nur nombrajn valorojn, kiel estas la kazo de Victoria Metrics.
Ŝajnus, ke ĉi tio ne tiom gravas - ja krom protokoloj, iuj ajn metrikoj povas esti konservitaj en formo de nombroj (nur aldonu mapadon por konataj ŝtatoj - speco de enum)?
En nia kazo, ekzistis almenaŭ unu scenaro kie kordaj metrikoj estis tre utilaj.
Okazis, ke la provizanto de niaj "inteligentaj ŝargiloj" estis tria, ni havis neniun kontrolon pri la disvolva procezo kaj la informoj, kiujn ĉi tiuj ŝargiloj povus provizi.
Kiel rezulto, la ŝarĝa API estis malproksima de ideala, sed la ĉefa problemo estis, ke ni ne ĉiam povis kompreni ilian staton.
Ĉi tie Influx venis al la savo. Ni simple skribis la kordstatuson, kiu venis al ni en la kampon de datumbazo InfluxDB sen ŝanĝoj.
Dum iom da tempo, nur valoroj kiel "rete" kaj "senrete" alvenis tie, surbaze de kiuj informoj estis montritaj en nia administra panelo, kaj sciigoj estis senditaj al Slack. Tamen, iam, valoroj kiel "malkonektita" ankaŭ komencis aperi tie.
Kiel montriĝis poste, ĉi tiu statuso estis sendita unufoje post kiam la konekto estis perdita, se la ŝargilo ne povis establi konekton kun la servilo post certa nombro da provoj.
Tiel, se ni nur uzus fiksan aron da valoroj, ni eble ne vidos ĉi tiujn ŝanĝojn en la firmvaro en la ĝusta tempo.
Kaj ĝenerale, kordaj metrikoj disponigas multe pli da eblecoj por uzo; vi povas registri preskaŭ ajnan informon en ili. Kvankam, kompreneble, vi ankaŭ devas uzi ĉi tiun ilon zorge.
Krom la kutimaj metrikoj, ni ankaŭ registris informojn pri GPS-lokaj informoj en InfluxDB. Ĉi tio estis nekredeble utila por kontroli la lokon de skoteroj en nia administra panelo.
Fakte, ni ĉiam sciis kie kaj kiu skotero estas en la momento, kiun ni bezonis.
Ĉi tio estis tre utila al ni, kiam ni serĉis skoteron (vidu konkludojn ĉe la fino).
Monitorado de infrastrukturo
Krom la skoteroj mem, ni ankaŭ bezonis kontroli nian tutan (sufiĉe ampleksan) infrastrukturon.
Tre ĝenerala arkitekturo aspektis kiel ĉi tio:
Se ni reliefigas puran monitoran stakon, ĝi aspektas jene:
Kion ni ŝatus kontroli en la nubo estas:
- Datumbazoj
- ŝlosilmantelo
- Mikroservoj
Ĉar ĉiuj niaj nubaj servoj situas en Kubernetes, estus bone kolekti informojn pri ĝia stato.
Feliĉe, Telegraf el la skatolo povas kolekti grandegan nombron da metrikoj pri la stato de la Kubernetes-areo, kaj Chronograf tuj ofertas belajn panelojn por ĉi tio.
Ni ĉefe monitoris la agadon de la podoj kaj memorkonsumon. En kazo de falo, atentigoj en Slack.
Estas du manieroj spuri podojn en Kubernetes: DaemonSet kaj Sidecar.
Ambaŭ metodoj estas priskribitaj detale .
Ni uzis Telegraf Sidecar kaj, krom metrikoj, kolektis pod protokolojn.
En nia kazo, ni devis ruzi kun la ŝtipoj. Malgraŭ la fakto, ke Telegraf povas tiri protokolojn de la Docker API, ni volis havi unuforman kolekton de protokoloj kun niaj finaj aparatoj kaj agordita syslog por ujoj por ĉi tio. Eble ĉi tiu solvo ne estis bela, sed ne estis plendoj pri ĝia laboro kaj la protokoloj estis bone montritaj en Chronograf.
Monitora monitorado???
Fine aperis la malnova demando pri monitorado de monitoraj sistemoj, sed feliĉe, aŭ bedaŭrinde, ni simple ne havis sufiĉe da tempo por tio.
Kvankam Telegraf povas facile sendi siajn proprajn metrikojn aŭ kolekti metrikojn de la datumbazo InfluxDB por sendi aŭ al la sama Enfluo aŭ aliloke.
trovoj
Kiajn konkludojn ni eltiris el la rezultoj de la piloto?
Kiel vi povas fari monitoradon?
Antaŭ ĉio, la TICK-stako plene plenumis niajn atendojn kaj donis al ni eĉ pli da ŝancoj ol tio, kion ni komence atendis.
Ĉiuj funkcioj, kiujn ni bezonis, ĉeestis. Ĉio, kion ni faris per ĝi, funkciis sen problemoj.
Produkteco
La ĉefa problemo kun la TICK-stako en la senpaga versio estas la manko de skalaj kapabloj. Ĉi tio ne estis problemo por ni.
Ni ne kolektis precizajn ŝarĝajn datumojn/ciferojn, sed ni kolektis datumojn de ĉirkaŭ 30 skoteroj samtempe.
Ĉiu el ili kolektis pli ol tri dekduojn da metrikoj. Samtempe, ŝtipoj de la aparatoj estis kolektitaj. Kolekto kaj sendo de datumoj okazis ĉiujn 10 sekundojn.
Gravas noti, ke post semajno kaj duono de la piloto, kiam la plej granda parto de la "infanaj problemoj" estis korektita kaj la plej gravaj problemoj jam estis solvitaj, ni devis redukti la oftecon de sendo de datumoj al la servilo al 30 sekundoj. Ĉi tio fariĝis necesa ĉar la trafiko sur niaj LTE-SIM-kartoj komencis rapide malaperi.
La plej granda parto de la trafiko estis konsumita de ŝtipoj; la metrikoj mem, eĉ kun 10-sekunda intervalo, preskaŭ ne malŝparis ĝin.
Kiel rezulto, post iom da tempo ni tute malŝaltis la kolekton de protokoloj sur aparatoj, ĉar specifaj problemoj jam estis evidentaj eĉ sen konstanta kolekto.
En iuj kazoj, se vidi la protokolojn ankoraŭ estis necesaj, ni simple konektiĝis per WireGuard per VPN.
Mi ankaŭ aldonos, ke ĉiu aparta medio estis apartigita unu de la alia, kaj la supre priskribita ŝarĝo estis grava nur por la produkta medio.
En la evolumedio, ni levis apartan InfluxDB-instancon, kiu daŭre kolektis datumojn ĉiujn 10 sekundojn kaj ni ne renkontis problemojn pri rendimento.
TICK - ideala por malgrandaj ĝis mezaj projektoj
Surbaze de ĉi tiu informo, mi konkludus, ke la TICK-stako estas ideala por relative malgrandaj projektoj aŭ projektoj, kiuj certe ne atendas iun HighLoad.
Se vi ne havas milojn da podoj aŭ centojn da maŝinoj, eĉ unu InfluxDB-instanco bone manipulos la ŝarĝon.
En iuj kazoj, vi povas esti kontenta pri Influx Relay kiel primitiva Alta Havebleca solvo.
Kaj, kompreneble, neniu malhelpas vin starigi "vertikalan" skaladon kaj simple atribui malsamajn servilojn por malsamaj specoj de metrikoj.
Se vi ne certas pri la atendata ŝarĝo de la monitoraj servoj, aŭ vi estas garantiita havi/havos tre "pezan" arkitekturon, mi ne rekomendus uzi la senpagan version de la TICK-stako.
Kompreneble, simpla solvo estus aĉeti — sed ĉi tie mi ne povas iel komenti, ĉar mi mem ne konas la subtilaĵojn. Krom tio, ke ĝi estas tre multekosta kaj certe ne taŭgas por malgrandaj kompanioj.
En ĉi tiu kazo, hodiaŭ, mi rekomendus rigardi al kolektado de metrikoj per Victoria Metrics kaj protokoloj uzante Loki.
Vere, mi denove faros rezervon, ke Loki/Grafana estas multe malpli oportunaj (pro ilia pli granda ĉiuflankeco) ol la preta TICK, sed ili estas senpagaj.
gravaj: ĉiuj informoj ĉi tie priskribitaj rilatas por versio Influx 1.8, nuntempe Influx 2.0 estas eldonota.
Kvankam mi ne havis ŝancon provi ĝin en batalkondiĉoj kaj estas malfacile tiri konkludojn pri plibonigoj, la interfaco certe fariĝis eĉ pli bona, la arkitekturo simpliĝis (sen kapacitor kaj chronograf),
aperis ŝablonoj ("mortiga trajto" - ). Sed, bedaŭrinde, nuntempe, versio 2 ne havas la ŝlosilan aferon, por kiu ni elektis la unuan version - ne ekzistas protokolo-kolekto.
Ĉi tiu funkcio aperos ankaŭ en Influx 2.0, sed ni ne povis trovi ajnajn limdatojn, eĉ proksimumajn.
Kiel ne fari IoT-platformojn (nun)
Fine, lanĉinte la piloton, ni mem kunvenis nian propran plenrajtan IoT-stakon, sen alternativo taŭga laŭ niaj normoj.
Tamen, lastatempe ĝi estas disponebla en Beta-versio — estas domaĝe, ke ŝi ne estis tie kiam ni komencis fari la projekton.
Ni estas tute kontentaj pri la fina rezulto kaj la platformo bazita sur Ansible + TICK + WireGuard, kiujn ni kunvenis mem. Sed hodiaŭ, mi rekomendus rigardi pli detale Balena antaŭ ol provi mem konstrui vian propran IoT-platformon.
Ĉar finfine ĝi povas fari la plej grandan parton de tio, kion ni faris, kaj OpenBalena estas senpaga kaj malferma fonto.
Ĝi jam scias kiel ne nur sendi ĝisdatigojn, sed ankaŭ VPN jam estas enkonstruita kaj adaptita por uzo en IoT-medio.
Kaj ĵus, ili eĉ publikigis sian , kiu facile ligiĝas al ilia ekosistemo.
He, kio pri la mankanta skotero?
Do la skotero, "Ralph", malaperis sen spuro.
Ni tuj kuris por rigardi la mapon en nia "administra panelo", kun GPS-metrikaj datumoj de InfluxDB.
Danke al monitoraj datumoj, ni facile determinis, ke la skotero forlasis la parkejon ĉirkaŭ 21:00 lastan tagon, veturis ĉirkaŭ duonhoron al iu areo kaj estis parkumita ĝis la 5-a matene apud iu germana domo.
Post la 5-a a.m., neniuj monitoraj datumoj estis ricevitaj - tio signifis aŭ la kroma baterio estis tute malŝarĝita, aŭ la atakanto finfine eltrovis kiel forigi la inteligentan aparataron de la skotero.
Malgraŭ tio, la polico daŭre estis vokita al la adreso kie la skotero estis situanta. La skotero ne estis tie.
Tamen, la posedanto de la domo ankaŭ estis surprizita pro tio, ĉar li efektive veturis ĉi tiun skotero hejmen de la oficejo hieraŭ nokte.
Kiel montriĝis, unu el la subtenaj dungitoj alvenis frue matene kaj prenis la skoteron, vidante, ke ĝia kroma baterio estas tute malŝarĝita kaj portis ĝin (piede) al la parkejo. Kaj la aldona kuirilaro malsukcesis pro malsekeco.
Ni ŝtelis la skoteron de ni mem. Cetere, mi ne scias kiel kaj kiu tiam solvis la problemon kun la polica kazo, sed la monitorado funkciis perfekte...
fonto: www.habr.com