Pred letom dni smo lansirali pilotno različico promocijskega projekta za .
Sprva se je projekt imenoval Road-To-Barcelona, kasneje Road-To-Berlin (torej R2B na posnetkih), na koncu pa se je imenoval xRide.
Glavna ideja projekta je bila naslednja: namesto centralizirane storitve izposoje avtomobilov ali skuterjev (govorimo o skuterjih ali električnih motociklih, ne o skuterjih/skirojih), smo želeli narediti platformo za decentralizirano izposojo. O težavah, s katerimi smo se srečali .
Sprva se je projekt osredotočal na avtomobile, vendar so bili zaradi rokov, izjemno dolge komunikacije s proizvajalci in ogromnega števila varnostnih omejitev za pilota izbrani električni skiroji.
Uporabnik je na telefon namestil iOS ali Android aplikacijo, pristopil do skuterja, ki mu je bil všeč, nakar sta telefon in skuter vzpostavila povezavo enakovrednega, ETH je bil izmenjan in uporabnik je lahko začel vožnjo z vklopom skuterja preko telefon. Ob koncu potovanja je bilo možno tudi plačilo potovanja z uporabo Ethereuma iz uporabnikove denarnice na telefonu.
Poleg skuterjev je uporabnik v aplikaciji videl »pametne polnilce«, z obiskom katerih je lahko sam zamenjal trenutno baterijo, če je bila prazna.
Tako je na splošno izgledal naš pilot, ki smo ga lansirali septembra lani v dveh nemških mestih: Bonnu in Berlinu.
In potem, nekega dne, v Bonnu, zgodaj zjutraj, je bila naša podporna ekipa (na kraju samem za vzdrževanje skuterjev v delovnem stanju) obveščena: eden od skuterjev je izginil brez sledu.
Kako ga najti in vrniti?
V tem članku bom govoril o tem, a najprej o tem, kako smo zgradili lastno IoT platformo in kako smo jo spremljali.
Kaj in zakaj spremljati: skuterje, infrastrukturo, polnilne postaje?
Torej, kaj smo želeli spremljati v našem projektu?
Najprej so to sami skuterji - električni skuterji so sami po sebi precej dragi, takšnega projekta ne morete zagnati, če niste ustrezno pripravljeni; če je le mogoče, želite zbrati čim več informacij o skuterjih: o njihovi lokaciji, ravni napolnjenosti itd.
Poleg tega bi rad spremljal stanje lastne IT infrastrukture – baz podatkov, storitev in vsega, kar potrebujejo za delovanje. Prav tako je bilo treba spremljati stanje »pametnih polnilcev«, če bi se pokvarili ali izpraznili polne baterije.
Skuterji
Kakšni so bili naši skiroji in kaj smo želeli vedeti o njih?
Prva in najpomembnejša stvar so GPS koordinate, saj po njih lahko razumemo, kje so in kam se gibljejo.
Sledi polnjenje baterije, zahvaljujoč kateri lahko ugotovimo, da se polnjenje skuterjev bliža koncu in pošljemo sokovnik ali vsaj opozorimo uporabnika.
Seveda je treba preveriti tudi, kaj se dogaja z našimi strojnimi komponentami:
- ali bluetooth deluje?
- ali sam modul GPS deluje?
- Imeli smo tudi težavo, da je GPS lahko pošiljal napačne koordinate in se zataknil, to pa je bilo mogoče ugotoviti le z dodatnimi pregledi skuterja,
in čim prej obvestite podporo za rešitev težave
- Imeli smo tudi težavo, da je GPS lahko pošiljal napačne koordinate in se zataknil, to pa je bilo mogoče ugotoviti le z dodatnimi pregledi skuterja,
In nazadnje: pregledi programske opreme, začenši z operacijskim sistemom in procesorjem, obremenitvijo omrežja in diska, konča s pregledi lastnih modulov, ki so bolj specifični za nas (, ).
strojna oprema
Kaj je bil naš "železni" del?
Upoštevajoč najkrajši možni časovni okvir in potrebo po hitri izdelavi prototipov smo izbrali najlažjo možnost izvedbe in izbire komponent - Raspberry Pi.
Poleg samega Rpi smo imeli custom board (ki smo ga sami razvili in naročili iz Kitajske za pospešitev procesa sestavljanja končne rešitve) in komplet komponent - rele (za vklop/izklop skuterja), čitalnik napolnjenosti baterije, modem, antene. Vse to je bilo kompaktno zapakirano v poseben “xRide box”.
Treba je tudi omeniti, da je celotno škatlo napajal dodatni power bank, ta pa iz glavne baterije skuterja.
To je omogočilo uporabo nadzora in vklop skuterja tudi po koncu vožnje, saj se je glavna baterija izklopila takoj po obračanju ključa za vžig v položaj "off".
Docker? Navadni Linux? in uvajanje
Vrnimo se k spremljanju, torej Raspberry - kaj imamo?
Ena od prvih stvari, ki smo jih želeli uporabiti za pospešitev postopka uvajanja, posodabljanja in dostave komponent fizičnim napravam, je bil Docker.
Na žalost je hitro postalo jasno, da ima Docker na RPi, čeprav deluje, veliko režijskih stroškov, zlasti v smislu porabe energije.
Razlika z uporabo »domačega« OS, čeprav ne tako močna, je bila vseeno zadostna, da smo bili pozorni na možnost prehitre izgube napolnjenosti.
Drugi razlog je bila ena od naših partnerskih knjižnic na Node.js (sic!) – edina komponenta sistema, ki ni bila napisana v Go/C/C++.
Avtorji knjižnice niso imeli časa zagotoviti delovne različice v nobenem od "maternih" jezikov.
Ne samo, da samo vozlišče ni najelegantnejša rešitev za nizko zmogljive naprave, ampak je bila sama knjižnica zelo požrešna po virih.
Ugotovili smo, da bi uporaba Dockerja, tudi če bi to želeli, za nas predstavljala prevelik strošek. Izbira je bila narejena v korist domačega OS in dela neposredno pod njim.
OS
Posledično smo ponovno izbrali najpreprostejšo možnost kot OS in uporabili Raspbian (Debian build for Pi).
V Go pišemo vso svojo programsko opremo, zato smo v Go napisali tudi modul glavnega posrednika strojne opreme v našem sistemu.
On je odgovoren za delo z GPS, Bluetooth, branje polnjenja, vklop skuterja itd.
Razporedi
Takoj se je pojavilo vprašanje o potrebi po implementaciji mehanizma za dostavo posodobitev naprav (OTA) - tako posodobitev našega agenta/aplikacije kot same posodobitve OS/firmware (ker bi nove različice agenta lahko zahtevale posodobitve jedra ali sistemske komponente, knjižnice itd.).
Po precej dolgi analizi trga se je izkazalo, da obstaja kar nekaj rešitev za dostavo posodobitev v napravo.
Od razmeroma preprostih pripomočkov, ki so večinoma usmerjeni v posodabljanje/dvojni zagon, kot je swupd/SWUpdate/OSTree, do polnopravnih platform, kot sta Mender in Balena.
Najprej smo se odločili, da nas zanimajo rešitve od konca do konca, zato je izbira takoj padla na platforme.
Zelo je bil izključen zaradi dejstva, da dejansko uporablja isti Docker znotraj svojega balenaEngine.
Vendar ugotavljam, da smo kljub temu na koncu nenehno uporabljali njihov izdelek za vdelano programsko opremo flash na karticah SD - preprost in izjemno priročen pripomoček za to.
Zato je na koncu izbira padla . Mender je popolna platforma za sestavljanje, dostavo in namestitev vdelane programske opreme.
Na splošno je platforma videti odlično, vendar smo potrebovali približno teden in pol, da smo zgradili pravilno različico naše vdelane programske opreme z graditeljem mender.
In bolj ko smo se poglabljali v zapletenost njegove uporabe, bolj je postajalo jasno, da bomo za njegovo popolno uvedbo potrebovali veliko več časa, kot smo ga imeli.
Žal, naši kratki roki so povzročili, da smo bili prisiljeni opustiti uporabo Menderja in izbrati še enostavnejšega.
Možno
Najenostavnejša rešitev v naši situaciji je bila uporaba Ansible. Nekaj knjig iger je bilo dovolj za začetek.
Njihovo bistvo je bilo v tem, da smo se iz gostitelja (CI strežnika) preprosto povezali preko ssh-a na naše rasberries in jim distribuirali posodobitve.
Na samem začetku je bilo vse preprosto - morali ste biti v istem omrežju z napravami, točenje je potekalo prek Wi-Fi.
V pisarni je bilo preprosto ducat testnih malin povezanih v isto omrežje, vsaka naprava je imela statični naslov IP, ki je bil prav tako določen v Ansible Inventory.
Ansible je bil tisti, ki je dostavil našega nadzornega agenta do končnih naprav
3G / LTE
Na žalost je ta primer uporabe za Ansible lahko deloval le v razvojnem načinu, preden smo imeli dejanske skuterje.
Ker skuterji, kot razumete, ne sedijo povezani z enim usmerjevalnikom Wi-Fi in nenehno čakajo na posodobitve prek omrežja.
V resnici skuterji sploh ne morejo imeti nobene druge povezave razen mobilnega 3G/LTE (pa še to ne ves čas).
To takoj naloži številne težave in omejitve, kot sta nizka hitrost povezave in nestabilna komunikacija.
Najpomembnejše pa je, da se v omrežju 3G/LTE ne moremo preprosto zanesti na statični IP, dodeljen omrežju.
To delno rešujejo nekateri ponudniki SIM kartic, obstajajo celo posebne SIM kartice, namenjene IoT napravam s statičnimi naslovi IP. Vendar nismo imeli dostopa do takih kartic SIM in nismo mogli uporabljati naslovov IP.
Seveda so bile ideje, da bi naredili nekakšno registracijo IP naslovov aka odkrivanje storitev nekje kot Consul, vendar smo morali takšne ideje opustiti, saj se je pri naših testih lahko IP naslov prepogosto spreminjal, kar je vodilo v veliko nestabilnost.
Iz tega razloga najprimernejša uporaba za dostavo metrik ne bi bila uporaba vlečnega modela, kjer bi šli do naprav po potrebne metrike, ampak potiskanje, dostava metrik iz naprave neposredno na strežnik
VPN
Kot rešitev tega problema smo izbrali VPN – konkretno .
Odjemalci (skuterji) so se ob zagonu sistema povezali s strežnikom VPN in se lahko nanje povezali. Ta tunel je bil uporabljen za dostavo posodobitev.
V teoriji bi lahko isti tunel uporabili za spremljanje, vendar je bila takšna povezava bolj zapletena in manj zanesljiva od preprostega potiska.
Viri v oblaku
Nenazadnje je potrebno spremljati naše oblačne storitve in baze podatkov, saj zanje uporabljamo Kubernetes, idealno, da je uvajanje spremljanja v gruči čim preprostejše. V idealnem primeru z uporabo , saj ga za uvajanje uporabljamo v večini primerov. In seveda, za spremljanje oblaka morate uporabiti enake rešitve kot za same skuterje.
dano
Fuj, zdi se, da smo uredili opis, naredimo seznam, kaj smo potrebovali na koncu:
- Hitra rešitev, saj je spremljanje potrebno že v procesu razvoja
- Obseg/količina – potrebne so številne meritve
- Zahtevano je zbiranje dnevnikov
- Zanesljivost – podatki so ključnega pomena za uspeh lansiranja
- Ne morete uporabiti vlečnega modela - potrebujete potiskanje
- Potrebujemo enotno spremljanje ne le strojne opreme, ampak tudi oblaka
Končna slika je izgledala nekako takole
Izbira sklada
Tako smo se soočili z vprašanjem izbire nadzornega sklada.
Najprej smo iskali najpopolnejšo rešitev vse-v-enem, ki bi hkrati pokrivala vse naše zahteve, a bila hkrati dovolj prilagodljiva, da bi njeno uporabo prilagodili našim potrebam. Kljub temu smo imeli veliko omejitev, ki so nam jih nalagali strojna oprema, arhitektura in roki.
Obstaja veliko različnih rešitev za spremljanje, začenši s popolnimi sistemi, kot je , ali in konča s pripravljenimi rešitvami za upravljanje voznega parka.
Sprva se nam je slednja zdela idealna rešitev, a nekatere niso imele popolnega nadzora, druge so imele močno omejene zmožnosti brezplačnih različic, tretje preprosto niso pokrivale naših »želj« ali pa niso bile dovolj prilagodljive, da bi ustrezale našim scenarijem. Nekateri so preprosto zastareli.
Po analizi številnih podobnih rešitev smo hitro prišli do zaključka, da bi bilo lažje in hitreje sami sestaviti podoben sklad. Da, to bo nekoliko bolj zapleteno kot uvedba popolnoma pripravljene platforme za upravljanje voznega parka, vendar nam ne bo treba sklepati kompromisov.
Skoraj zagotovo se v vsej množici rešitev že najde kakšna pripravljena, ki bi nam popolnoma ustrezala, vendar je bilo v našem primeru veliko hitreje, če smo sami sestavili določen kupček in ga prilagodili »zase«, kot pa testiranje že pripravljenih izdelkov.
Pri vsem tem nismo stremeli sami sestaviti celotne platforme za spremljanje, ampak smo iskali čim bolj funkcionalne »gotove« sklade, le z možnostjo njihove fleksibilne konfiguracije.
(B)ELK?
Prva rešitev, ki je bila dejansko obravnavana, je bil dobro znani sklad ELK.
Pravzaprav bi se moral imenovati BELK, saj se vse začne z Beats -
Seveda je ELK ena najbolj znanih in zmogljivih rešitev na področju monitoringa, še bolj pa zbiranja in obdelave dnevnikov.
Nameravali smo, da bi ELK uporabljali za zbiranje dnevnikov in tudi za dolgoročno shranjevanje metrik, pridobljenih od Prometheusa.
Za vizualizacijo lahko uporabite Grafan.
Pravzaprav lahko novi sklad ELK neodvisno zbira metrike (metricbeat), Kibana pa jih lahko tudi prikaže.
Kljub temu je ELK sprva zrasel iz dnevnikov in do zdaj ima funkcionalnost metrike številne resne pomanjkljivosti:
- Bistveno počasneje od Prometeja
- Integrira se na veliko manj mestih kot Prometheus
- Težko jim je nastaviti opozorila
- Meritve zavzamejo veliko prostora
- Nastavitev nadzornih plošč z metrikami v Kibanu je veliko bolj zapletena kot v Grafanu
Na splošno so metrike v ELK težke in še niso tako priročne kot v drugih rešitvah, od katerih je zdaj veliko več kot le Prometheus: TSDB, Victoria Metrics, Cortex itd., itd. Seveda bi si zelo želel takoj imeti popolno rešitev vse v enem, a v primeru metricbeata je bilo preveč kompromisov.
In sam sklad ELK ima številne težke trenutke:
- Težko je, včasih celo zelo težko, če zberete precej veliko količino podatkov
- Morate ga "znati kuhati" - morate ga povečati, vendar to ni nepomembno.
- Zmanjšana brezplačna različica - brezplačna različica nima običajnega opozarjanja in v času izbire ni bilo preverjanja pristnosti
Moram reči, da je v zadnjem času zadnja točka postala boljša in poleg tega (vključno z avtentikacijo) se je sam model oblikovanja cen začel spreminjati.
Toda v času, ko smo nameravali uvesti to rešitev, alarmiranja sploh ni bilo.
Morda bi lahko poskusili zgraditi nekaj z uporabo ElastAlert ali drugih rešitev skupnosti, vendar smo se vseeno odločili razmisliti o drugih alternativah.
Loki - Grafana - Prometej
Trenutno bi lahko bila dobra rešitev izgradnja sklada za spremljanje, ki temelji izključno na Prometheusu kot ponudniku metrik, Lokiju za dnevnike, za vizualizacijo pa lahko uporabite isto Grafano.
Žal je bil Loki v času začetka prodajnega pilota projekta (september-oktober 19) še v beta različici 0.3-0.4 in ga ob začetku razvoja ni bilo mogoče obravnavati kot produkcijsko rešitev. nasploh.
Nimam še izkušenj z dejansko uporabo Lokija v resnih projektih, vendar lahko rečem, da Promtail (agent za zbiranje dnevnikov) deluje odlično tako za bare-metal kot za pods v kubernetesu.
KLIKNI
Morda je najbolj vredna (edina?) popolna alternativa skladu ELK zdaj mogoče imenovati le sklad TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Spodaj bom podrobneje opisal vse komponente, vendar je splošna ideja naslednja:
- Telegraf - agent za zbiranje metrik
- InfluxDB - podatkovna baza metrik
- Kapacitor - metrični procesor v realnem času za opozarjanje
- Chronograf - spletna plošča za vizualizacijo
Za InfluxDB, Kapacitor in Chronograf obstajajo uradne karte za krmiljenje, ki smo jih uporabili za njihovo namestitev.
Upoštevati je treba, da sta v najnovejši različici Influx 2.0 (beta) Kapacitor in Chronograf postala del InfluxDB in ne obstajata več ločeno
telegraf
je zelo lahek agent za zbiranje metrik na državnem stroju.
Lahko spremlja ogromno vsega, od za
strežnika .
Ima številne kul prednosti:
- Hiter in lahek (napisano v Go)
- Poje minimalno količino virov
- Privzete potisne meritve
- Zbira vse potrebne metrike
- Sistemska metrika brez nastavitev
- Meritve strojne opreme, kot so informacije iz senzorjev
- Svoje meritve je zelo enostavno dodati
- Veliko vtičnikov takoj po namestitvi
- Zbira hlode
Ker so bile push metrike za nas nujne, so bile vse ostale prednosti več kot prijeten dodatek.
Zelo priročno je tudi zbiranje dnevnikov s strani samega agenta, saj ni treba priključiti dodatnih pripomočkov za beleženje dnevnikov.
Influx ponuja najbolj priročno izkušnjo za delo z dnevniki, če uporabljate .
Telegraf je na splošno odličen agent za zbiranje metrik, tudi če ne uporabljate preostalega sklada ICK.
Mnogi ljudje ga zaradi udobja križajo z ELK in različnimi drugimi bazami podatkov časovnih vrst, saj lahko zapiše meritve skoraj povsod.
InfluxDB
InfluxDB je glavno jedro sklada TICK, in sicer baza podatkov časovnih vrst za meritve.
Poleg meritev lahko Influx shranjuje tudi dnevnike, čeprav so dnevniki zanj v bistvu enake meritve, le da namesto običajnih numeričnih indikatorjev glavno funkcijo opravlja vrstica besedila dnevnika.
InfluxDB je prav tako napisan v Go in zdi se, da deluje veliko hitreje v primerjavi z ELK v naši (ne najmočnejši) gruči.
Ena od kul prednosti Influxa bi vključevala tudi zelo priročen in bogat API za podatkovne poizvedbe, ki smo ga zelo aktivno uporabljali.
Slabosti - $$$ ali skaliranje?
Sklad TICK ima samo eno pomanjkljivost, ki smo jo odkrili - to draga. Še več.
Kaj ima plačljiva različica, česar brezplačna različica nima?
Kolikor nam je uspelo razumeti, je edina razlika med plačljivo različico sklada TICK in brezplačno zmožnosti skaliranja.
Namreč, lahko dvignete gručo z visoko razpoložljivostjo samo v .
Če želite popolno HA, morate plačati ali uporabiti nekaj bergel. Obstaja nekaj skupnostnih rešitev - npr izgleda kompetentna rešitev, vendar piše, da ni primerna za proizvodnjo, pa tudi
- enostavna rešitev s črpanjem podatkov preko NATS (tudi to bo treba skalirati, a se da rešiti).
Škoda, vendar se zdi, da sta oba zapuščena - svežih commitov ni, predvidevam, da gre za kmalu pričakovani izid nove različice Influx 2.0, v kateri bo marsikaj drugače (ni informacij o skaliranje v njem še).
Uradno obstaja brezplačna različica - pravzaprav je to primitivna HA, vendar le z uravnoteženjem,
saj bodo vsi podatki zapisani v vse instance InfluxDB za izravnalnikom obremenitve.
Nekaj jih ima kot so morebitne težave s prepisovanjem točk in potreba po vnaprejšnjem ustvarjanju osnov za meritve
(kar se zgodi samodejno med običajnim delom z InfluxDB).
Poleg tega , to pomeni dodatne stroške za podvojene metrike (tako obdelavo kot shranjevanje), ki jih morda ne potrebujete, vendar jih ni mogoče ločiti.
Victoria Metrics?
Posledično smo se kljub dejstvu, da smo bili popolnoma zadovoljni s skladom TICK v vsem razen plačljivega skaliranja, odločili preveriti, ali obstajajo brezplačne rešitve, ki bi lahko nadomestile bazo podatkov InfluxDB, medtem ko smo pustili preostale komponente T_CK.
Obstaja veliko podatkovnih baz časovnih vrst, vendar je najbolj obetavna Victoria Metrics, ima številne prednosti:
- Hitro in enostavno, vsaj glede na rezultate
- Obstaja različica grozda, o kateri so zdaj celo dobre ocene
- Lahko drobi
- Podpira protokol InfluxDB
Nismo nameravali zgraditi povsem prilagojenega sklada, ki bi temeljil na Victorii, in glavno upanje je bilo, da bi ga lahko uporabili kot vmesno zamenjavo za InfluxDB.
Žal to ni mogoče, kljub dejstvu, da je protokol InfluxDB podprt, deluje samo za beleženje metrik - "zunaj" je na voljo samo Prometheus API, kar pomeni, da nanj ne bo mogoče nastaviti Chronografa.
Poleg tega so za meritve podprte samo številske vrednosti (uporabili smo vrednosti nizov za meritve po meri - več o tem v razdelku ).
Očitno iz istega razloga VM ne more shranjevati dnevnikov, kot to počne Influx.
Prav tako je treba opozoriti, da v času iskanja optimalne rešitve Victoria Metrics še ni bila tako priljubljena, dokumentacija je bila veliko manjša in funkcionalnost šibkejša.
(Ne spomnim se podrobnega opisa različice gruče in razdeljevanja).
Izbira podlage
Posledično smo se odločili, da se bomo za pilot še vedno omejili na eno samo vozlišče InfluxDB.
Za to izbiro je bilo več glavnih razlogov:
- Zelo nam je bila všeč celotna funkcionalnost sklada TICK
- Uspelo nam ga je že namestiti in delovalo je odlično
- Roki so se iztekali in ni bilo več veliko časa za testiranje drugih možnosti.
- Nismo pričakovali tako velike obremenitve
Za prvo fazo pilota nismo imeli veliko skuterjev in testiranje med razvojem ni razkrilo težav z zmogljivostjo.
Zato smo se odločili, da nam bo za ta projekt zadostovalo eno Influx vozlišče brez potrebe po skaliranju (glej zaključke na koncu).
Odločili smo se za sklad in osnovo - zdaj o preostalih komponentah sklada TICK.
kondenzator
Kapacitor je del sklada TICK, storitve, ki lahko v realnem času spremlja metrike, ki vstopajo v bazo podatkov, in izvaja različna dejanja na podlagi pravil.
Na splošno je postavljen kot orodje za morebitno sledenje anomalij in strojno učenje (nisem prepričan, da so te funkcije v povpraševanju), vendar je najbolj priljubljen primer njegove uporabe bolj običajen - opozarjanje.
Tako smo ga uporabili za obvestila. Nastavili smo opozorila Slack, ko je določen skuter prekinil povezavo, in enako smo storili za pametne polnilnike in pomembne komponente infrastrukture.
To je omogočilo hitro odzivanje na težave in prejemanje obvestil, da je vse spet po starem.
Enostaven primer: dodatna baterija za napajanje naše "škatlice" se je pokvarila ali iz neznanega razloga zmanjkalo energije; že z vgradnjo nove bi morali čez nekaj časa prejeti obvestilo, da je skuter spet deloval.
V Influx 2.0 je Kapacitor postal del DB
Kronograf
Videl sem veliko različnih UI rešitev za spremljanje, vendar lahko rečem, da se glede funkcionalnosti in UX nič ne more primerjati s Chronografom.
Začeli smo uporabljati sklad TICK, nenavadno, z Grafanom kot spletnim vmesnikom.
Ne bom opisoval njegove funkcionalnosti, vsi poznajo njene široke možnosti za nastavitev česar koli.
Vendar je Grafana še vedno povsem univerzalen inštrument, medtem ko je Chronograf namenjen predvsem uporabi z Influxom.
In seveda, zahvaljujoč temu si lahko Chronograf privošči veliko bolj pametno ali priročno funkcionalnost.
Morda je glavna priročnost dela s Chronografom ta, da si lahko ogledate notranjost svojega InfluxDB prek Explore.
Zdi se, da ima Grafana skoraj enako funkcionalnost, a v resnici je nastavitev nadzorne plošče v Chronografu možna z nekaj kliki miške (hkrati si ogledate tamkajšnjo vizualizacijo), medtem ko boste v Grafani slej ko prej vseeno imeli za urejanje konfiguracije JSON (seveda Chronograf omogoča nalaganje vaših ročno konfiguriranih dash in njihovo urejanje kot JSON, če je to potrebno – vendar se mi jih ni bilo treba dotakniti, potem ko sem jih ustvaril v uporabniškem vmesniku).
Kibana ima veliko bogatejše možnosti za ustvarjanje nadzornih plošč in kontrol zanje, vendar je UX za takšne operacije zelo kompleksen.
Za ustvarjanje priročne nadzorne plošče bo potrebno nekaj dobrega razumevanja. In čeprav je funkcionalnost nadzornih plošč Chronograf manjša, je njihova izdelava in prilagajanje veliko preprostejša.
Same armaturne plošče se, razen prijetnega vizualnega stila, pravzaprav ne razlikujejo od armaturnih plošč v Grafani ali Kibani:
Okno poizvedbe je videti takole:
Med drugim je pomembno omeniti, da vam lahko kronograf včasih samodejno pomaga pri pisanju poizvedbe ali izbiri pravilne funkcije združevanja, kot je povprečje, če poznate vrste polj v bazi podatkov InfluxDB.
In seveda, Chronograf je čim bolj priročen za ogled dnevnikov. Videti je takole:
Dnevniki Influx so privzeto prilagojeni za uporabo syslog in imajo zato pomemben parameter - resnost.
Graf na vrhu je še posebej uporaben, na njem lahko vidite napake, ki se pojavljajo, barva pa takoj jasno pokaže, če je resnost večja.
Nekajkrat smo na ta način ujeli pomembne hrošče, šli smo pogledat dnevnike za zadnji teden in videli rdečo konico.
Seveda bi bilo idealno nastaviti opozorila za takšne napake, saj smo za to že imeli vse.
To smo za nekaj časa celo vklopili, a se je v procesu priprave pilota izkazalo, da dobivamo kar nekaj napak (tudi sistemskih, kot je nedosegljivost omrežja LTE), ki so "spamile" tudi Slack kanal. veliko, brez povzročanja kakršnih koli težav Velika korist.
Pravilna rešitev bi bila obravnavati večino tovrstnih napak, jim prilagoditi resnost in šele nato omogočiti opozarjanje.
Na ta način bi bile v Slacku objavljene le nove ali pomembne napake. Enostavno ni bilo dovolj časa za takšno postavitev glede na tesne roke.
Preverjanje pristnosti
Prav tako je treba omeniti, da Chronograf podpira OAuth in OIDC kot avtentikacijo.
To je zelo priročno, saj vam omogoča, da ga enostavno priključite na svoj strežnik in ustvarite popolno enotno prijavo.
V našem primeru je bil strežnik — uporabljen je bil za povezovanje s spremljanjem, vendar je bil isti strežnik uporabljen tudi za preverjanje pristnosti skuterjev in zahtev za zaledje.
"Admin"
Zadnja komponenta, ki jo bom opisal, je naša samonapisana »skrbniška plošča« v Vue.
V bistvu je to le samostojna storitev, ki hkrati prikazuje podatke o skuterju iz naših lastnih podatkovnih baz, mikrostoritev in podatkov o meritvah iz InfluxDB.
Poleg tega so bile tja premaknjene številne administrativne funkcije, na primer ponovni zagon v sili ali oddaljeno odpiranje ključavnice za skupino za podporo.
Tam so bili tudi zemljevidi. Omenil sem že, da smo začeli z Grafano namesto s Chronografom - ker so za Grafano na voljo zemljevidi v obliki vtičnikov, na katerih lahko pregledujemo koordinate skirojev. Na žalost so zmožnosti widgetov zemljevidov za Grafana zelo omejene in posledično je bilo veliko lažje napisati svojo spletno aplikacijo z zemljevidi v nekaj dneh, da ne le trenutno vidite koordinate, ampak tudi prikažete pot, ki jo prevozi skuter, možnost filtriranja podatkov na zemljevidu itd. (vse tiste funkcije, ki jih nismo mogli konfigurirati na preprosti nadzorni plošči).
Ena od že omenjenih prednosti Influxa je možnost enostavnega ustvarjanja lastnih metrik.
To omogoča uporabo v najrazličnejših scenarijih.
Tam smo poskušali zabeležiti vse uporabne informacije: napolnjenost baterije, stanje zaklepanja, delovanje senzorja, bluetooth, GPS in številne druge zdravstvene preglede.
Vse to smo prikazali na skrbniški plošči.
Seveda je bilo za nas najpomembnejše merilo stanje delovanja skuterja - pravzaprav Influx to sam preveri in prikaže z "zelenimi lučmi" v razdelku Vozlišča.
To naredi funkcija — uporabili smo ga za razumevanje delovanja naše škatle in pošiljanje istih opozoril Slacku.
Mimogrede, skuterje smo poimenovali po imenih likov iz Simpsonovih - tako priročno jih je bilo razlikovati med seboj
In na splošno je bilo tako bolj zabavno. Neprestano so se slišali stavki, kot je "Fantje, Smithers je mrtev!".
Meritve nizov
Pomembno je, da vam InfluxDB omogoča shranjevanje ne le številskih vrednosti, kot je to v primeru Victoria Metrics.
Zdi se, da to ni tako pomembno - navsezadnje je mogoče poleg dnevnikov vse metrike shraniti v obliki številk (samo dodajte preslikavo za znana stanja - neke vrste enum)?
V našem primeru je obstajal vsaj en scenarij, kjer so bile metrike nizov zelo uporabne.
Zgodilo se je, da je bil dobavitelj naših »pametnih polnilcev« tretja oseba, nismo imeli nadzora nad razvojnim procesom in informacijami, ki bi jih ti polnilci lahko posredovali.
Posledično API za polnjenje še zdaleč ni bil idealen, a glavna težava je bila, da nismo mogli vedno razumeti njihovega stanja.
Tu je Influx priskočil na pomoč. Status niza, ki nam je prišel, smo preprosto zapisali v polje baze podatkov InfluxDB brez sprememb.
Nekaj časa so tja prišle samo vrednosti, kot sta »online« in »offline«, na podlagi katerih so bile informacije prikazane v naši skrbniški plošči, obvestila pa so bila poslana Slacku. Vendar so se na neki točki tam začele pojavljati tudi vrednosti, kot je "odklopljen".
Kot se je kasneje izkazalo, je bil ta status poslan enkrat po izgubi povezave, če polnilnik po določenem številu poskusov ni mogel vzpostaviti povezave s strežnikom.
Če bi torej uporabili samo fiksni nabor vrednosti, teh sprememb v vdelani programski opremi morda ne bi videli ob pravem času.
In na splošno nizovne metrike ponujajo veliko več možnosti za uporabo, vanje lahko zabeležite skoraj vse informacije. Čeprav morate seveda tudi to orodje uporabljati previdno.
Poleg običajnih meritev smo v InfluxDB beležili tudi informacije o lokaciji GPS. To je bilo izjemno uporabno za spremljanje lokacije skuterjev v naši skrbniški plošči.
Pravzaprav smo vedno vedeli, kje in kateri skuter je v trenutku, ko ga potrebujemo.
To nam je zelo koristilo, ko smo iskali skuter (glej zaključke na koncu).
Spremljanje infrastrukture
Poleg samih skuterjev smo morali spremljati tudi našo celotno (precej obsežno) infrastrukturo.
Zelo splošna arhitektura je izgledala nekako takole:
Če izpostavimo čisti nadzorni sklad, je videti takole:
V oblaku bi radi preverili:
- Baze podatkov
- keycloak
- Mikrostoritve
Ker se vse naše storitve v oblaku nahajajo v Kubernetesu, bi bilo lepo zbrati informacije o njegovem stanju.
Na srečo lahko Telegraf izven škatle zbere ogromno metrik o stanju gruče Kubernetes, Chronograf pa za to takoj ponudi čudovite nadzorne plošče.
Spremljali smo predvsem delovanje podov in porabo pomnilnika. V primeru padca, opozorila v Slacku.
Podom v Kubernetesu lahko sledite na dva načina: DaemonSet in Sidecar.
Obe metodi sta podrobno opisani .
Uporabili smo Telegraf Sidecar in poleg metrik zbirali dnevnike podov.
V našem primeru smo se morali poigrati s hlodi. Kljub dejstvu, da lahko Telegraf vleče dnevnike iz API-ja Docker, smo želeli imeti enotno zbirko dnevnikov z našimi končnimi napravami in za to konfigurirali sistemski dnevnik za vsebnike. Morda ta rešitev ni bila lepa, vendar ni bilo nobenih pritožb glede njenega dela in dnevniki so bili dobro prikazani v Chronografu.
Spremljanje monitorja???
Na koncu se je postavilo staro vprašanje spremljanja nadzornih sistemov, a za to na srečo ali žalost enostavno nismo imeli dovolj časa.
Čeprav lahko Telegraf enostavno pošlje lastne metrike ali zbira metrike iz baze podatkov InfluxDB za pošiljanje v isti Influx ali kam drugam.
Ugotovitve
Kakšne sklepe smo potegnili iz rezultatov pilota?
Kako lahko izvajate spremljanje?
Prvič, sklad TICK je v celoti izpolnil naša pričakovanja in nam dal celo več priložnosti, kot smo sprva pričakovali.
Prisotne so bile vse funkcionalnosti, ki smo jih potrebovali. Vse, kar smo naredili z njim, je delovalo brez težav.
Produktivnost
Glavna težava sklada TICK v brezplačni različici je pomanjkanje zmožnosti skaliranja. To za nas ni bil problem.
Nismo zbrali natančnih podatkov/številk o obremenitvi, vendar smo zbrali podatke za približno 30 skuterjev hkrati.
Vsak od njih je zbral več kot tri ducate meritev. Hkrati so bili zbrani dnevniki iz naprav. Zbiranje in pošiljanje podatkov je potekalo vsakih 10 sekund.
Pomembno je omeniti, da smo morali po tednu in pol pilota, ko je bila večina »otroških ranic« odpravljena in najpomembnejši problemi že odpravljeni, pogostost pošiljanja podatkov na strežnik zmanjšati na 30 sekund. To je postalo potrebno, ker je promet na naših LTE SIM karticah začel hitro izginjati.
Večino prometa so porabili dnevniki, sama metrika pa ga tudi z 10-sekundnim intervalom praktično ni zapravila.
Posledično smo čez nekaj časa popolnoma onemogočili zbiranje dnevnikov na napravah, saj so bile specifične težave očitne že brez stalnega zbiranja.
V nekaterih primerih, če je bil ogled dnevnikov še vedno potreben, smo se preprosto povezali preko WireGuard prek VPN.
Dodal bom tudi, da je bilo vsako ločeno okolje ločeno drug od drugega, zgoraj opisana obremenitev pa je bila pomembna samo za proizvodno okolje.
V razvojnem okolju smo ustvarili ločen primerek InfluxDB, ki je še naprej zbiral podatke vsakih 10 sekund in nismo naleteli na nobene težave z zmogljivostjo.
TICK - idealno za manjše do srednje velike projekte
Na podlagi teh informacij bi sklepal, da je sklad TICK idealen za relativno majhne projekte ali projekte, ki zagotovo ne pričakujejo visoke obremenitve.
Če nimate na tisoče podov ali na stotine strojev, bo celo ena instanca InfluxDB dobro prenesla obremenitev.
V nekaterih primerih boste morda zadovoljni z Influx Relay kot primitivno visoko razpoložljivostjo.
In seveda vam nihče ne preprečuje, da bi nastavili "navpično" skaliranje in preprosto dodelili različne strežnike za različne vrste metrik.
Če niste prepričani o pričakovani obremenitvi storitev spremljanja ali če je zagotovljeno, da imate/boste imeli zelo "težko" arhitekturo, ne priporočam uporabe brezplačne različice sklada TICK.
Seveda bi bila preprosta rešitev nakup - tukaj pa nekako ne morem komentirati, ker sam nisem seznanjen s tankostmi. Poleg tega, da je zelo drago in vsekakor ni primerno za mala podjetja.
V tem primeru danes priporočam zbiranje meritev prek Victoria Metrics in dnevnikov z uporabo Lokija.
Res je, spet bom pridržal, da so Loki/Grafana veliko manj priročni (zaradi večje vsestranskosti) kot že pripravljeni TICK, vendar so brezplačni.
Pomembno je,: vse tukaj opisane informacije veljajo za različico Influx 1.8, trenutno bo Influx 2.0 izdan.
Čeprav ga še nisem imel priložnosti preizkusiti v bojnih razmerah in je težko sklepati o izboljšavah, je vmesnik zagotovo postal še boljši, arhitektura je poenostavljena (brez kondenzatorja in kronografa),
pojavile so se predloge (»morilna funkcija« - ). A na žalost različica 2 trenutno nima tistega ključnega, zaradi česar smo izbrali prvo različico - ni zbiranja dnevnikov.
Ta funkcionalnost se bo pojavila tudi v Influxu 2.0, vendar rokov, niti približnih, nismo našli.
Kako ne narediti platform IoT (zdaj)
Na koncu, ko smo zagnali pilotni projekt, smo sami sestavili lasten polnopravni sklad IoT, v odsotnosti alternative, ki bi ustrezala našim standardom.
Vendar pa je pred kratkim na voljo v različici Beta — škoda, da je ni bilo zraven, ko smo začeli delati projekt.
S končnim rezultatom in platformo na osnovi Ansible + TICK + WireGuard, ki smo jo sestavili sami, smo povsem zadovoljni. Toda danes bi vam priporočal, da si Baleno podrobneje ogledate, preden poskušate sami zgraditi lastno IoT platformo.
Ker navsezadnje zmore večino tega, kar smo mi, OpenBalena pa je brezplačna in odprtokodna.
Že ve, kako ne samo pošiljati posodobitve, ampak je tudi VPN že vgrajen in prilagojen za uporabo v okolju IoT.
In prav pred kratkim so celo izdali svojega , ki se zlahka poveže z njihovim ekosistemom.
Hej, kaj pa pogrešani skuter?
Tako je skuter "Ralph" izginil brez sledu.
Takoj smo stekli pogledat zemljevid v naši »skrbniški plošči«, s podatki o meritvah GPS iz InfluxDB.
Zahvaljujoč podatkim spremljanja smo zlahka ugotovili, da je skuter prejšnji dan okoli 21. ure zapeljal s parkirišča, se peljal približno pol ure do nekega območja in bil do 00. ure zjutraj parkiran ob neki nemški hiši.
Po 5. uri zjutraj ni bilo prejetih nobenih podatkov o nadzoru - to je pomenilo, da je bila dodatna baterija popolnoma izpraznjena ali pa je napadalec končno ugotovil, kako odstraniti pametno strojno opremo s skuterja.
Kljub temu so na naslov, kjer se je skuter nahajal, vseeno poklicali policijo. Skuterja ni bilo.
Je pa to presenetilo tudi lastnika hiše, saj se je sinoči s tem skuterjem dejansko odpeljal domov iz službe.
Kot se je izkazalo, je eden od uslužbencev podpore prišel zgodaj zjutraj in prevzel skuter, ko je videl, da je njegova dodatna baterija popolnoma izpraznjena, in ga (peš) odpeljal na parkirišče. In dodatna baterija je odpovedala zaradi vlage.
Skuter smo ukradli sami sebi. Mimogrede, ne vem, kako in kdo je potem rešil težavo s policijskim primerom, vendar je nadzor deloval odlično ...
Vir: www.habr.com