'n Jaar gelede het ons 'n loodsweergawe van 'n promosieprojek vir .
Aanvanklik is die projek Road-To-Barcelona genoem, later het dit Road-To-Berlin geword (dus R2B in die skermkiekies), en uiteindelik is dit xRide genoem.
Die hoofgedagte van die projek was die volgende: in plaas daarvan om 'n gesentraliseerde motor- of bromponie-huurdiens te hê (ons praat van bromponies of elektriese motorfietse, nie skopbromponies/bromponies nie), wou ons 'n platform vir gedesentraliseerde huur maak. Oor die moeilikhede wat ons teëgekom het .
Aanvanklik het die projek op motors gefokus, maar weens spertye, uiters lang kommunikasie met vervaardigers en 'n groot aantal veiligheidsbeperkings, is elektriese bromponies vir die loods gekies.
Die gebruiker het 'n iOS- of Android-toepassing op die foon geïnstalleer, die bromponie genader waarvan hy hou, waarna die foon en die bromponie 'n eweknie-verbinding tot stand gebring het, ETH is uitgeruil en die gebruiker kon die rit begin deur die bromponie aan te skakel via die foon. Aan die einde van die reis was dit ook moontlik om vir die reis met Ethereum uit die gebruiker se beursie op die telefoon te betaal.
Benewens bromponies het die gebruiker “slim laaiers” in die toepassing gesien, deur te besoek wat die gebruiker self die huidige battery kon verander as dit laag was.
Dit is oor die algemeen hoe ons vlieënier gelyk het, wat in September verlede jaar in twee Duitse stede van stapel gestuur is: Bonn en Berlyn.
En toe, eendag, vroegoggend in Bonn, word ons ondersteuningspan (wat op die terrein geleë is om bromponies in werkende toestand te hou) gewaarsku: een van die bromponies het spoorloos verdwyn.
Hoe om dit te vind en terug te gee?
In hierdie artikel sal ek hieroor praat, maar eers - oor hoe ons ons eie IoT-platform gebou het en hoe ons dit gemonitor het.
Wat en hoekom om te monitor: bromponies, infrastruktuur, laaistasies?
So, wat wou ons in ons projek monitor?
Eerstens, dit is die bromponies self - elektriese bromponies self is redelik duur, jy kan nie so 'n projek loods sonder om voldoende voorbereid te wees nie; indien moontlik, wil jy soveel inligting as moontlik oor die bromponies insamel: oor hul ligging, laaivlak , ens.
Daarbenewens wil ek graag die stand van ons eie IT-infrastruktuur monitor – databasisse, dienste en alles wat hulle nodig het om te werk. Dit was ook nodig om die status van die "slim laaiers" te monitor, ingeval hulle breek of vol batterye raak.
Scooters
Wat was ons bromponies en wat wou ons daarvan weet?
Die eerste en belangrikste ding is GPS-koördinate, want danksy hulle kan ons verstaan waar hulle is en waarheen hulle beweeg.
Volgende is die batterylading, waardeur ons kan bepaal dat die laai van die bromponies tot 'n einde kom en 'n versapper stuur of ten minste die gebruiker waarsku.
Dit is natuurlik ook nodig om na te gaan wat met ons hardeware-komponente gebeur:
- werk bluetooth?
- werk die GPS-module self?
- Ons het ook 'n probleem gehad met die feit dat die GPS verkeerde koördinate kon stuur en vashaak, en dit kon slegs bepaal word deur bykomende kontrole op die bromponie,
en stel ondersteuning so gou moontlik in kennis om die probleem op te los
- Ons het ook 'n probleem gehad met die feit dat die GPS verkeerde koördinate kon stuur en vashaak, en dit kon slegs bepaal word deur bykomende kontrole op die bromponie,
En laastens: kontroles van die sagteware, begin met die bedryfstelsel en verwerker, netwerk- en skyflading, wat eindig met kontroles van ons eie modules wat meer spesifiek vir ons is (, ).
hardeware
Wat was ons "yster" deel?
Met inagneming van die kortste moontlike tydraamwerk en die behoefte aan vinnige prototipering, het ons die maklikste opsie vir implementering en keuse van komponente gekies - Raspberry Pi.
Benewens die Rpi self, het ons 'n pasgemaakte bord gehad (wat ons self ontwikkel en van China af bestel het om die monteringsproses van die finale oplossing te bespoedig) en 'n stel komponente - 'n aflos (om die bromponie aan/af te skakel), 'n batterylaaileser, 'n modem, antennas. Dit alles is kompak verpak in 'n spesiale "xRide-boks".
Daar moet ook op gelet word dat die hele boks aangedryf is deur 'n bykomende kragbank, wat op sy beurt deur die hoofbattery van die bromponie aangedryf is.
Dit het dit moontlik gemaak om monitering te gebruik en die bromponie aan te skakel selfs na die einde van die rit, aangesien die hoofbattery onmiddellik afgeskakel is nadat die aansittersleutel na die "af" posisie gedraai is.
Docker? Gewone Linux? en ontplooiing
Kom ons keer terug na monitering, so Framboos - wat het ons?
Een van die eerste dinge wat ons wou gebruik om die proses van ontplooiing, opdatering en aflewering van komponente aan fisiese toestelle te bespoedig, was Docker.
Ongelukkig het dit vinnig duidelik geword dat Docker op RPi, hoewel dit werk, baie oorhoofse koste het, veral in terme van kragverbruik.
Die verskil met behulp van die "inheemse" bedryfstelsel, hoewel nie so sterk nie, was steeds voldoende vir ons om versigtig te wees vir die moontlikheid om te vinnig beheer te verloor.
Die tweede rede was een van ons vennootbiblioteke op Node.js (sic!) - die enigste komponent van die stelsel wat nie in Go/C/C++ geskryf is nie.
Die skrywers van die biblioteek het nie tyd gehad om 'n werkende weergawe in enige van die "moedertaal" te verskaf nie.
Nie net is die nodus self nie die mees elegante oplossing vir laeprestasie-toestelle nie, maar die biblioteek self was baie hulpbronhonger.
Ons het besef dat, selfs al sou ons wou, die gebruik van Docker vir ons te veel van 'n bokoste sou wees. Die keuse is gemaak ten gunste van die inheemse OS en werk direk daaronder.
OS
Gevolglik het ons weer die eenvoudigste opsie as die bedryfstelsel gekies en Raspbian (Debian-bou vir Pi) gebruik.
Ons skryf al ons sagteware in Go, so ons het ook die hoof hardeware agent module in ons stelsel in Go geskryf.
Dit is hy wat verantwoordelik is om met GPS, Bluetooth te werk, die lading te lees, die bromponie aan te skakel, ens.
Ontplooi
Die vraag het dadelik ontstaan oor die behoefte om 'n meganisme te implementeer vir die lewering van opdaterings aan toestelle (OTA) - beide opdaterings aan ons agent/toepassing self, en opdaterings aan die bedryfstelsel/firmware self (aangesien nuwe weergawes van die agent opdaterings aan die kern kan vereis of stelselkomponente, biblioteke, ens.).
Na 'n taamlike lang ontleding van die mark, het dit geblyk dat daar heelwat oplossings is om opdaterings aan die toestel te lewer.
Van relatief eenvoudige, meestal opdaterings-/dubbellaai-georiënteerde nutsprogramme soos swupd/SWUpdate/OSTree tot volwaardige platforms soos Mender en Balena.
Eerstens het ons besluit dat ons in end-to-end oplossings belangstel, so die keuse het dadelik op platforms geval.
Die baie is uitgesluit weens die feit dat dit eintlik dieselfde Docker binne sy balenaEngine gebruik.
Maar ek merk op dat ten spyte hiervan, ons uiteindelik hul produk voortdurend gebruik het vir flitsfirmware op SD-kaarte - 'n eenvoudige en uiters gerieflike hulpmiddel hiervoor.
Daarom het die keuse op die ou end geval . Mender is 'n volledige platform vir die samestelling, aflewering en installering van firmware.
Oor die algemeen lyk die platform goed, maar dit het ons ongeveer 'n week en 'n half geneem net om die korrekte weergawe van ons firmware te bou met behulp van die mender-bouer.
En hoe meer ons onsself verdiep het in die ingewikkeldhede van die gebruik daarvan, hoe meer het dit duidelik geword dat ons baie meer tyd sou benodig as wat ons gehad het om dit ten volle te ontplooi.
Helaas, ons streng spertye het beteken dat ons gedwing was om die gebruik van Mender te laat vaar en 'n selfs eenvoudiger een te kies.
Ansible
Die eenvoudigste oplossing in ons situasie was om Ansible te gebruik. 'n Paar speelboeke was genoeg om te begin.
Hul essensie was dat ons eenvoudig vanaf die gasheer (CI-bediener) via ssh na ons rasberries gekoppel het en opdaterings aan hulle versprei het.
Heel aan die begin was alles eenvoudig - jy moes op dieselfde netwerk met die toestelle wees, skink was via Wi-Fi gedoen.
In die kantoor was daar bloot 'n dosyn toetsframbose wat aan dieselfde netwerk gekoppel is, elke toestel het 'n statiese IP-adres gehad wat ook in Ansible Inventory gespesifiseer is.
Dit was Ansible wat ons moniteringsagent aan die eindtoestelle gelewer het
3G / LTE
Ongelukkig kon hierdie gebruiksgeval vir Ansible net in ontwikkelingsmodus werk voordat ons werklike bromponies gehad het.
Want bromponies, soos jy verstaan, sit nie gekoppel aan een Wi-Fi-roeteerder nie en wag voortdurend vir opdaterings oor die netwerk.
In werklikheid kan bromponies glad nie enige verbinding hê behalwe mobiele 3G/LTE nie (en selfs dan nie heeltyd nie).
Dit plaas onmiddellik baie probleme en beperkings, soos lae verbindingspoed en onstabiele kommunikasie.
Maar die belangrikste ding is dat ons in 'n 3G/LTE-netwerk nie bloot kan staatmaak op 'n statiese IP wat aan die netwerk toegewys is nie.
Dit word gedeeltelik opgelos deur sommige SIM-kaartverskaffers; daar is selfs spesiale SIM-kaarte wat ontwerp is vir IoT-toestelle met statiese IP-adresse. Maar ons het nie toegang tot sulke SIM-kaarte gehad nie en kon nie IP-adresse gebruik nie.
Natuurlik was daar idees om 'n soort registrasie van IP-adresse, oftewel diensontdekking iewers soos Consul, te doen, maar ons moes sulke idees laat vaar, aangesien die IP-adres in ons toetse te gereeld kon verander, wat tot groot onstabiliteit gelei het.
Om hierdie rede sal die mees gerieflike gebruik vir die lewering van statistieke nie die gebruik van die trekmodel wees nie, waar ons na toestelle gaan vir die nodige statistieke, maar stoot en statistieke vanaf die toestel direk na die bediener lewer
Skynprivaatnetwerk
As 'n oplossing vir hierdie probleem het ons VPN gekies - spesifiek .
Kliënte (bromponies) het aan die begin van die stelsel aan die VPN-bediener gekoppel en kon aan hulle koppel. Hierdie tonnel is gebruik om opdaterings te lewer.
In teorie kan dieselfde tonnel vir monitering gebruik word, maar so 'n verbinding was meer ingewikkeld en minder betroubaar as eenvoudige druk.
Wolk hulpbronne
Laastens is dit nodig om ons wolkdienste en databasisse te monitor, aangesien ons Kubernetes daarvoor gebruik, ideaal sodat die implementering van monitering in die groepering so eenvoudig as moontlik is. Ideaal gesproke, gebruik , aangesien ons dit in die meeste gevalle vir ontplooiing gebruik. En natuurlik, om die wolk te monitor, moet jy dieselfde oplossings gebruik as vir die bromponies self.
Gegee
Sjoe, dit lyk asof ons die beskrywing uitgesorteer het, kom ons maak 'n lys van wat ons nodig gehad het op die ou end:
- 'n Vinnige oplossing, aangesien monitering reeds tydens die ontwikkelingsproses nodig is
- Volume/hoeveelheid – baie maatstawwe benodig
- Logboekversameling word vereis
- Betroubaarheid – data is van kritieke belang om sukses te loods
- Jy kan nie die trekmodel gebruik nie – jy het stoot nodig
- Ons benodig verenigde monitering van nie net hardeware nie, maar ook wolk
Die finale prent het iets soos hierdie gelyk
Stapel seleksie
Ons het dus gekonfronteer met die vraag om 'n moniteringsstapel te kies.
Eerstens was ons op soek na die mees volledige alles-in-een-oplossing wat gelyktydig aan al ons vereistes sou voldoen, maar terselfdertyd buigsaam genoeg sou wees om die gebruik daarvan by ons behoeftes aan te pas. Tog het ons baie beperkings opgelê deur hardeware, argitektuur en sperdatums.
Daar is 'n groot verskeidenheid moniteringsoplossings, wat begin met volwaardige stelsels soos , of en eindig met klaargemaakte oplossings vir Vlootbestuur.
Aanvanklik het laasgenoemde na 'n ideale oplossing vir ons gelyk, maar sommige het nie volle monitering gehad nie, ander het erg beperkte vermoëns van die gratis weergawes gehad, en ander het eenvoudig nie ons "begeertes" gedek nie of was nie buigsaam genoeg om by ons scenario's te pas nie. Sommige is eenvoudig verouderd.
Nadat ons 'n aantal soortgelyke oplossings ontleed het, het ons vinnig tot die gevolgtrekking gekom dat dit makliker en vinniger sou wees om self 'n soortgelyke stapel saam te stel. Ja, dit sal 'n bietjie meer ingewikkeld wees as om 'n heeltemal klaargemaakte vlootbestuurplatform te ontplooi, maar ons hoef nie kompromieë te maak nie.
Byna seker, in al die groot oorvloed van oplossings, is daar reeds 'n klaargemaakte een wat heeltemal by ons sal pas, maar in ons geval was dit baie vinniger om 'n sekere stapel op ons eie bymekaar te maak en dit "vir onsself" aan te pas eerder as klaargemaakte produkte te toets.
Met dit alles het ons nie daarna gestreef om self 'n hele moniteringsplatform saam te stel nie, maar was op soek na die mees funksionele "gereedgemaakte" stapels, net met die vermoë om dit buigsaam te konfigureer.
(B)ELK?
Die eerste oplossing wat eintlik oorweeg is, was die bekende ELK-stapel.
Eintlik moet dit BELK genoem word, want dit begin alles met Beats -
Natuurlik is ELK een van die bekendste en kragtigste oplossings op die gebied van monitering, en nog meer in die versameling en verwerking van logs.
Ons was van plan dat ELK gebruik sou word om logs te versamel en sowel as langtermynberging van metrieke wat van Prometheus verkry is.
Vir visualisering kan jy Grafan gebruik.
Trouens, die nuwe ELK-stapel kan statistieke onafhanklik versamel (metriekslag), en Kibana kan dit ook vertoon.
Maar steeds, ELK het aanvanklik uit logs gegroei en tot dusver het die funksionaliteit van die metrieke 'n aantal ernstige nadele:
- Aansienlik stadiger as Prometheus
- Integreer op baie minder plekke as Prometheus
- Dit is moeilik om waarskuwings vir hulle op te stel
- Metrieke neem baie ruimte op
- Die opstel van dashboards met maatstawwe in Kiban is baie meer ingewikkeld as in Grafan
Oor die algemeen is die metrieke in ELK swaar en nog nie so gerieflik soos in ander oplossings nie, waarvan daar nou veel meer as net Prometheus is: TSDB, Victoria Metrics, Cortex, ens., ens. Natuurlik sou ek baie graag dadelik 'n volwaardige alles-in-een-oplossing wou hê, maar in die geval van metrieke klop was daar te veel kompromieë.
En die ELK-stapel self het 'n aantal moeilike oomblikke:
- Dit is swaar, soms selfs baie swaar as jy 'n redelike groot hoeveelheid data insamel
- Jy moet "weet hoe om dit te kook" - jy moet dit skaal, maar dit is nie triviaal om te doen nie
- Gratis weergawe gestroop - die gratis weergawe het nie normale waarskuwing nie, en ten tyde van die keuse was daar geen stawing nie
Ek moet sê dat die laaste punt onlangs beter en bykomend geword het (insluitend verifikasie) het die prysmodel self begin verander.
Maar in die tyd toe ons hierdie oplossing gaan ontplooi, was daar geen waarskuwing nie.
Miskien kon ons probeer het om iets te bou deur ElastAlert of ander gemeenskapsoplossings te gebruik, maar ons het steeds besluit om ander alternatiewe te oorweeg.
Loki - Grafana - Prometheus
Op die oomblik kan 'n goeie oplossing wees om 'n moniteringsstapel te bou wat suiwer gebaseer is op Prometheus as 'n statistiekverskaffer, Loki vir logs, en vir visualisering kan jy dieselfde Grafana gebruik.
Ongelukkig, ten tyde van die aanvang van die verkoopsloods van die projek (September-Oktober 19), was Loki nog in beta-weergawe 0.3-0.4, en ten tyde van die aanvang van ontwikkeling kon dit nie as 'n produksieoplossing beskou word nie. enigsins.
Ek het nog nie ondervinding om Loki in ernstige projekte te gebruik nie, maar ek kan sê dat Promtail ('n agent vir die versameling van houtblokke) uitstekend werk vir beide kaalmetaal en peule in kubernetes.
TIK
Miskien kan die mees waardige (die enigste?) volwaardige alternatief vir die ELK-stapel nou net die TICK-stapel genoem word - Telegraf, InfluxDB, Chronograf, Kapacitor.
Ek sal al die komponente hieronder in meer besonderhede beskryf, maar die algemene idee is die volgende:
- Telegraf - agent vir die insameling van metrieke
- InfluxDB - metrieke databasis
- Kapasitor - real-time metrieke verwerker vir waarskuwing
- Chronograf - webpaneel vir visualisering
Vir InfluxDB, Kapacitor en Chronograf is daar amptelike stuurkaarte wat ons gebruik het om dit te ontplooi.
Daar moet kennis geneem word dat Kapacitor en Chronograf in die jongste weergawe van Influx 2.0 (beta) deel geword het van InfluxDB en nie meer afsonderlik bestaan nie
Telegraaf
is 'n baie liggewig agent vir die insameling van metrieke op 'n staatsmasjien.
Hy kan 'n groot hoeveelheid van alles monitor, van aan
bediener .
Dit het 'n aantal koel voordele:
- Vinnig en liggewig (in Go geskryf)
- Eet 'n minimum hoeveelheid hulpbronne
- Druk maatstawwe by verstek
- Versamel alle nodige maatstawwe
- Stelselstatistieke sonder enige instellings
- Hardeware-metrieke soos inligting van sensors
- Dit is baie maklik om jou eie maatstawwe by te voeg
- Baie plugins uit die boks
- Versamel logs
Aangesien stootmaatstawwe vir ons nodig was, was alle ander voordele meer as aangename toevoegings.
Die versameling van logs deur die agent self is ook baie gerieflik, aangesien dit nie nodig is om bykomende nutsprogramme aan te sluit om logs aan te teken nie.
Influx bied die gerieflikste ervaring om met logs te werk as jy dit gebruik .
Telegraf is oor die algemeen 'n uitstekende agent vir die insameling van statistieke, selfs al gebruik jy nie die res van die ICK-stapel nie.
Baie mense kruis dit gerieflikheidshalwe met ELK en verskeie ander tydreeksdatabasisse, aangesien dit byna oral statistieke kan skryf.
InstromingDB
InfluxDB is die hoofkern van die TICK-stapel, naamlik 'n tydreeksdatabasis vir metrieke.
Benewens metrieke, kan Influx ook logs stoor, hoewel logs in wese net dieselfde statistieke is, maar in plaas van die gewone numeriese aanwysers, word die hooffunksie deur 'n reël logteks uitgevoer.
InfluxDB is ook in Go geskryf en dit lyk asof dit baie vinniger loop in vergelyking met ELK op ons (nie die kragtigste) groep.
Een van die cool voordele van Influx sou ook 'n baie gerieflike en ryk API vir data-navrae insluit, wat ons baie aktief gebruik het.
Nadele - $$$ of skaal?
Die TICK-stapel het net een nadeel wat ons ontdek het - dit liewe. Selfs meer.
Wat het die betaalde weergawe wat die gratis weergawe nie het nie?
Sover ons kon verstaan, is die enigste verskil tussen die betaalde weergawe van die TICK-stapel en die gratis een die skaalvermoëns.
U kan naamlik 'n groepering met Hoë beskikbaarheid slegs in .
As jy volwaardige HA wil hê, moet jy óf betaal óf 'n paar krukke gebruik. Daar is 'n paar gemeenskapsoplossings - byvoorbeeld lyk na 'n bekwame oplossing, maar daar word geskryf dat dit nie geskik is vir produksie, sowel as
- 'n eenvoudige oplossing met data wat deur NATS pomp (dit sal ook afgeskaal moet word, maar dit kan opgelos word).
Dit is jammer, maar dit lyk of albei van hulle laat vaar is - daar is geen nuwe commits nie, ek neem aan dat die probleem die binnekort verwagte vrystelling van die nuwe weergawe van Influx 2.0 is, waarin baie dinge anders sal wees (daar is geen inligting oor skaal nog daarin).
Amptelik is daar 'n gratis weergawe - in werklikheid is dit 'n primitiewe HA, maar slegs deur balansering,
aangesien alle data na alle InfluxDB-instansies agter die lasbalanseerder geskryf sal word.
Hy het 'n paar soos potensiële probleme met oorskryfpunte en die behoefte om vooraf basisse vir metrieke te skep
(wat outomaties gebeur tydens normale werk met InfluxDB).
Daarbenewens , beteken dit bykomende bokoste vir duplikaatstatistieke (beide verwerking en berging) wat jy dalk nie nodig het nie, maar daar is geen manier om hulle te skei nie.
Victoria Metrieke?
As gevolg hiervan, ten spyte van die feit dat ons heeltemal tevrede was met die TICK-stapel in alles anders as betaalde skaal, het ons besluit om te kyk of daar enige gratis oplossings is wat die InfluxDB-databasis kan vervang, terwyl ons die oorblywende T_CK-komponente verlaat.
Daar is baie tydreeksdatabasisse, maar die mees belowende een is Victoria Metrics, dit het 'n aantal voordele:
- Vinnig en maklik, ten minste volgens die resultate
- Daar is 'n groepweergawe, waaroor daar nou selfs goeie resensies is
- Sy kan skeur
- Ondersteun InfluxDB-protokol
Ons was nie van plan om 'n heeltemal pasgemaakte stapel gebaseer op Victoria te bou nie en die hoofhoop was dat ons dit kon gebruik as 'n drop-in plaasvervanger vir InfluxDB.
Ongelukkig is dit nie moontlik nie, ten spyte van die feit dat die InfluxDB-protokol ondersteun word, werk dit net vir die opname van statistieke - slegs die Prometheus API is "buite" beskikbaar, wat beteken dat dit nie moontlik sal wees om Chronograf daarop te stel nie.
Boonop word slegs numeriese waardes vir metrieke ondersteun (ons het stringwaardes vir pasgemaakte metrieke gebruik - meer daaroor in die afdeling ).
Uiteraard kan die VM om dieselfde rede nie logs stoor soos Influx doen nie.
Daar moet ook op gelet word dat Victoria Metrics ten tyde van die soeke na die optimale oplossing nog nie so gewild was nie, die dokumentasie baie kleiner was en die funksionaliteit swakker was.
(Ek onthou nie 'n gedetailleerde beskrywing van die cluster-weergawe en sharding nie).
Basis keuse
Gevolglik is besluit dat ons vir die vlieënier ons steeds tot 'n enkele InfluxDB-nodus sal beperk.
Daar was verskeie hoofredes vir hierdie keuse:
- Ons het baie van die hele funksionaliteit van die TICK-stapel gehou
- Ons het reeds daarin geslaag om dit te ontplooi en dit het uitstekend gewerk
- Die spertye was besig om uit te loop en daar was nie veel tyd oor om ander opsies te toets nie.
- Ons het nie so 'n swaar vrag verwag nie
Ons het nie baie bromponies gehad vir die eerste fase van die loods nie, en toetsing tydens ontwikkeling het geen prestasieprobleme aan die lig gebring nie.
Daarom het ons besluit dat vir hierdie projek een Instromingsnodus vir ons genoeg sal wees sonder die behoefte aan skaal (sien gevolgtrekkings aan die einde).
Ons het op die stapel en basis besluit – nou oor die oorblywende komponente van die TICK-stapel.
Kapasitor
Kapacitor is deel van die TICK-stapel, 'n diens wat statistieke wat die databasis binnegaan intyds kan monitor en verskeie aksies kan uitvoer gebaseer op reëls.
Oor die algemeen is dit geposisioneer as 'n instrument vir moontlike afwykingsopsporing en masjienleer (ek is nie seker dat hierdie funksies in aanvraag is nie), maar die gewildste geval van die gebruik daarvan is meer algemeen - waarskuwing.
Dit is hoe ons dit vir kennisgewings gebruik het. Ons het Slack-waarskuwings opgestel wanneer 'n spesifieke bromponie vanlyn gegaan het, en dieselfde is gedoen vir slimlaaiers en belangrike infrastruktuurkomponente.
Dit het dit moontlik gemaak om vinnig op probleme te reageer, asook kennisgewings te ontvang dat alles weer normaal is.
'n Eenvoudige voorbeeld: 'n bykomende battery om ons "boks" aan te dryf het gebreek of om een of ander rede het krag opgeraak; bloot deur 'n nuwe een te installeer, behoort ons na 'n rukkie 'n kennisgewing te ontvang dat die bromponie se funksionaliteit herstel is.
In Influx 2.0 het Kapacitor deel van DB geword
Chronograaf
Ek het baie verskillende UI-oplossings vir monitering gesien, maar ek kan sê dat in terme van funksionaliteit en UX niks vergelyk met Chronograf nie.
Ons het die TICK-stapel begin gebruik, vreemd genoeg, met Grafan as 'n webkoppelvlak.
Ek sal nie die funksionaliteit daarvan beskryf nie; almal ken sy wye moontlikhede om enigiets op te stel.
Grafana is egter steeds 'n heeltemal universele instrument, terwyl Chronograf hoofsaaklik ontwerp is vir gebruik met Influx.
En natuurlik, danksy hierdie, kan Chronograf baie meer slim of gerieflike funksionaliteit bekostig.
Miskien is die belangrikste gerief van werk met Chronograf dat jy die binnekant van jou InfluxDB deur Explore kan sien.
Dit wil voorkom asof Grafana amper identiese funksionaliteit het, maar in werklikheid kan die opstel van 'n dashboard in Chronograf met 'n paar muisklik gedoen word (kyk terselfdertyd na die visualisering daar), terwyl jy in Grafana nog steeds vroeër of later sal hê om die JSON-konfigurasie te wysig (natuurlik kan Chronograf jou handgekonfigureerde dashas oplaai en dit as JSON wysig indien nodig - maar ek hoef nooit daaraan te raak nadat ek dit op die UI geskep het nie).
Kibana het baie ryker vermoëns om dashboards en kontroles daarvoor te skep, maar die UX vir sulke bedrywighede is baie kompleks.
Dit sal 'n bietjie goeie begrip verg om 'n gerieflike dashboard te skep. En hoewel die funksionaliteit van Chronograf-kontroleskerms minder is, is dit baie makliker om dit te maak en aan te pas.
Die paneelborde self, afgesien van die aangename visuele styl, verskil eintlik nie van die paneelborde in Grafana of Kibana nie:
Dit is hoe die navraagvenster lyk:
Dit is belangrik om, onder andere, daarop te let dat die chronograaf self soms outomaties kan help met die skryf van 'n navraag of die keuse van die korrekte samevoegingsfunksie soos gemiddeld, met kennis van die tipe velde in die InfluxDB-databasis.
En natuurlik is Chronograf so gerieflik as moontlik om logs te bekyk. Dit lyk so:
By verstek is Influx logs aangepas om syslog te gebruik en daarom het hulle 'n belangrike parameter - erns.
Die grafiek aan die bokant is veral nuttig; daarop kan jy die foute sien wat voorkom en die kleur wys dadelik duidelik of die erns hoër is.
Ons het 'n paar keer belangrike goggas op hierdie manier gevang, die logboeke vir die afgelope week bekyk en 'n rooi punt gesien.
Natuurlik, ideaal sou dit wees om waarskuwings vir sulke foute op te stel, aangesien ons reeds alles hiervoor gehad het.
Ons het dit selfs vir 'n rukkie aangeskakel, maar in die proses om die loods voor te berei, het dit geblyk dat ons heelwat foute gekry het (insluitend stelsels soos die onbeskikbaarheid van die LTE-netwerk), wat die Slack-kanaal ook "gespam" het baie, sonder om enige probleme te veroorsaak groot voordeel.
Die korrekte oplossing sal wees om die meeste van hierdie tipe foute te hanteer, die erns daarvoor aan te pas en dan eers waarskuwing te aktiveer.
Op hierdie manier sal slegs nuwe of belangrike foute na Slack gepos word. Daar was eenvoudig nie genoeg tyd vir so 'n opstelling gegewe die streng spertye nie.
verifikasie
Dit is ook die moeite werd om te noem dat Chronograf OAuth en OIDC as verifikasie ondersteun.
Dit is baie gerieflik, aangesien dit jou toelaat om dit maklik aan jou bediener te koppel en volwaardige SSO te skep.
In ons geval was die bediener - dit is gebruik om aan monitering te koppel, maar dieselfde bediener is ook gebruik om bromponies en versoeke na die agterkant te verifieer.
"Admin"
Die laaste komponent wat ek sal beskryf, is ons selfgeskrewe "adminpaneel" in Vue.
Basies is dit net 'n selfstandige diens wat bromponie-inligting vanaf ons eie databasisse, mikrodienste en metrieke data van InfluxDB gelyktydig vertoon.
Daarbenewens is baie administratiewe funksies daarheen geskuif, soos 'n noodherlaai of 'n slot vir die ondersteuningspan op afstand oopmaak.
Daar was ook kaarte. Ek het reeds genoem dat ons met Grafana begin het in plaas van Chronograf - want vir Grafana is kaarte beskikbaar in die vorm van plugins, waarop ons die koördinate van bromponies kan sien. Ongelukkig is die vermoëns van kaartlegstukke vir Grafana baie beperk, en gevolglik was dit baie makliker om binne 'n paar dae jou eie webtoepassing met kaarte te skryf, om nie net die koördinate op die oomblik te sien nie, maar ook te vertoon die roete wat die bromponie geneem het, die data op kaart kan filtreer, ens. (al daardie funksionaliteit wat ons nie in 'n eenvoudige dashboard kon konfigureer nie).
Een van die reeds genoemde voordele van Influx is die vermoë om maklik jou eie maatstawwe te skep.
Dit laat dit toe om vir 'n groot verskeidenheid scenario's gebruik te word.
Ons het probeer om alle nuttige inligting daar op te teken: batterylading, slotstatus, sensorwerkverrigting, bluetooth, GPS en baie ander gesondheidsondersoeke.
Ons het dit alles op die administrasiepaneel vertoon.
Natuurlik was die belangrikste maatstaf vir ons die bedryfstoestand van die bromponie - trouens, Influx kontroleer dit self en wys dit met "groen ligte" in die Nodes-afdeling.
Dit word gedoen deur die funksie - ons het dit gebruik om die werkverrigting van ons boks te verstaan en dieselfde waarskuwings na Slack te stuur.
Terloops, ons het die bromponies genoem na die name van karakters uit The Simpsons - dit was so gerieflik om hulle van mekaar te onderskei
En oor die algemeen was dit meer pret op hierdie manier. Frases soos “Ouens, Smithers is dood!” is voortdurend gehoor.
String statistieke
Dit is belangrik dat InfluxDB jou toelaat om nie net numeriese waardes te stoor nie, soos die geval is met Victoria Metrics.
Dit wil voorkom asof dit nie so belangrik is nie - na alles, behalwe logs, kan enige metrieke gestoor word in die vorm van getalle (voeg net kartering by vir bekende toestande - 'n soort enum)?
In ons geval was daar ten minste een scenario waar string statistieke baie nuttig was.
Dit het toevallig toevallig dat die verskaffer van ons “slim laaiers” 'n derde party was, ons het geen beheer gehad oor die ontwikkelingsproses en die inligting wat hierdie laaiers kon verskaf nie.
As gevolg hiervan was die laai-API ver van ideaal, maar die grootste probleem was dat ons nie altyd hul toestand kon verstaan nie.
Dit is hier waar Influx tot die redding gekom het. Ons het eenvoudig die stringstatus wat na ons gekom het in die InfluxDB-databasisveld sonder veranderinge geskryf.
Vir 'n geruime tyd het net waardes soos "aanlyn" en "vanlyn" daar gekom, gebaseer op watter inligting in ons administrasiepaneel vertoon is, en kennisgewings aan Slack gestuur is. Op 'n stadium het waardes soos "ontkoppel" egter ook daar begin verskyn.
Soos dit later geblyk het, is hierdie status een keer gestuur na 'n verlies van verbinding, as die laaier nie 'n verbinding met die bediener kon vestig na 'n sekere aantal pogings nie.
Dus, as ons slegs 'n vaste stel waardes gebruik het, sal ons hierdie veranderinge dalk nie op die regte tyd in die firmware sien nie.
En oor die algemeen bied string-metrieke baie meer gebruiksmoontlikhede; jy kan feitlik enige inligting daarin opneem. Alhoewel jy natuurlik ook hierdie instrument versigtig moet gebruik.
Benewens die gewone statistieke, het ons ook GPS-ligginginligting in InfluxDB aangeteken. Dit was ongelooflik nuttig om die ligging van bromponies in ons administrasiepaneel te monitor.
Trouens, ons het altyd geweet waar en watter bromponie was op die oomblik wat ons nodig gehad het.
Dit was vir ons baie nuttig toe ons 'n bromponie gesoek het (sien gevolgtrekkings aan die einde).
Infrastruktuur monitering
Benewens die bromponies self, moes ons ook ons hele (nogal uitgebreide) infrastruktuur monitor.
'n Baie algemene argitektuur het iets soos volg gelyk:
As ons 'n suiwer moniteringsstapel uitlig, lyk dit soos volg:
Wat ons graag in die wolk wil nagaan, is:
- databasisse
- Sleutelmantel
- Mikrodienste
Aangesien al ons wolkdienste in Kubernetes geleë is, sal dit lekker wees om inligting oor die toestand daarvan in te samel.
Gelukkig kan Telegraf uit die boks 'n groot aantal statistieke oor die toestand van die Kubernetes-groepering insamel, en Chronograf bied onmiddellik pragtige dashboards hiervoor.
Ons het hoofsaaklik die werkverrigting van die peule en geheueverbruik gemonitor. In die geval van 'n val, waarskuwings in Slack.
Daar is twee maniere om peule in Kubernetes op te spoor: DaemonSet en Sidecar.
Beide metodes word in detail beskryf .
Ons het Telegraf Sidecar gebruik en, benewens metrieke, podlogs versamel.
In ons geval moes ons aan die stompe peuter. Ten spyte van die feit dat Telegraf logs van die Docker API kan trek, wou ons 'n eenvormige versameling logs hê met ons eindtoestelle en gekonfigureerde syslog vir houers hiervoor. Miskien was hierdie oplossing nie mooi nie, maar daar was geen klagtes oor sy werk nie en die logs is goed vertoon in Chronograf.
Monitor monitering???
Op die ou end het die eeue oue vraag van monitering van moniteringstelsels ontstaan, maar gelukkig, of ongelukkig, het ons eenvoudig nie genoeg tyd hiervoor gehad nie.
Alhoewel Telegraf maklik sy eie statistieke kan stuur of statistieke van die InfluxDB-databasis kan insamel om óf na dieselfde Influx óf iewers anders te stuur.
Bevindinge
Watter gevolgtrekkings het ons uit die resultate van die loods gemaak?
Hoe kan jy monitering doen?
Eerstens het die TICK-stapel ten volle aan ons verwagtinge voldoen en ons selfs meer geleenthede gegee as wat ons aanvanklik verwag het.
Al die funksionaliteit wat ons nodig gehad het, was teenwoordig. Alles wat ons daarmee gedoen het, het sonder probleme gewerk.
produktiwiteit
Die grootste probleem met die TICK-stapel in die gratis weergawe is die gebrek aan skaalvermoë. Dit was nie vir ons 'n probleem nie.
Ons het nie presiese vragdata/syfers ingesamel nie, maar ons het data van ongeveer 30 bromponies op 'n slag ingesamel.
Elkeen van hulle het meer as drie dosyn statistieke ingesamel. Terselfdertyd is logs van die toestelle versamel. Data-insameling en versending het elke 10 sekondes plaasgevind.
Dit is belangrik om daarop te let dat ons na 'n week en 'n half van die loodstyd, toe die grootste deel van die "kinderprobleme" reggestel is en die belangrikste probleme reeds opgelos is, die frekwensie van die stuur van data na die bediener moes verminder om 30 sekondes. Dit het nodig geword omdat die verkeer op ons LTE SIM-kaarte vinnig begin verdwyn het.
Die grootste deel van die verkeer is deur logs verteer; die maatstawwe self, selfs met 'n 10-sekonde interval, het dit feitlik nie gemors nie.
As gevolg hiervan het ons na 'n rukkie die versameling van logboeke op toestelle heeltemal gedeaktiveer, aangesien spesifieke probleme reeds voor die hand liggend was, selfs sonder konstante versameling.
In sommige gevalle, as dit steeds nodig was om die logs te bekyk, het ons eenvoudig via WireGuard via VPN gekoppel.
Ek sal ook byvoeg dat elke afsonderlike omgewing van mekaar geskei is, en die las wat hierbo beskryf is, was slegs relevant vir die produksie-omgewing.
In die ontwikkelingsomgewing het ons 'n aparte InfluxDB-instansie geopper wat aanhou om data elke 10 sekondes in te samel en ons het geen prestasieprobleme ondervind nie.
TICK - ideaal vir klein tot medium projekte
Op grond van hierdie inligting sou ek tot die gevolgtrekking kom dat die TICK-stapel ideaal is vir relatief klein projekte of projekte wat beslis geen HighLoad verwag nie.
As jy nie duisende peule of honderde masjiene het nie, sal selfs een InfluxDB-instansie die vrag goed hanteer.
In sommige gevalle kan jy tevrede wees met Influx Relay as 'n primitiewe oplossing vir hoë beskikbaarheid.
En natuurlik keer niemand jou om “vertikale” skaal op te stel en bloot verskillende bedieners vir verskillende soorte statistieke toe te ken nie.
As jy nie seker is oor die verwagte las op die moniteringsdienste nie, of jy is gewaarborg om 'n baie "swaar" argitektuur te hê/sal hê, sal ek nie aanbeveel om die gratis weergawe van die TICK-stapel te gebruik nie.
Natuurlik sou 'n eenvoudige oplossing wees om te koop - maar hier kan ek nie op een of ander manier kommentaar lewer nie, aangesien ek self nie met die subtiliteite vertroud is nie. Behalwe die feit dat dit baie duur is en beslis nie geskik is vir klein maatskappye nie.
In hierdie geval sal ek vandag aanbeveel om metrieke in te samel deur middel van Victoria Metrics en logs met Loki.
Ek sal weliswaar weer 'n voorbehoud maak dat Loki/Grafana baie minder gerieflik is (weens hul groter veelsydigheid) as die klaargemaakte TICK, maar hulle is gratis.
Dit is belangrik om: al die inligting wat hier beskryf word, is relevant vir weergawe Influx 1.8, op die oomblik is Influx 2.0 op die punt om vrygestel te word.
Alhoewel ek nie kans gehad het om dit in gevegsomstandighede te probeer nie en dit moeilik is om gevolgtrekkings oor verbeterings te maak, het die koppelvlak beslis nog beter geword, die argitektuur is vereenvoudig (sonder kapasitor en chronograf),
sjablone het verskyn ("killer feature" - ). Maar ongelukkig het weergawe 2 op die oomblik nie die belangrikste ding waarvoor ons die eerste weergawe gekies het nie - daar is geen logboekversameling nie.
Hierdie funksionaliteit sal ook in Influx 2.0 verskyn, maar ons kon geen sperdatums vind nie, selfs by benadering.
Hoe om nie IoT-platforms te maak nie (nou)
Op die ou end, nadat ons die vlieënier van stapel gestuur het, het ons self ons eie volwaardige IoT-stapel saamgestel, in die afwesigheid van 'n alternatief wat volgens ons standaarde geskik is.
Dit is egter onlangs in Beta-weergawe beskikbaar - dit is jammer sy was nie daar toe ons die projek begin maak het nie.
Ons is heeltemal tevrede met die eindresultaat en die platform gebaseer op Ansible + TICK + WireGuard wat ons self saamgestel het. Maar vandag sal ek aanbeveel om Balena van nader te bekyk voordat jy self jou eie IoT-platform probeer bou.
Want uiteindelik kan dit die meeste doen van wat ons gedoen het, en OpenBalena is gratis en oopbron.
Dit weet reeds hoe om nie net opdaterings te stuur nie, maar ook 'n VPN is reeds ingebou en aangepas vir gebruik in 'n IoT-omgewing.
En net onlangs het hulle selfs hul , wat maklik met hul ekosisteem verbind.
Haai, wat van die vermiste bromponie?
So het die bromponie, "Ralph", spoorloos verdwyn.
Ons het dadelik gehardloop om na die kaart in ons "admin-paneel" te kyk, met GPS-metriekdata van InfluxDB.
Danksy moniteringsdata het ons maklik vasgestel dat die bromponie verlede dag omstreeks 21:00 die parkeerterrein verlaat het, sowat 'n halfuur na een of ander area gery het en tot 5:XNUMX langs een of ander Duitse huis geparkeer was.
Na 5:XNUMX is geen moniteringsdata ontvang nie - dit het beteken óf die bykomende battery was heeltemal ontlaai, óf die aanvaller het uiteindelik uitgevind hoe om die slim hardeware van die bromponie te verwyder.
Ten spyte hiervan is die polisie steeds ontbied na die adres waar die bromponie geleë was. Die bromponie was nie daar nie.
Die eienaar van die huis was egter ook hieroor verras, aangesien hy eintlik gisteraand van die kantoor af met hierdie bromponie huis toe gery het.
Soos dit geblyk het, het een van die ondersteuningswerknemers vroegoggend opgedaag en die bromponie opgetel, siende dat sy bykomende battery heeltemal leeg was en dit (te voet) na die parkeerterrein geneem het. En die bykomende battery het misluk weens vog.
Ons het die bromponie by onsself gesteel. Terloops, ek weet nie hoe en wie dan die probleem met die polisiesaak opgelos het nie, maar die monitering het perfek gewerk...
Bron: will.com