Prije godinu dana pokrenuli smo pilot verziju promotivnog projekta za .
U početku se projekt zvao Road-To-Barcelona, kasnije je to postao Road-To-Berlin (dakle R2B na snimkama), a na kraju je nazvan xRide.
Glavna ideja projekta bila je sljedeća: umjesto centralizirane usluge iznajmljivanja automobila ili skutera (govorimo o skuterima ili električnim motociklima, a ne o skuterima/skuterima), htjeli smo napraviti platformu za decentralizirani najam. O poteškoćama na koje smo nailazili .
U početku se projekt fokusirao na automobile, no zbog rokova, iznimno duge komunikacije s proizvođačima i velikog broja sigurnosnih ograničenja, za pilot su odabrani električni skuteri.
Korisnik je na telefon instalirao iOS ili Android aplikaciju, prišao skuteru koji mu se svidio, nakon čega su telefon i skuter uspostavili peer-to-peer vezu, razmijenjen je ETH i korisnik je mogao započeti vožnju paljenjem skutera putem telefon. Na kraju putovanja također je bilo moguće platiti putovanje Ethereumom iz korisnikovog novčanika na telefonu.
Osim skutera, korisnik je u aplikaciji vidio i “pametne punjače” čijim posjetom može sam promijeniti trenutnu bateriju ako je slaba.
Ovako je općenito izgledao naš pilot, pokrenut u rujnu prošle godine u dva njemačka grada: Bonnu i Berlinu.
A onda, jednog dana, u Bonnu, rano ujutro, naš tim za podršku (koji se nalazi na licu mjesta radi održavanja skutera u ispravnom stanju) je upozoren: jedan od skutera je nestao bez traga.
Kako ga pronaći i vratiti?
U ovom ću članku govoriti o tome, ali prvo - o tome kako smo izgradili vlastitu IoT platformu i kako smo je pratili.
Što i zašto pratiti: skutere, infrastrukturu, punionice?
Dakle, što smo htjeli pratiti u našem projektu?
Prije svega, to su sami skuteri - sami električni skuteri su prilično skupi, ne možete pokrenuti takav projekt ako niste dovoljno pripremljeni; ako je moguće, želite prikupiti što više informacija o skuterima: o njihovoj lokaciji, razini napunjenosti itd.
Osim toga, želio bih pratiti stanje vlastite informatičke infrastrukture – baza podataka, servisa i svega što im je potrebno za rad. Također je bilo potrebno pratiti status “pametnih punjača” u slučaju da se pokvare ili isprazne pune baterije.
Skuteri
Što su bili naši skuteri i što smo željeli znati o njima?
Prva i najvažnija stvar su GPS koordinate, jer zahvaljujući njima možemo razumjeti gdje su i kamo se kreću.
Sljedeće je punjenje baterije zahvaljujući kojem možemo utvrditi da je punjenje skutera pri kraju i poslati sokovnik ili barem upozoriti korisnika.
Naravno, također je potrebno provjeriti što se događa s našim hardverskim komponentama:
- radi li bluetooth?
- radi li sam GPS modul?
- Također smo imali problem što je GPS znao poslati krive koordinate i zapeti, a to se moglo utvrditi samo dodatnim provjerama na skuteru,
i obavijestite podršku što je prije moguće kako bi riješili problem
- Također smo imali problem što je GPS znao poslati krive koordinate i zapeti, a to se moglo utvrditi samo dodatnim provjerama na skuteru,
I na kraju: provjere softvera, počevši od OS-a i procesora, opterećenja mreže i diska, do provjere vlastitih modula koji su specifičniji za nas (, ).
hardver
Što je bio naš "željezni" dio?
Uzimajući u obzir najkraći mogući vremenski okvir i potrebu za brzom izradom prototipa, odabrali smo najlakšu opciju za implementaciju i odabir komponenti - Raspberry Pi.
Uz sam Rpi, imali smo custom ploču (koju smo sami razvili i naručili iz Kine kako bismo ubrzali proces sklapanja konačnog rješenja) i set komponenti - relej (za paljenje/gašenje skutera), čitač napunjenosti baterije, modem, antene. Sve je to bilo kompaktno upakirano u posebnu “xRide kutiju”.
Također treba napomenuti da je cijelu kutiju napajao dodatni power bank, koji je pak bio napajan iz glavne baterije skutera.
To je omogućilo korištenje nadzora i uključivanje skutera čak i nakon završetka putovanja, jer je glavna baterija bila isključena odmah nakon okretanja ključa za paljenje u položaj "isključeno".
Lučki radnik? Običan Linux? i raspoređivanje
Vratimo se na monitoring, pa Malina - što imamo?
Jedna od prvih stvari koje smo htjeli upotrijebiti kako bismo ubrzali proces postavljanja, ažuriranja i isporuke komponenti na fizičke uređaje bio je Docker.
Nažalost, brzo je postalo jasno da Docker na RPi-ju, iako radi, ima dosta troškova, posebice u pogledu potrošnje energije.
Razlika u “nativnom” OS-u, iako ne toliko jaka, ipak je bila dovoljna da se pripazimo na mogućnost prebrzog gubitka napunjenosti.
Drugi razlog bila je jedna od naših partnerskih biblioteka na Node.js (sic!) - jedina komponenta sustava koja nije napisana u Go/C/C++.
Autori biblioteke nisu imali vremena dati radnu verziju ni na jednom od “materinjih” jezika.
Ne samo da sam čvor nije najelegantnije rješenje za uređaje niskih performansi, već je sama biblioteka bila vrlo gladna resursa.
Shvatili smo da bi nam, čak i da želimo, korištenje Dockera predstavljalo preveliki trošak. Izbor je napravljen u korist izvornog OS-a i rada izravno pod njim.
OS
Kao rezultat toga, ponovno smo odabrali najjednostavniju opciju kao OS i koristili Raspbian (Debian build for Pi).
Sav naš softver pišemo u Go-u, tako da smo također napisali modul glavnog hardverskog agenta u našem sustavu u Go-u.
On je odgovoran za rad s GPS-om, Bluetoothom, očitavanje napunjenosti, uključivanje skutera itd.
Rasporedi
Odmah se postavilo pitanje o potrebi implementacije mehanizma za isporuku ažuriranja na uređaje (OTA) - kako ažuriranja samog agenta/aplikacije, tako i ažuriranja samog OS-a/firmwarea (budući da nove verzije agenta mogu zahtijevati ažuriranja kernela ili komponente sustava, biblioteke itd.) .
Nakon dosta duge analize tržišta, pokazalo se da postoji dosta rješenja za isporuku ažuriranja na uređaj.
Od relativno jednostavnih uslužnih programa koji su uglavnom orijentirani na ažuriranje/dualno pokretanje kao što su swupd/SWUpdate/OSTree do potpunih platformi kao što su Mender i Balena.
Prije svega, odlučili smo da nas zanimaju end-to-end rješenja, pa je izbor odmah pao na platforme.
Vrlo je isključen zbog činjenice da zapravo koristi isti Docker unutar svog balenaEnginea.
Ali napominjem da smo unatoč tome na kraju stalno koristili njihov proizvod za flash firmware na SD karticama - jednostavan i izuzetno praktičan uslužni program za to.
Stoga je na kraju izbor pao na . Mender je cjelovita platforma za sklapanje, isporuku i instaliranje firmware-a.
Sve u svemu, platforma izgleda sjajno, ali trebalo nam je oko tjedan i pol samo da napravimo ispravnu verziju našeg firmware-a koristeći mender builder.
I što smo se više udubljivali u zamršenost njegove upotrebe, postajalo je jasnije da će nam trebati mnogo više vremena da bismo je u potpunosti postavili.
Nažalost, naši kratki rokovi značili su da smo bili prisiljeni napustiti korištenje Mendera i izabrati još jednostavniji.
Ansible
Najjednostavnije rješenje u našoj situaciji bilo je korištenje Ansiblea. Nekoliko udžbenika bilo je dovoljno za početak.
Njihova suština je bila da smo se jednostavno s hosta (CI server) spojili sshom na naše rasberries i distribuirali im update.
Na samom početku sve je bilo jednostavno – morali ste biti na istoj mreži s uređajima, točenje se vršilo putem Wi-Fi-ja.
U uredu je jednostavno bilo desetak testnih malina spojenih na istu mrežu, svaki uređaj je imao statičku IP adresu također navedenu u Ansible Inventory-u.
Ansible je bio taj koji je isporučio našeg nadzornog agenta do krajnjih uređaja
3G / LTE
Nažalost, ovaj slučaj upotrebe za Ansible mogao je raditi samo u razvojnom načinu prije nego što smo imali stvarne skutere.
Budući da skuteri, kao što razumijete, ne stoje povezani na jedan Wi-Fi usmjerivač, stalno čekajući ažuriranja preko mreže.
U stvarnosti, skuteri uopće ne mogu imati nikakvu vezu osim mobilnog 3G/LTE (pa čak ni tada ne cijelo vrijeme).
To odmah nameće mnoge probleme i ograničenja, poput niske brzine veze i nestabilne komunikacije.
Ali najvažnije je da se u 3G/LTE mreži ne možemo jednostavno osloniti na statički IP dodijeljen mreži.
To djelomično rješavaju neki dobavljači SIM kartica; postoje čak i posebne SIM kartice dizajnirane za IoT uređaje sa statičkim IP adresama. Ali mi nismo imali pristup takvim SIM karticama i nismo mogli koristiti IP adrese.
Naravno, bilo je ideja da napravimo neku vrstu registracije IP adresa aka service discovery negdje poput Consula, ali morali smo odustati od takvih ideja, jer se u našim testovima IP adresa znala prečesto mijenjati, što je dovodilo do velike nestabilnosti.
Iz tog razloga, najprikladnija upotreba za isporuku metrike ne bi bila korištenje modela povlačenja, gdje bismo išli na uređaje za potrebne metrike, već push, isporuka metrike s uređaja izravno na poslužitelj
VPN
Kao rješenje ovog problema odabrali smo upravo VPN .
Klijenti (skuteri) su se u startu sustava spojili na VPN server i mogli su se spojiti na njih. Ovaj je tunel korišten za isporuku ažuriranja.
U teoriji bi se isti tunel mogao koristiti za nadzor, ali je takva veza bila kompliciranija i manje pouzdana od jednostavnog guranja.
Resursi u oblaku
Na kraju, potrebno je pratiti naše cloud servise i baze podataka, budući da za njih koristimo Kubernetes, idealno kako bi implementacija nadzora u klasteru bila što jednostavnija. Idealno, koristeći , budući da ga za implementaciju koristimo u većini slučajeva. I, naravno, za praćenje oblaka morate koristiti ista rješenja kao i za same skutere.
S obzirom na to
Fuj, izgleda da smo sredili opis, idemo na kraju napraviti popis onoga što nam treba:
- Brzo rješenje, budući da je praćenje potrebno već tijekom procesa razvoja
- Volumen/količina – potrebno je mnogo metrika
- Potrebno je prikupljanje dnevnika
- Pouzdanost - podaci su ključni za uspjeh lansiranja
- Ne možete koristiti model povlačenja – treba vam potisak
- Trebamo objedinjeni nadzor ne samo hardvera, već i oblaka
Konačna slika izgledala je otprilike ovako
Odabir hrpe
Dakle, suočili smo se s pitanjem odabira nadzornog skupa.
Prije svega, tražili smo najcjelovitije sve-u-jednom rješenje koje bi istovremeno pokrilo sve naše zahtjeve, ali istovremeno bilo dovoljno fleksibilno da svoju upotrebu prilagodimo našim potrebama. Ipak, imali smo mnoga ograničenja koja su nam nametali hardver, arhitektura i rokovi.
Postoji veliki izbor rješenja za nadzor, počevši od potpunih sustava poput , ili i završavajući s gotovim rješenjima za upravljanje voznim parkom.
U početku se potonje činilo kao idealno rješenje za nas, ali neki nisu imali puni nadzor, drugi su imali ozbiljno ograničene mogućnosti besplatnih verzija, a treći jednostavno nisu pokrivali naše "želje" ili nisu bili dovoljno fleksibilni da bi odgovarali našim scenarijima. Neki su jednostavno zastarjeli.
Nakon analize niza sličnih rješenja, brzo smo došli do zaključka da bi bilo lakše i brže sami sastaviti sličnu hrpu. Da, bit će malo kompliciranije od postavljanja potpuno gotove platforme za upravljanje voznim parkom, ali nećemo morati raditi kompromise.
Gotovo sigurno, u svom ogromnom obilju rješenja, već postoji neko gotovo koje bi nam u potpunosti odgovaralo, ali u našem slučaju bilo je mnogo brže sami sastaviti određeni stog i prilagoditi ga “za sebe” nego testiranje gotovih proizvoda.
Uz sve to, nismo težili sami sastaviti cijelu platformu za nadzor, već smo tražili najfunkcionalnije „gotove“ stekove, samo s mogućnošću fleksibilnog konfiguriranja.
(B)ELK?
Prvo rješenje koje je zapravo razmatrano bio je dobro poznati ELK stack.
Zapravo bi se trebao zvati BELK, jer od Beatsa sve počinje -
Naravno, ELK je jedno od najpoznatijih i najmoćnijih rješenja u području monitoringa, a još više u prikupljanju i obradi logova.
Namjeravali smo da se ELK koristi za prikupljanje dnevnika, kao i za dugoročnu pohranu metrike dobivene od Prometheusa.
Za vizualizaciju možete koristiti Grafan.
Zapravo, novi ELK stack može neovisno prikupljati metrike (metricbeat), a Kibana ih također može prikazati.
Ipak, ELK je u početku izrastao iz zapisa i do sada funkcionalnost metrike ima niz ozbiljnih nedostataka:
- Znatno sporiji od Prometeja
- Integrira se na mnogo manje mjesta od Prometeja
- Teško je postaviti upozorenja za njih
- Mjerni podaci zauzimaju puno prostora
- Postavljanje nadzornih ploča s metrikom u Kibanu puno je kompliciranije nego u Grafanu
Općenito, metrika u ELK-u je teška i još nije tako prikladna kao u drugim rješenjima, kojih sada ima mnogo više od samo Prometheusa: TSDB, Victoria Metrics, Cortex itd., itd. Naravno, stvarno bih želio odmah imati punopravno sve-u-jednom rješenje, ali u slučaju metricbeata bilo je previše kompromisa.
I sam ELK stack ima nekoliko teških trenutaka:
- Teško je, ponekad čak i vrlo teško ako prikupite prilično veliku količinu podataka
- Morate ga "znati skuhati" - morate ga mjeriti, ali to nije trivijalno za napraviti
- Ogoljena besplatna verzija - besplatna verzija nema normalno upozorenje, a u trenutku odabira nije bilo provjere autentičnosti
Moram reći da je nedavno zadnja točka postala bolja i dodatno (uključujući autentifikaciju) počeo se mijenjati i sam model određivanja cijena.
Ali u vrijeme kada smo namjeravali implementirati ovo rješenje, nije bilo nikakvog upozorenja.
Možda smo mogli pokušati izgraditi nešto koristeći ElastAlert ili druga rješenja zajednice, ali smo ipak odlučili razmotriti druge alternative.
Loki - Grafana - Prometej
Trenutačno bi dobro rješenje moglo biti izgraditi skup za praćenje koji se temelji isključivo na Prometheusu kao pružatelju metrike, Lokiju za zapise, a za vizualizaciju možete koristiti istu Grafanu.
Nažalost, u trenutku početka prodajnog pilot projekta (rujan-listopad 19.), Loki je još uvijek bio u beta verziji 0.3-0.4, te se u trenutku početka razvoja nije mogao smatrati produkcijskim rješenjem uopće.
Još nemam iskustva u stvarnom korištenju Lokija u ozbiljnim projektima, ali mogu reći da Promtail (agent za prikupljanje logova) radi odlično i za bare-metal i za podove u kubernetesu.
TICK
Možda najvrijednija (jedina?) potpuno opremljena alternativa ELK stacku sada se može nazvati samo TICK stackom - Telegraf, InfluxDB, Chronograf, Kapacitor.
U nastavku ću detaljnije opisati sve komponente, ali opća ideja je sljedeća:
- Telegraf - agent za prikupljanje metrike
- InfluxDB - metrička baza podataka
- Kapacitor - metrički procesor u stvarnom vremenu za upozoravanje
- Chronograf - web panel za vizualizaciju
Za InfluxDB, Kapacitor i Chronograf postoje službene karte kormila koje smo koristili za njihovu implementaciju.
Treba napomenuti da su u posljednjoj verziji Influxa 2.0 (beta), Kapacitor i Chronograf postali dio InfluxDB-a i više ne postoje zasebno
telegraf
je vrlo lagan agent za prikupljanje metrike na stroju stanja.
Može pratiti ogromnu količinu svega, od na
poslužitelja .
Ima brojne cool prednosti:
- Brzo i lagano (napisano u Go)
- Jede minimalnu količinu resursa
- Push metrika prema zadanim postavkama
- Prikuplja sve potrebne metrike
- Mjerni podaci sustava bez ikakvih postavki
- Hardverske metrike kao što su informacije sa senzora
- Vrlo je jednostavno dodati vlastite metrike
- Mnoštvo dodataka izvan kutije
- Skuplja trupce
Budući da su nam push metrike bile neophodne, sve druge prednosti bile su više nego ugodni dodaci.
Prikupljanje dnevnika od strane samog agenta također je vrlo zgodno, budući da nema potrebe za povezivanjem dodatnih uslužnih programa za evidentiranje dnevnika.
Influx nudi najprikladnije iskustvo za rad sa zapisima ako koristite .
Telegraf je općenito odličan agent za prikupljanje metrike, čak i ako ne koristite ostatak ICK stoga.
Mnogi ljudi ga križaju s ELK-om i raznim drugim bazama podataka vremenskih nizova radi praktičnosti, budući da može pisati metrike gotovo bilo gdje.
InfluxDB
InfluxDB je glavna jezgra TICK skupa, naime baza podataka vremenskih serija za metriku.
Osim metrike, Influx također može pohranjivati zapise, iako su, u biti, zapisnici za njega ista metrika, samo umjesto uobičajenih numeričkih pokazatelja, glavnu funkciju obavlja redak teksta dnevnika.
InfluxDB je također napisan u Go-u i čini se da radi mnogo brže u usporedbi s ELK-om na našem (ne najsnažnijem) klasteru.
Jedna od zgodnih prednosti Influxa također bi uključivala vrlo zgodan i bogat API za upite podataka, koji smo vrlo aktivno koristili.
Nedostaci - $$$ ili skaliranje?
TICK stack ima samo jedan nedostatak koji smo otkrili - njega draga. Još više.
Što plaćena verzija ima, a besplatna nema?
Koliko smo uspjeli shvatiti, jedina razlika između plaćene inačice TICK stacka i besplatne je u mogućnostima skaliranja.
Naime, možete podići klaster s Visokom dostupnošću samo u .
Ako želite potpuni HA, morate ili platiti ili koristiti štake. Postoji nekoliko rješenja zajednice - na primjer izgleda kao kompetentno rješenje, ali je napisano da nije prikladno za proizvodnju, kao i
- jednostavno rješenje s pumpanjem podataka kroz NATS (također će se morati skalirati, ali to se može riješiti).
Šteta, ali oba su izgleda napuštena - nema svježih komitova, pretpostavljam da je problem u skorom očekivanom izlasku nove verzije Influxa 2.0, u kojoj će mnogo toga biti drugačije (nema informacija o skaliranje u njemu još).
Službeno postoji besplatna verzija - zapravo, ovo je primitivni HA, ali samo kroz balansiranje,
jer će svi podaci biti upisani u sve InfluxDB instance iza balansera opterećenja.
Ima neke poput potencijalnih problema s prepisivanjem točaka i potrebe za stvaranjem baza za metriku unaprijed
(što se događa automatski tijekom normalnog rada s InfluxDB-om).
Osim toga , to znači dodatno opterećenje za duplicirane metrike (i obradu i pohranu) koje vam možda neće trebati, ali ne postoji način da ih odvojite.
Victoria Metrics?
Kao rezultat toga, unatoč činjenici da smo bili potpuno zadovoljni TICK stogom u svemu osim plaćenog skaliranja, odlučili smo vidjeti postoje li besplatna rješenja koja bi mogla zamijeniti InfluxDB bazu podataka, dok smo ostavili preostale T_CK komponente.
Postoji mnogo baza podataka vremenskih serija, ali ona koja najviše obećava je Victoria Metrics, ima niz prednosti:
- Brzo i jednostavno, barem prema rezultatima
- Postoji verzija klastera, o kojoj sada postoje čak i dobre kritike
- Ona može krhotinu
- Podržava InfluxDB protokol
Nismo namjeravali izgraditi potpuno prilagođeni stog temeljen na Victoriji i glavna nada bila je da bismo je mogli koristiti kao zamjenu za InfluxDB.
Nažalost, to nije moguće, unatoč činjenici da je InfluxDB protokol podržan, radi samo za snimanje metrike - samo je Prometheus API dostupan "vani", što znači da neće biti moguće postaviti Chronograf na njega.
Štoviše, za metriku su podržane samo numeričke vrijednosti (koristili smo vrijednosti niza za prilagođenu metriku - više o tome u odjeljku ).
Očito, iz istog razloga, VM ne može pohranjivati zapise kao što to čini Influx.
Također, valja napomenuti da u vrijeme traženja optimalnog rješenja Victoria Metrics još nije bila toliko popularna, dokumentacija je bila puno manja, a funkcionalnost slabija
(Ne sjećam se detaljnog opisa verzije klastera i dijeljenja).
Izbor baze
Kao rezultat toga, odlučeno je da ćemo se za pilot i dalje ograničiti na jedan InfluxDB čvor.
Bilo je nekoliko glavnih razloga za ovaj izbor:
- Jako nam se svidjela cjelokupna funkcionalnost TICK stacka
- Već smo ga uspjeli implementirati i odlično je funkcionirao
- Rokovi su istjecali i nije ostalo puno vremena za testiranje drugih opcija.
- Nismo očekivali ovoliki teret
Nismo imali mnogo skutera za prvu fazu pilota, a testiranje tijekom razvoja nije otkrilo probleme s performansama.
Stoga smo odlučili da će nam za ovaj projekt biti dovoljan jedan Influx čvor bez potrebe za skaliranjem (vidi zaključke na kraju).
Odlučili smo se za hrpu i bazu - sada o preostalim komponentama TICK hrpe.
kondenzator
Kapacitor je dio TICK stacka, servisa koji može pratiti metrike koje ulaze u bazu podataka u stvarnom vremenu i izvoditi različite radnje na temelju pravila.
Općenito, pozicioniran je kao alat za potencijalno praćenje anomalija i strojno učenje (nisam siguran da su te funkcije tražene), ali najpopularniji slučaj njegove upotrebe je uobičajeniji - uzbunjivanje.
Tako smo ga koristili za obavijesti. Postavili smo Slack upozorenja kada je određeni skuter isključen, a isto je učinjeno za pametne punjače i važne infrastrukturne komponente.
To je omogućilo brzo reagiranje na probleme, kao i primanje obavijesti da se sve vratilo u normalu.
Jednostavan primjer: dodatna baterija za napajanje naše “kutije” se pokvarila ili iz nekog razloga ostala bez struje, jednostavnom ugradnjom nove, nakon nekog vremena trebamo dobiti obavijest da je skuter vraćen u funkciju.
U Influxu 2.0 Kapacitor je postao dio DB-a
Kronograf
Vidio sam mnogo različitih UI rješenja za praćenje, ali mogu reći da se u pogledu funkcionalnosti i UX-a ništa ne može usporediti s Chronografom.
Počeli smo koristiti TICK stack, čudno, s Grafanom kao web sučeljem.
Neću opisivati njegovu funkcionalnost, svi znaju njegove široke mogućnosti za postavljanje bilo čega.
Međutim, Grafana je još uvijek potpuno univerzalan instrument, dok je Chronograf uglavnom namijenjen za korištenje s Influxom.
I naravno, zahvaljujući tome, Chronograf si može priuštiti mnogo pametniju ili praktičniju funkcionalnost.
Možda je glavna pogodnost rada s Chronografom to što možete vidjeti unutrašnjost svog InfluxDB-a putem Istraživanja.
Čini se da Grafana ima gotovo identičnu funkcionalnost, no u stvarnosti je postavljanje nadzorne ploče u Chronografu moguće obaviti s nekoliko klikova mišem (istovremeno gledajući tamošnju vizualizaciju), dok ćete u Grafani ipak prije ili kasnije imati za uređivanje JSON konfiguracije (naravno, Chronograf dopušta učitavanje vaših ručno konfiguriranih dasha i njihovo uređivanje kao JSON ako je potrebno - ali nikada ih nisam morao dirati nakon što sam ih izradio na korisničkom sučelju).
Kibana ima puno bogatije mogućnosti za kreiranje nadzornih ploča i kontrola za njih, ali je UX za takve operacije vrlo složen.
Za izradu prikladne nadzorne ploče trebat će malo dobrog razumijevanja. I iako je funkcionalnost Chronograf nadzornih ploča manja, njihova izrada i prilagodba puno je jednostavnija.
Same ploče, osim ugodnog vizualnog stila, zapravo se ne razlikuju od ploča u Grafani ili Kibani:
Ovako izgleda prozor upita:
Važno je napomenuti, između ostalog, da vam, poznavajući vrste polja u bazi podataka InfluxDB, sam kronograf ponekad automatski može pomoći pri pisanju upita ili odabiru ispravne funkcije agregacije kao što je srednja vrijednost.
I naravno, Chronograf je što praktičniji za pregledavanje dnevnika. Ovako izgleda:
Prema zadanim postavkama, Influx dnevnici su prilagođeni za korištenje syslog-a i stoga imaju važan parametar - ozbiljnost.
Posebno je koristan grafikon na vrhu; na njemu možete vidjeti pogreške koje se pojavljuju, a boja odmah jasno pokazuje ako je ozbiljnost veća.
Nekoliko puta smo uhvatili važne bugove na ovaj način, otišli smo pogledati dnevnike za prošli tjedan i vidjeli crveni šiljak.
Naravno, idealno bi bilo postaviti upozorenja za takve greške, jer smo već imali sve za to.
To smo čak i uključili neko vrijeme, no u procesu pripreme pilota pokazalo se da dobivamo dosta grešaka (uključujući sistemske poput nedostupnosti LTE mreže), koje su "spamile" i Slack kanal mnogo, bez ikakvih problema. velika korist.
Ispravno rješenje bilo bi obraditi većinu ovih vrsta pogrešaka, prilagoditi im ozbiljnost i tek onda omogućiti upozoravanje.
Na taj način bi se samo nove ili važne pogreške objavljivale u Slacku. Jednostavno nije bilo dovoljno vremena za takvu postavu s obzirom na kratke rokove.
ovjera
Također je vrijedno spomenuti da Chronograf podržava OAuth i OIDC kao autentifikaciju.
Ovo je vrlo zgodno jer vam omogućuje jednostavno pričvršćivanje na vaš poslužitelj i stvaranje punopravnog SSO-a.
U našem slučaju, poslužitelj je bio — korišten je za povezivanje s nadzorom, ali isti je poslužitelj korišten i za autentifikaciju skutera i zahtjeva prema pozadini.
“Administrator”
Posljednja komponenta koju ću opisati je naš vlastiti "admin panel" u Vue.
U osnovi to je samo samostalna usluga koja istovremeno prikazuje informacije o skuteru iz naših vlastitih baza podataka, mikroservisa i metričkih podataka iz InfluxDB-a.
Osim toga, tamo su premještene mnoge administrativne funkcije, poput hitnog ponovnog pokretanja ili daljinskog otvaranja brave za tim za podršku.
Bile su tu i karte. Već sam spomenuo da smo krenuli s Grafanom umjesto Chronografom - jer za Grafanu su dostupne karte u obliku dodataka, na kojima smo mogli vidjeti koordinate skutera. Nažalost, mogućnosti widgeta karte za Grafanu vrlo su ograničene, pa je kao rezultat toga bilo puno lakše napisati vlastitu web aplikaciju s kartama u nekoliko dana, kako biste ne samo vidjeli koordinate u trenutku, već i prikazali rutu kojom ide skuter, moći filtrirati podatke na karti itd. (sve te funkcionalnosti koje nismo mogli konfigurirati na jednostavnoj nadzornoj ploči).
Jedna od već spomenutih prednosti Influxa je mogućnost jednostavne izrade vlastitih metrika.
To mu omogućuje da se koristi za veliki izbor scenarija.
Pokušali smo tamo zabilježiti sve korisne informacije: napunjenost baterije, status zaključavanja, rad senzora, bluetooth, GPS i mnoge druge provjere zdravlja.
Sve smo to prikazali na admin panelu.
Naravno, najvažniji kriterij za nas je bilo radno stanje skutera - zapravo, Influx to sam provjerava i pokazuje "zelenim svjetlima" u odjeljku Čvorovi.
To čini funkcija — upotrijebili smo ga za razumijevanje performansi naše kutije i slanje istih upozorenja Slacku.
Usput, skutere smo nazvali po imenima likova iz Simpsonovih - bilo je tako zgodno razlikovati ih jedne od drugih
I općenito je ovako bilo zabavnije. Stalno su se čule fraze poput "Dečki, Smithers je mrtav!".
String metrika
Važno je da vam InfluxDB omogućuje pohranjivanje ne samo numeričkih vrijednosti, kao što je slučaj s Victoria Metrics.
Čini se da to i nije toliko važno - nakon svega, osim dnevnika, bilo koja metrika može biti pohranjena u obliku brojeva (samo dodajte mapiranje za poznata stanja - neka vrsta enuma)?
U našem slučaju, postojao je barem jedan scenarij u kojem su metrike nizova bile vrlo korisne.
Slučajno se dogodilo da je dobavljač naših “pametnih punjača” treća strana, nismo imali kontrolu nad razvojnim procesom i informacijama koje ti punjači mogu dostaviti.
Kao rezultat toga, API za punjenje bio je daleko od idealnog, ali glavni je problem bio što nismo uvijek mogli razumjeti njihovo stanje.
Tu je Influx priskočio u pomoć. Jednostavno smo upisali status niza koji nam je došao u polje baze podataka InfluxDB bez promjena.
Neko vrijeme tamo su stizale samo vrijednosti poput "online" i "offline", na temelju kojih su se informacije prikazivale u našem administratorskom panelu, a obavijesti su slane Slacku. Međutim, u nekom su se trenutku tamo počele pojavljivati vrijednosti poput "isključeno".
Kako se kasnije pokazalo, ovaj status je poslan jednom nakon gubitka veze, ako punjač nije mogao uspostaviti vezu sa serverom nakon određenog broja pokušaja.
Dakle, ako koristimo samo fiksni skup vrijednosti, možda nećemo vidjeti ove promjene u firmveru u pravo vrijeme.
I općenito, string metrika pruža mnogo više mogućnosti za korištenje, u njih možete zabilježiti gotovo sve informacije. Iako, naravno, također morate pažljivo koristiti ovaj alat.
Uz uobičajenu metriku, također smo zabilježili informacije o GPS lokaciji u InfluxDB. Ovo je bilo nevjerojatno korisno za praćenje lokacije skutera u našoj administratorskoj ploči.
Zapravo, uvijek smo znali gdje i koji je skuter u trenutku kada nam treba.
Ovo nam je bilo vrlo korisno kada smo tražili skuter (vidi zaključke na kraju).
Praćenje infrastrukture
Osim samih skutera, morali smo pratiti i cjelokupnu našu (prilično opsežnu) infrastrukturu.
Vrlo općenita arhitektura izgledala je otprilike ovako:
Ako istaknemo čisti skup praćenja, on izgleda ovako:
Ono što želimo provjeriti u oblaku je:
- baze podataka
- ogrtač za ključeve
- Mikroservisi
Budući da se sve naše usluge u oblaku nalaze u Kubernetesu, bilo bi lijepo prikupiti informacije o njegovom stanju.
Srećom, Telegraf izvan kutije može prikupiti ogroman broj metrika o stanju Kubernetes klastera, a Chronograf odmah nudi prekrasne nadzorne ploče za to.
Uglavnom smo pratili performanse podova i potrošnju memorije. U slučaju pada, upozorenja u Slacku.
Postoje dva načina za praćenje podova u Kubernetesu: DaemonSet i Sidecar.
Obje metode su detaljno opisane .
Koristili smo Telegraf Sidecar i, osim metrike, prikupljali pod logove.
U našem slučaju, morali smo petljati s trupcima. Unatoč činjenici da Telegraf može povući zapise iz Docker API-ja, željeli smo imati jedinstvenu zbirku zapisa s našim krajnjim uređajima i za to smo konfigurirali syslog za spremnike. Možda ovo rješenje nije bilo lijepo, ali nije bilo pritužbi na njegov rad i zapisi su dobro prikazani u Chronografu.
Praćenje monitora???
Na kraju se postavilo staro pitanje nadzora nadzornih sustava, ali za to, na sreću ili nažalost, jednostavno nismo imali dovoljno vremena.
Iako Telegraf može lako poslati vlastitu metriku ili prikupiti metriku iz InfluxDB baze podataka za slanje ili istom Influxu ili negdje drugdje.
Zaključci
Koje smo zaključke izvukli iz rezultata pilota?
Kako možete vršiti praćenje?
Prije svega, TICK stack je u potpunosti ispunio naša očekivanja i dao nam je čak više mogućnosti nego što smo u početku očekivali.
Sve funkcionalnosti koje su nam trebale bile su prisutne. Sve što smo radili s njim radilo je bez problema.
Performanse
Glavni problem s TICK stackom u besplatnoj verziji je nedostatak mogućnosti skaliranja. To nam nije bio problem.
Nismo prikupili točne podatke/brojke o opterećenju, ali prikupili smo podatke za oko 30 skutera odjednom.
Svaki od njih prikupio je više od tri desetke metrika. Istovremeno su prikupljeni dnevnici s uređaja. Prikupljanje i slanje podataka događalo se svakih 10 sekundi.
Važno je napomenuti da smo nakon tjedan i pol pilota, kada je glavnina "problema iz djetinjstva" ispravljena, a najvažniji problemi već riješeni, morali smanjiti učestalost slanja podataka na poslužitelj na 30 sekundi. Ovo je postalo neophodno jer je promet na našim LTE SIM karticama počeo brzo nestajati.
Najveći dio prometa trošili su dnevnici, a sama metrika, čak i s intervalom od 10 sekundi, praktički ga nije trošila.
Kao rezultat toga, nakon nekog vremena potpuno smo onemogućili prikupljanje logova na uređajima, jer su specifični problemi već bili očiti i bez stalnog prikupljanja.
U nekim slučajevima, ako je pregledavanje zapisa bilo potrebno, jednostavno smo se povezali putem WireGuarda putem VPN-a.
Također ću dodati da je svako zasebno okruženje bilo odvojeno jedno od drugog, a gore opisano opterećenje bilo je relevantno samo za proizvodno okruženje.
U razvojnom okruženju podigli smo zasebnu instancu InfluxDB koja je nastavila prikupljati podatke svakih 10 sekundi i nismo naišli na probleme s izvedbom.
TICK - idealan za male i srednje projekte
Na temelju ovih informacija, zaključio bih da je TICK stack idealan za relativno male projekte ili projekte koji definitivno ne očekuju nikakav HighLoad.
Ako nemate tisuće podova ili stotine strojeva, čak će i jedna InfluxDB instanca dobro podnijeti opterećenje.
U nekim slučajevima možete biti zadovoljni Influx Relayom kao primitivnim rješenjem visoke dostupnosti.
I, naravno, nitko vas ne sprječava da postavite "vertikalno" skaliranje i jednostavno dodjeljujete različite poslužitelje za različite vrste metrika.
Ako niste sigurni o očekivanom opterećenju usluga nadzora ili vam je zajamčeno da imate/ćete imati vrlo "tešku" arhitekturu, ne bih preporučio korištenje besplatne verzije TICK stacka.
Naravno, jednostavno rješenje bila bi kupnja - ali ovdje ne mogu komentirati nekako, jer ni sam nisam upoznat sa suptilnostima. Osim što je vrlo skup i definitivno nije pogodan za male tvrtke.
U ovom slučaju, danas bih preporučio prikupljanje metrike putem Victoria Metrics i zapisnika pomoću Lokija.
Istina, opet ću napraviti rezervu da su Loki/Grafana mnogo manje praktični (zbog svoje veće svestranosti) od gotovog TICK-a, ali su besplatni.
To je važno: sve ovdje opisane informacije relevantne su za verziju Influx 1.8, trenutno će Influx 2.0 biti objavljen.
Iako ga nisam imao priliku isprobati u borbenim uvjetima i teško je donositi zaključke o poboljšanjima, sučelje je definitivno postalo još bolje, arhitektura je pojednostavljena (bez kondenzatora i kronografa),
pojavili su se predlošci ("ubojita značajka" - ). No, nažalost, u ovom trenutku verzija 2 nema ono ključno zbog čega smo odabrali prvu verziju - nema prikupljanja dnevnika.
Ova će se funkcionalnost pojaviti iu Influxu 2.0, ali nismo uspjeli pronaći rokove, čak ni okvirne.
Kako ne napraviti IoT platforme (sada)
Na kraju, nakon što smo pokrenuli pilot, sami smo sastavili vlastiti punopravni IoT stog, u nedostatku alternative koja bi odgovarala našim standardima.
Međutim, odnedavno je dostupan u Beta verziji — Šteta što nije bila tu kad smo krenuli u izradu projekta.
Potpuno smo zadovoljni krajnjim rezultatom i platformom baziranom na Ansible + TICK + WireGuard koju smo sami sastavili. Ali danas bih preporučio da pomnije pogledate Balenu prije nego što sami pokušate izgraditi vlastitu IoT platformu.
Jer u konačnici može učiniti većinu onoga što smo mi učinili, a OpenBalena je besplatna i otvorenog koda.
Već zna kako ne samo slati ažuriranja, već je i VPN već ugrađen i prilagođen za korištenje u IoT okruženju.
A nedavno su čak i objavili svoje , koji se lako povezuje s njihovim ekosustavom.
Hej, što je s nestalim skuterom?
Tako je skuter, "Ralph", nestao bez traga.
Odmah smo potrčali pogledati kartu u našoj "admin ploči", s GPS metričkim podacima iz InfluxDB-a.
Zahvaljujući podacima praćenja lako smo utvrdili da je skuter prošlog dana oko 21 sat krenuo s parkirališta, vozio se oko pola sata do nekog područja i do 00 ujutro bio parkiran pokraj neke njemačke kuće.
Nakon 5 ujutro nisu primljeni nikakvi podaci o praćenju - to je značilo ili da je dodatna baterija potpuno ispražnjena ili da je napadač konačno smislio kako ukloniti pametni hardver sa skutera.
Unatoč tome, policija je ipak pozvana na adresu na kojoj se nalazio skuter. Skutera nije bilo.
No, i vlasnika kuće to je iznenadilo, jer se on sinoć iz ureda kući dovezao ovim skuterom.
Kako se doznaje, jedan od djelatnika podrške stigao je rano ujutro i preuzeo skuter, vidjevši da mu je dodatna baterija potpuno ispražnjena te ga (pješice) odnio na parkiralište. I dodatna baterija otkazala zbog vlage.
Sami smo sebi ukrali skuter. Inače, ne znam kako je i tko je tada riješio problem s policijskim slučajem, ali nadzor je savršeno funkcionirao...
Izvor: www.habr.com