Pred rokom sme spustili pilotnú verziu propagačného projektu pre .
Spočiatku sa projekt nazýval Road-To-Barcelona, neskôr sa stal Road-To-Berlin (preto R2B na snímkach obrazovky) a nakoniec sa nazýval xRide.
Hlavnou myšlienkou projektu bolo toto: namiesto centralizovanej požičovne áut alebo skútrov (hovoríme o skútroch alias elektrických motorkách, nie o kolobežkách/skútroch) sme chceli vytvoriť platformu pre decentralizovaný prenájom. O ťažkostiach, s ktorými sme sa stretli .
Spočiatku sa projekt zameriaval na autá, no kvôli termínom, extrémne dlhej komunikácii s výrobcami a obrovskému množstvu bezpečnostných obmedzení boli do pilotného projektu vybrané elektrické skútre.
Používateľ si do telefónu nainštaloval aplikáciu pre iOS alebo Android, priblížil sa ku kolobežke, ktorá sa mu páčila, potom telefón a kolobežka nadviazali peer-to-peer spojenie, vymenilo sa ETH a užívateľ mohol začať jazdu zapnutím kolobežky cez Telefón. Na konci cesty bolo tiež možné zaplatiť za cestu pomocou Etherea z peňaženky používateľa v telefóne.
Používateľ okrem kolobežiek videl v aplikácii aj „smart nabíjačky“, ktorých návštevou si používateľ mohol sám vymeniť aktuálnu batériu, ak bola slabá.
Takto vo všeobecnosti vyzeral náš pilotný projekt, ktorý bol spustený v septembri minulého roku v dvoch nemeckých mestách: Bonn a Berlín.
A potom, jedného dňa, v Bonne, skoro ráno, náš podporný tím (umiestnený na mieste, aby udržiaval skútre v prevádzkovom stave) bol upozornený: jeden zo skútrov zmizol bez stopy.
Ako ho nájsť a vrátiť?
V tomto článku o tom budem hovoriť, ale najprv o tom, ako sme vybudovali vlastnú platformu IoT a ako sme ju monitorovali.
Čo a prečo monitorovať: skútre, infraštruktúru, nabíjacie stanice?
Čo sme teda chceli v našom projekte sledovať?
V prvom rade sú to samotné kolobežky - samotné elektrokolobežky sú dosť drahé, takýto projekt nemôžete spustiť bez dostatočnej prípravy, ak je to možné, chcete o kolobežkách nazbierať čo najviac informácií: o ich umiestnení, úrovni nabitia. , atď.
Okrem toho by som chcel sledovať stav našej vlastnej IT infraštruktúry – databáz, služieb a všetkého, čo potrebujú k svojej práci. Taktiež bolo potrebné sledovať stav „inteligentných nabíjačiek“, ak by sa pokazili alebo sa im vybili plné batérie.
Kolobežky
Aké boli naše kolobežky a čo sme o nich chceli vedieť?
Prvou a najdôležitejšou vecou sú GPS súradnice, keďže vďaka nim vieme pochopiť, kde sa nachádzajú a kde sa pohybujú.
Nasleduje nabíjanie batérie, vďaka ktorému vieme určiť, že nabíjanie kolobežiek sa blíži ku koncu a poslať odšťavovač alebo aspoň varovať používateľa.
Samozrejme je tiež potrebné skontrolovať, čo sa deje s našimi hardvérovými komponentmi:
- funguje bluetooth?
- funguje samotný GPS modul?
- Problém sme mali aj s tým, že GPS mohlo poslať nesprávne súradnice a zaseknúť sa a to sa dalo zistiť až dodatočnými kontrolami na kolobežke,
a čo najskôr upozornite podporu, aby sa problém vyriešil
- Problém sme mali aj s tým, že GPS mohlo poslať nesprávne súradnice a zaseknúť sa a to sa dalo zistiť až dodatočnými kontrolami na kolobežke,
A nakoniec: kontroly softvéru, počnúc OS a procesorom, zaťažením siete a disku, končiac kontrolami vlastných modulov, ktoré sú pre nás špecifickejšie (, ).
technické vybavenie
Aká bola naša „železná“ časť?
S prihliadnutím na čo najkratší časový rámec a potrebu rýchleho prototypovania sme zvolili najjednoduchšiu možnosť implementácie a výberu komponentov – Raspberry Pi.
Okrem samotného Rpi sme mali dosku na mieru (ktorú sme sami vyvinuli a objednali z Číny, aby sme urýchlili proces montáže finálneho riešenia) a sadu komponentov - relé (na zapnutie/vypnutie kolobežky), čítačka nabíjania batérie, modem, antény. To všetko bolo kompaktne zabalené v špeciálnom „xRide boxe“.
Treba si tiež uvedomiť, že celý box bol napájaný prídavnou power bankou, ktorú zase napájala hlavná batéria kolobežky.
To umožnilo využiť monitorovanie a zapnúť kolobežku aj po skončení jazdy, keďže hlavná batéria bola vypnutá ihneď po otočení kľúča zapaľovania do polohy „vypnuté“.
Docker? Obyčajný Linux? a nasadenie
Vráťme sa k monitoringu, takže Malina – čo máme?
Jednou z prvých vecí, ktoré sme chceli použiť na urýchlenie procesu nasadzovania, aktualizácie a doručovania komponentov na fyzické zariadenia, bol Docker.
Bohužiaľ sa rýchlo ukázalo, že Docker na RPi, aj keď funguje, má veľa réžie, najmä pokiaľ ide o spotrebu energie.
Rozdiel pri použití „natívneho“ operačného systému, aj keď nie taký výrazný, bol stále dostatočný na to, aby sme si dávali pozor na možnosť príliš rýchlej straty náboja.
Druhým dôvodom bola jedna z našich partnerských knižníc na Node.js (sic!) – jedinom komponente systému, ktorý nebol napísaný v Go/C/C++.
Autori knižnice nestihli poskytnúť pracovnú verziu v žiadnom z „rodných“ jazykov.
Nielenže samotný uzol nie je najelegantnejším riešením pre zariadenia s nízkym výkonom, ale aj samotná knižnica bola veľmi náročná na zdroje.
Uvedomili sme si, že aj keby sme chceli, používanie Dockeru by bolo pre nás príliš náročné. Voľba bola urobená v prospech natívneho OS a práce priamo pod ním.
OS
V dôsledku toho sme si opäť vybrali najjednoduchšiu možnosť ako OS a použili sme Raspbian (Debian zostavenie pre Pi).
Všetok náš softvér píšeme v Go, takže sme napísali aj hlavný modul hardvérového agenta v našom systéme v Go.
Je to on, kto je zodpovedný za prácu s GPS, Bluetooth, čítanie nabitia, zapnutie kolobežky atď.
Nasadiť
Okamžite vyvstala otázka o potrebe implementovať mechanizmus na doručovanie aktualizácií do zariadení (OTA) – a to ako aktualizácie nášho agenta/aplikácie samotného, tak aj aktualizácie samotného OS/firmvéru (keďže nové verzie agenta môžu vyžadovať aktualizácie jadra alebo systémové komponenty, knižnice atď.) .
Po pomerne dlhej analýze trhu sa ukázalo, že riešení na dodávanie aktualizácií do zariadenia je pomerne veľa.
Od relatívne jednoduchých, väčšinou aktualizácií/dual-boot orientovaných utilít ako swupd/SWUpdate/OSTree až po plnohodnotné platformy ako Mender a Balena.
V prvom rade sme sa rozhodli, že nás zaujímajú end-to-end riešenia, takže voľba hneď padla na platformy.
Veľmi bol vylúčený z dôvodu, že v skutočnosti používa rovnaký Docker vo svojom balenaEngine.
Ale podotýkam, že napriek tomu sme ich produkt nakoniec používali neustále pre flash firmvér na SD kartách - na to jednoduchý a mimoriadne pohodlný nástroj.
Preto nakoniec padla voľba . Mender je kompletná platforma na zostavenie, dodanie a inštaláciu firmvéru.
Celkovo platforma vyzerá skvele, ale trvalo nám asi týždeň a pol, kým sme vytvorili správnu verziu nášho firmvéru pomocou nástroja na tvorbu menderov.
A čím viac sme sa ponorili do zložitosti jeho používania, tým viac bolo jasné, že na jeho plné nasadenie budeme potrebovať oveľa viac času, ako sme mali.
Bohužiaľ, naše krátke termíny znamenali, že sme boli nútení opustiť používanie Mender a zvoliť si ešte jednoduchší.
Ansible
Najjednoduchším riešením v našej situácii bolo použiť Ansible. Na začiatok stačilo pár zošitov.
Ich podstatou bolo, že sme sa jednoducho pripojili z hostiteľa (CI server) cez ssh k našim rasberries a distribuovali sme im aktualizácie.
Na samom začiatku bolo všetko jednoduché - museli ste byť v rovnakej sieti so zariadeniami, nalievanie prebiehalo cez Wi-Fi.
V kancelárii bolo jednoducho tucet testovacích malín pripojených k rovnakej sieti, každé zariadenie malo statickú IP adresu, ktorá bola tiež špecifikovaná v Ansible Inventory.
Bol to Ansible, ktorý doručil nášho monitorovacieho agenta do koncových zariadení
3G / LTE
Bohužiaľ, tento prípad použitia pre Ansible mohol fungovať iba v režime vývoja predtým, ako sme mali skutočné skútre.
Pretože skútre, ako ste pochopili, nesedia pripojené k jednému smerovaču Wi-Fi a neustále čakajú na aktualizácie cez sieť.
V skutočnosti kolobežky nemôžu mať vôbec žiadne iné pripojenie ako mobilné 3G/LTE (a aj to nie stále).
To okamžite spôsobuje veľa problémov a obmedzení, ako je nízka rýchlosť pripojenia a nestabilná komunikácia.
Najdôležitejšie však je, že v sieti 3G/LTE sa nemôžeme spoliehať len na statickú IP pridelenú sieti.
Čiastočne to riešia niektorí poskytovatelia SIM kariet, existujú dokonca špeciálne SIM karty určené pre IoT zariadenia so statickými IP adresami. K takýmto SIM kartám sme však nemali prístup a nemohli sme používať IP adresy.
Samozrejme, existovali nápady urobiť nejakú registráciu IP adries alias vyhľadávanie služieb niekde ako Consul, ale museli sme od takýchto nápadov upustiť, keďže v našich testoch sa IP adresa mohla meniť príliš často, čo viedlo k veľkej nestabilite.
Z tohto dôvodu by najpohodlnejším použitím na doručovanie metrík nebolo použitie modelu pull, kde by sme potrebné metriky prešli na zariadenia, ale push, doručovanie metrík zo zariadenia priamo na server.
VPN
Ako riešenie tohto problému sme zvolili VPN – konkrétne .
Klienti (kolobežky) sa pri štarte systému pripojili k serveru VPN a mohli sa k nim pripojiť. Tento tunel bol použitý na doručovanie aktualizácií.
Teoreticky by sa na monitorovanie dal použiť rovnaký tunel, ale takéto spojenie bolo komplikovanejšie a menej spoľahlivé ako jednoduché tlačenie.
Cloudové zdroje
V neposlednom rade je potrebné monitorovať naše cloudové služby a databázy, keďže na ne používame Kubernetes, ideálne tak, aby nasadenie monitoringu v klastri bolo čo najjednoduchšie. V ideálnom prípade pomocou , keďže na nasadenie ho vo väčšine prípadov používame. A samozrejme na monitorovanie cloudu je potrebné použiť rovnaké riešenia ako pre samotné kolobežky.
Dané
Uf, zdá sa, že sme vyriešili popis, poďme urobiť zoznam toho, čo sme nakoniec potrebovali:
- Rýchle riešenie, keďže monitorovanie je potrebné už počas procesu vývoja
- Objem/množstvo – je potrebných veľa metrík
- Vyžaduje sa zber denníkov
- Spoľahlivosť – dáta sú rozhodujúce pre úspech spustenia
- Nemôžete použiť ťahový model - potrebujete tlačiť
- Potrebujeme jednotný monitoring nielen hardvéru, ale aj cloudu
Finálny obrázok vyzeral asi takto
Výber zásobníka
Stáli sme teda pred otázkou výberu monitorovacieho zásobníka.
V prvom rade sme hľadali čo najkompletnejšie all-in-one riešenie, ktoré by súčasne pokrylo všetky naše požiadavky, no zároveň bolo dostatočne flexibilné na to, aby sme jeho využitie prispôsobili našim potrebám. Napriek tomu sme mali veľa obmedzení, ktoré nám uložil hardvér, architektúra a termíny.
Existuje obrovské množstvo monitorovacích riešení, počnúc plnohodnotnými systémami ako napr , alebo a končiac hotovými riešeniami pre správu vozového parku.
Spočiatku sa nám to posledné zdalo ako ideálne riešenie, ale niektoré nemali úplné monitorovanie, iné mali výrazne obmedzené možnosti bezplatných verzií a iné jednoducho nepokrývali naše „priania“ alebo neboli dostatočne flexibilné, aby vyhovovali našim scenárom. Niektoré sú jednoducho zastarané.
Po analýze niekoľkých podobných riešení sme rýchlo dospeli k záveru, že by bolo jednoduchšie a rýchlejšie zostaviť podobný stoh sami. Áno, bude to trochu komplikovanejšie ako nasadenie úplne pripravenej platformy na správu flotily, ale nebudeme musieť robiť kompromisy.
Takmer určite vo všetkom obrovskom množstve riešení už existuje hotové riešenie, ktoré by nám úplne vyhovovalo, ale v našom prípade bolo oveľa rýchlejšie zostaviť určitý stoh svojpomocne a prispôsobiť si ho „pre seba“, ako testovanie hotových výrobkov.
Pri tom všetkom sme sa nesnažili sami zostaviť celú monitorovaciu platformu, ale hľadali sme čo najfunkčnejšie „hotové“ stohy, len s možnosťou ich flexibilnej konfigurácie.
(B) ELK?
Prvým riešením, o ktorom sa skutočne uvažovalo, bol známy ELK stack.
V skutočnosti by sa mal volať BELK, pretože všetko začína Beats -
Samozrejme, ELK je jedno z najznámejších a najvýkonnejších riešení v oblasti monitorovania a ešte viac v oblasti zberu a spracovania protokolov.
Zamýšľali sme, že ELK sa bude používať na zhromažďovanie protokolov a tiež na dlhodobé uchovávanie metrík získaných z Prometheus.
Na vizualizáciu môžete použiť Grafan.
V skutočnosti môže nový zásobník ELK zbierať metriky nezávisle (metricbeat) a Kibana ich môže tiež zobrazovať.
Napriek tomu ELK spočiatku vyrastal z protokolov a doteraz má funkčnosť metrík niekoľko vážnych nevýhod:
- Výrazne pomalšie ako Prometheus
- Integruje sa na oveľa menej miest ako Prometheus
- Je ťažké pre nich nastaviť upozornenia
- Metriky zaberajú veľa miesta
- Nastavenie dashboardov s metrikami v Kibane je oveľa komplikovanejšie ako v Grafane
Vo všeobecnosti sú metriky v ELK ťažké a ešte nie sú také pohodlné ako v iných riešeniach, ktorých je teraz oveľa viac ako len Prometheus: TSDB, Victoria Metrics, Cortex atď., atď. Samozrejme, veľmi by som chcel mať hneď plnohodnotné all-in-one riešenie, no v prípade metricbeat bolo kompromisov priveľa.
A samotný ELK stack má niekoľko ťažkých momentov:
- Je ťažké, niekedy dokonca veľmi ťažké, ak zbierate pomerne veľké množstvo údajov
- Musíte to „vedieť variť“ - musíte to škálovať, ale nie je to triviálne
- Odstránená bezplatná verzia – bezplatná verzia nemá normálne upozornenia a v čase výberu neexistovala žiadna autentifikácia
Musím povedať, že nedávno sa posledný bod zlepšil a navyše (vrátane autentifikácie) sa začal meniť aj samotný cenový model.
Ale v čase, keď sme sa chystali nasadiť toto riešenie, nebolo žiadne upozornenie.
Možno sme sa mohli pokúsiť vytvoriť niečo pomocou ElastAlert alebo iných komunitných riešení, ale stále sme sa rozhodli zvážiť iné alternatívy.
Loki - Grafana - Prometheus
Momentálne môže byť dobrým riešením vybudovanie monitorovacieho zásobníka založeného čisto na Prometheus ako poskytovateľovi metrík, Loki pre protokoly a na vizualizáciu môžete použiť rovnakú Grafana.
Bohužiaľ, v čase spustenia predajného pilotu projektu (september-október 19) bol Loki ešte v beta verzii 0.3-0.4 a v čase spustenia vývoja ho nebolo možné považovať za produkčné riešenie. vôbec.
Zatiaľ nemám skúsenosti so skutočným používaním Lokiho v serióznych projektoch, ale môžem povedať, že Promtail (agent na zbieranie protokolov) funguje skvele ako na bare-metal, tak aj na pody v kubernetes.
TICK
Azda najdôstojnejšia (jediná?) plnohodnotná alternatíva k ELK stacku sa teraz môže nazývať iba TICK stack - Telegraf, InfluxDB, Chronograf, Kapacitor.
Nižšie popíšem všetky komponenty podrobnejšie, ale všeobecná myšlienka je takáto:
- Telegraf - agent pre zber metrík
- InfluxDB - databáza metrík
- Kapacitor - procesor metrík v reálnom čase na upozorňovanie
- Chronograf - webový panel pre vizualizáciu
Pre InfluxDB, Kapacitor a Chronograf existujú oficiálne tabuľky kormidla, ktoré sme použili na ich nasadenie.
Treba poznamenať, že v najnovšej verzii Influx 2.0 (beta) sa Kapacitor a Chronograf stali súčasťou InfluxDB a už neexistujú samostatne
telegraf
je veľmi ľahký agent na zhromažďovanie metrík na štátnom automate.
Dokáže sledovať obrovské množstvo všetkého, od na
server .
Má množstvo skvelých výhod:
- Rýchly a ľahký (napísané v Go)
- Jedáva minimálne množstvo zdrojov
- Push metriky predvolene
- Zhromažďuje všetky potrebné metriky
- Systémové metriky bez akýchkoľvek nastavení
- Hardvérové metriky, ako sú informácie zo senzorov
- Je veľmi jednoduché pridať svoje vlastné metriky
- Veľa pluginov hneď po vybalení
- Zbiera protokoly
Keďže push metriky boli pre nás nevyhnutné, všetky ostatné výhody boli viac než príjemným doplnkom.
Zhromažďovanie protokolov samotným agentom je tiež veľmi pohodlné, pretože nie je potrebné pripájať ďalšie nástroje na protokolovanie protokolov.
Influx ponúka najpohodlnejšie skúsenosti pre prácu s protokolmi, ak používate .
Telegraf je vo všeobecnosti skvelým prostriedkom na zhromažďovanie metrík, aj keď nepoužívate zvyšok zásobníka ICK.
Mnoho ľudí ju pre pohodlie kríži s ELK a rôznymi inými databázami časových sérií, pretože dokáže zapisovať metriky takmer kdekoľvek.
InfluxDB
InfluxDB je hlavným jadrom zásobníka TICK, konkrétne databázy časových sérií pre metriky.
Okrem metrík môže Influx ukladať aj protokoly, hoci protokoly preň sú v podstate rovnaké metriky, len namiesto obvyklých číselných ukazovateľov hlavnú funkciu vykonáva riadok textu protokolu.
InfluxDB je tiež napísaný v Go a zdá sa, že beží oveľa rýchlejšie v porovnaní s ELK na našom (nie najvýkonnejšom) klastri.
Jednou zo skvelých výhod Influxu by bolo aj veľmi pohodlné a bohaté API pre dátové dopyty, ktoré sme veľmi aktívne využívali.
Nevýhody – $$$ alebo škálovanie?
Zásobník TICK má len jednu nevýhodu, ktorú sme objavili - je drahý. Ešte viac.
Čo má platená verzia a čo bezplatná verzia nemá?
Pokiaľ sme boli schopní pochopiť, jediný rozdiel medzi platenou verziou zásobníka TICK a bezplatnou verziou sú možnosti škálovania.
Konkrétne môžete vytvoriť klaster s vysokou dostupnosťou iba v .
Ak chcete plnohodnotnú HA, musíte si buď zaplatiť, alebo použiť nejaké barličky. Existuje par komunitnych rieseni - napr vyzerá ako kompetentné riešenie, ale je napísané, že nie je vhodné na výrobu, ako aj
- jednoduché riešenie s pumpovaním dát cez NATS (bude sa musieť aj škálovať, ale dá sa to vyriešiť).
Je to škoda, ale oboje sa zdá byť opustené - neexistujú žiadne čerstvé commity, predpokladám, že problémom je čoskoro očakávané vydanie novej verzie Influx 2.0, v ktorej bude veľa vecí inak (nie sú informácie o zatiaľ v ňom
Oficiálne existuje bezplatná verzia - v skutočnosti ide o primitívnu HA, ale iba prostredníctvom vyváženia,
pretože všetky údaje sa zapíšu do všetkých inštancií InfluxDB za vyrovnávačom zaťaženia.
Má nejaké ako potenciálne problémy s prepisovaním bodov a potreba vopred vytvoriť základy pre metriky
(čo sa deje automaticky pri bežnej práci s InfluxDB).
Okrem toho , to znamená dodatočnú réžiu pre duplicitné metriky (spracovanie aj ukladanie), ktoré možno nepotrebujete, no neexistuje spôsob, ako ich oddeliť.
Victoria Metrics?
Výsledkom bolo, že napriek tomu, že sme boli úplne spokojní so zásobníkom TICK vo všetkom okrem plateného škálovania, rozhodli sme sa zistiť, či existujú nejaké bezplatné riešenia, ktoré by mohli nahradiť databázu InfluxDB, pričom zostávajúce komponenty T_CK ponechajú.
Existuje veľa databáz časových radov, ale najsľubnejšia je Victoria Metrics, má množstvo výhod:
- Rýchlo a jednoducho, aspoň podľa výsledkov
- Existuje klastrová verzia, o ktorej sú teraz dokonca dobré recenzie
- Môže sa lámať
- Podporuje protokol InfluxDB
Nemali sme v úmysle postaviť úplne vlastný stack založený na Victorii a hlavnou nádejou bolo, že by sme ho mohli použiť ako drop-in náhradu za InfluxDB.
Bohužiaľ to nie je možné, napriek tomu, že protokol InfluxDB je podporovaný, funguje len na zaznamenávanie metrík – „vonku“ je dostupné iba API Prometheus, čo znamená, že na ňom nebude možné nastaviť Chronograf.
Okrem toho sú pre metriky podporované iba číselné hodnoty (pre vlastné metriky sme použili reťazcové hodnoty - viac v sekcii ).
Je zrejmé, že z rovnakého dôvodu nemôže VM ukladať protokoly ako Influx.
Tiež je potrebné poznamenať, že v čase hľadania optimálneho riešenia ešte nebola Victoria Metrics taká populárna, dokumentácia bola oveľa menšia a funkcionalita slabšia
(Nepamätám si podrobný popis verzie klastra a shardingu).
Výber základne
V dôsledku toho sa rozhodlo, že pre pilotný projekt sa stále obmedzíme na jeden uzol InfluxDB.
Pre túto voľbu bolo niekoľko hlavných dôvodov:
- Veľmi sa nám páčila celá funkčnosť zásobníka TICK
- Už sa nám to podarilo nasadiť a fungovalo to výborne
- Termíny sa krátili a nezostávalo veľa času na testovanie iných možností.
- Nečakali sme taký ťažký náklad
Na prvú fázu pilota sme nemali veľa skútrov a testovanie počas vývoja neodhalilo žiadne výkonnostné problémy.
Preto sme sa rozhodli, že pre tento projekt nám bude stačiť jeden Influx node bez potreby škálovania (pozri závery na konci).
Rozhodli sme sa pre zásobník a základňu - teraz o zostávajúcich komponentoch zásobníka TICK.
Kapacitor
Kapacitor je súčasťou zásobníka TICK, služby, ktorá dokáže sledovať metriky vstupujúce do databázy v reálnom čase a vykonávať rôzne akcie na základe pravidiel.
Vo všeobecnosti je umiestnený ako nástroj na sledovanie potenciálnych anomálií a strojové učenie (nie som si istý, či sú tieto funkcie žiadané), ale najpopulárnejší prípad jeho použitia je bežnejší - varovanie.
Takto sme to použili na upozornenia. Nastavili sme upozornenia Slack, keď konkrétny skúter prešiel do režimu offline, a to isté sa urobilo pre inteligentné nabíjačky a dôležité komponenty infraštruktúry.
To umožnilo rýchlo reagovať na problémy, ako aj dostávať upozornenia, že je všetko v normále.
Jednoduchý príklad: pokazila sa alebo sa z nejakého dôvodu vybila prídavná batéria na napájanie našej „škatule“; jednoducho inštaláciou novej by sme po chvíli mali dostať upozornenie, že funkčnosť kolobežky bola obnovená.
V Influx 2.0 sa Kapacitor stal súčasťou DB
chronograf
Videl som veľa rôznych UI riešení na monitorovanie, ale môžem povedať, že z hľadiska funkčnosti a UX sa nič nevyrovná Chronografu.
Začali sme používať zásobník TICK, napodiv, s Grafanom ako webovým rozhraním.
Jeho funkčnosť nebudem popisovať, každý pozná široké možnosti nastavenia čohokoľvek.
Grafana je však stále úplne univerzálny nástroj, zatiaľ čo Chronograf je určený hlavne na použitie s Influxom.
A samozrejme, vďaka tomu si Chronograf môže dovoliť oveľa šikovnejšiu či pohodlnejšiu funkcionalitu.
Možno hlavnou výhodou práce s Chronografom je to, že si môžete prezrieť vnútro InfluxDB prostredníctvom Preskúmať.
Zdalo by sa, že Grafana má takmer identickú funkcionalitu, ale v skutočnosti sa dá nastavenie dashboardu v Chronografe vykonať niekoľkými kliknutiami myšou (súčasne sa tam pozriete na vizualizáciu), zatiaľ čo v Grafane budete mať skôr či neskôr upraviť konfiguráciu JSON (samozrejme Chronograf umožňuje nahrať vaše ručne nakonfigurované pomlčky a v prípade potreby ich upraviť ako JSON - ale nikdy som sa ich nemusel dotýkať po ich vytvorení v používateľskom rozhraní).
Kibana má oveľa bohatšie možnosti na vytváranie dashboardov a ovládacích prvkov pre ne, ale UX pre takéto operácie je veľmi zložité.
Vytvorenie pohodlného dashboardu si bude vyžadovať dobré pochopenie. A hoci je funkčnosť prístrojových panelov Chronograf menšia, ich vytváranie a prispôsobenie je oveľa jednoduchšie.
Samotné prístrojové dosky, okrem príjemného vizuálneho štýlu, sa vlastne nijako nelíšia od prístrojových dosiek v Grafane či Kibane:
Takto vyzerá okno dotazu:
Okrem iného je dôležité poznamenať, že chronograf, ktorý pozná typy polí v databáze InfluxDB, vám môže niekedy automaticky pomôcť s písaním dotazu alebo výberom správnej agregačnej funkcie, ako je priemer.
A samozrejme, Chronograf je maximálne pohodlný na prezeranie denníkov. Vyzerá to takto:
V predvolenom nastavení sú protokoly Influx prispôsobené na použitie syslog, a preto majú dôležitý parameter - závažnosť.
Užitočný je najmä graf v hornej časti, na ktorom vidíte vyskytujúce sa chyby a farba okamžite jasne ukazuje, či je závažnosť vyššia.
Niekoľkokrát sme týmto spôsobom zachytili dôležité chyby, keď sme si prezreli záznamy za posledný týždeň a videli sme červený bodec.
Samozrejme, ideálne by bolo nastaviť upozornenia na takéto chyby, keďže na to sme už mali všetko.
Dokonca sme to na chvíľu zapli, no v procese prípravy pilota sa ukázalo, že dostávame pomerne veľa chýb (vrátane systémových, ako je nedostupnosť LTE siete), ktoré „spamovali“ aj kanál Slack veľa, bez toho, aby to spôsobilo nejaké problémy.veľký prínos.
Správnym riešením by bolo zvládnuť väčšinu týchto typov chýb, upraviť ich závažnosť a až potom povoliť upozorňovanie.
Týmto spôsobom by sa do Slacku odosielali iba nové alebo dôležité chyby. Na takéto nastavenie jednoducho nebolo dosť času vzhľadom na krátke termíny.
overenie pravosti
Za zmienku tiež stojí, že Chronograf podporuje OAuth a OIDC ako autentifikáciu.
Je to veľmi výhodné, pretože vám to umožňuje jednoducho ho pripojiť k serveru a vytvoriť plnohodnotné jednotné prihlásenie.
V našom prípade to bol server — bol použitý na pripojenie k monitorovaniu, ale rovnaký server bol použitý aj na autentifikáciu skútrov a požiadaviek na back-end.
"správca"
Posledným komponentom, ktorý opíšem, je náš samostatne napísaný „admin panel“ vo Vue.
V podstate je to len samostatná služba, ktorá súčasne zobrazuje informácie o kolobežkách z našich vlastných databáz, mikroslužieb a metrických údajov z InfluxDB.
Okrem toho sa tam presunulo mnoho administratívnych funkcií, ako napríklad núdzový reštart alebo diaľkové otvorenie zámku pre tím podpory.
Boli tam aj mapy. Už som spomínal, že sme začali s Grafanou namiesto Chronografu – pretože pre Grafana sú dostupné mapy vo forme pluginov, na ktorých sme si mohli prezerať súradnice skútrov. Možnosti mapových widgetov pre Grafana sú, žiaľ, veľmi obmedzené a v dôsledku toho bolo oveľa jednoduchšie za pár dní napísať vlastnú webovú aplikáciu s mapami, aby ste v danom momente nielen videli súradnice, ale aj zobrazovali trasu, ktorú skúter prejde, možnosť filtrovania údajov na mape atď. (všetky tieto funkcie, ktoré sme nemohli nakonfigurovať na jednoduchom dashboarde).
Jednou z už spomínaných výhod Influxu je možnosť jednoduchého vytvárania vlastných metrík.
To umožňuje jeho použitie pre veľké množstvo scenárov.
Snažili sme sa tam zaznamenať všetky užitočné informácie: nabitie batérie, stav zámku, výkon senzora, bluetooth, GPS a mnoho ďalších zdravotných kontrol.
Toto všetko sme zobrazili na admin paneli.
Samozrejme, najdôležitejším kritériom pre nás bol prevádzkový stav skútra - v skutočnosti to Influx kontroluje sám a zobrazuje to „zelenými svetlami“ v časti Nodes.
Robí to funkcia — použili sme to na pochopenie výkonu nášho boxu a posielanie rovnakých upozornení do Slacku.
Mimochodom, skútre sme pomenovali podľa mien postáv zo Simpsonovcov - bolo tak pohodlné ich od seba odlíšiť
A vo všeobecnosti to bolo takto zábavnejšie. Neustále boli počuť frázy ako „Chlapci, Smithers je mŕtvy!“.
Reťazcové metriky
Dôležité je, že InfluxDB umožňuje ukladať nielen číselné hodnoty, ako je to v prípade Victoria Metrics.
Zdalo by sa, že to nie je až také dôležité – veď okrem logov možno ukladať akékoľvek metriky vo forme čísel (stačí pridať mapovanie pre známe stavy – akýsi enum)?
V našom prípade existoval aspoň jeden scenár, kde boli reťazcové metriky veľmi užitočné.
Náhodou sa stalo, že dodávateľom našich „inteligentných nabíjačiek“ bola tretia strana, nemali sme žiadnu kontrolu nad procesom vývoja a informáciami, ktoré nám tieto nabíjačky mohli poskytnúť.
Výsledkom bolo, že API na nabíjanie nebolo ani zďaleka ideálne, ale hlavným problémom bolo, že nie vždy sme dokázali pochopiť ich stav.
Tu prišiel na pomoc Influx. Stav reťazca, ktorý nám prišiel, sme jednoducho zapísali do poľa databázy InfluxDB bez zmien.
Nejaký čas sa tam dostali iba hodnoty ako „online“ a „offline“, na základe ktorých sa informácie zobrazovali v našom administračnom paneli a odosielali sa upozornenia do Slacku. V určitom okamihu sa tam však začali objavovať aj hodnoty ako „odpojené“.
Ako sa neskôr ukázalo, tento stav bol odoslaný raz po strate spojenia, ak sa nabíjačke nepodarilo nadviazať spojenie so serverom po určitom počte pokusov.
Ak by sme teda používali iba pevnú množinu hodnôt, možno by sme tieto zmeny vo firmvéri neuvideli v správnom čase.
A vo všeobecnosti reťazcové metriky poskytujú oveľa viac možností využitia, môžete do nich zaznamenať prakticky akékoľvek informácie. Aj keď, samozrejme, musíte tento nástroj používať opatrne.
Okrem bežných metrík sme v InfluxDB zaznamenávali aj informácie o polohe GPS. To bolo neuveriteľne užitočné pri monitorovaní polohy skútrov na našom administračnom paneli.
V skutočnosti sme vždy vedeli, kde a ktorá kolobežka je v momente, keď sme to potrebovali.
To sa nám veľmi hodilo, keď sme hľadali kolobežku (viď závery na konci).
Monitorovanie infraštruktúry
Okrem samotných skútrov sme potrebovali monitorovať aj celú našu (dosť rozsiahlu) infraštruktúru.
Veľmi všeobecná architektúra vyzerala asi takto:
Ak zvýrazníme čistý monitorovací zásobník, vyzerá to takto:
V cloude by sme chceli skontrolovať:
- databázy
- plášť na kľúče
- Mikroslužby
Keďže všetky naše cloudové služby sa nachádzajú v Kubernetes, bolo by pekné zbierať informácie o jeho stave.
Našťastie Telegraf po vybalení dokáže zhromaždiť obrovské množstvo metrík o stave klastra Kubernetes a Chronograf na to okamžite ponúka krásne dashboardy.
Sledovali sme najmä výkon podov a spotrebu pamäte. V prípade pádu výstrahy v Slacku.
Existujú dva spôsoby sledovania modulov v Kubernetes: DaemonSet a Sidecar.
Obe metódy sú podrobne opísané .
Použili sme Telegraf Sidecar a okrem metrík sme zbierali logy z pod.
V našom prípade sme sa museli popasovať s polenami. Napriek tomu, že Telegraf dokáže vytiahnuť protokoly z Docker API, chceli sme mať jednotnú kolekciu protokolov s našimi koncovými zariadeniami a nakonfigurovať na to syslog pre kontajnery. Možno toto riešenie nebolo pekné, ale na jeho prácu neboli žiadne sťažnosti a protokoly boli v Chronografe zobrazené dobre.
Monitorovať sledovanie???
Na záver sa objavila odveká otázka monitorovania monitorovacích systémov, no na to sme našťastie, alebo bohužiaľ, jednoducho nemali dostatok času.
Hoci Telegraf môže ľahko posielať svoje vlastné metriky alebo zbierať metriky z databázy InfluxDB na odosielanie buď do rovnakého Influxu alebo niekde inde.
Závery
Aké závery sme vyvodili z výsledkov pilotného projektu?
Ako môžete vykonávať monitorovanie?
V prvom rade TICK stack plne splnil naše očakávania a dal nám ešte viac príležitostí, ako sme pôvodne očakávali.
Všetky funkcie, ktoré sme potrebovali, boli k dispozícii. Všetko, čo sme s tým robili, fungovalo bez problémov.
produktivita
Hlavným problémom zásobníka TICK v bezplatnej verzii je nedostatok možností škálovania. Pre nás to nebol problém.
Nezbierali sme presné údaje/čísla o zaťažení, ale zbierali sme údaje z približne 30 skútrov naraz.
Každý z nich zhromaždil viac ako tri desiatky metrík. Zároveň sa zbierali protokoly zo zariadení. Zber a odosielanie údajov prebiehalo každých 10 sekúnd.
Je dôležité poznamenať, že po týždni a pol pilotnej prevádzky, keď bola väčšina „problémov z detstva“ opravená a najdôležitejšie problémy už boli vyriešené, sme museli znížiť frekvenciu odosielania údajov na server. 30 sekúnd. Bolo to nevyhnutné, pretože prevádzka na našich LTE SIM kartách začala rýchlo miznúť.
Gro návštevnosti pohltili logy, samotné metriky aj s 10-sekundovým intervalom prakticky neplytvali.
V dôsledku toho sme po určitom čase úplne zakázali zhromažďovanie protokolov na zariadeniach, pretože špecifické problémy boli zrejmé aj bez neustáleho zhromažďovania.
V niektorých prípadoch, ak bolo prezeranie protokolov stále potrebné, sme sa jednoducho pripojili cez WireGuard cez VPN.
Dodám tiež, že každé samostatné prostredie bolo od seba oddelené a zaťaženie opísané vyššie bolo relevantné iba pre produkčné prostredie.
Vo vývojovom prostredí sme vytvorili samostatnú inštanciu InfluxDB, ktorá pokračovala v zhromažďovaní údajov každých 10 sekúnd a nezaznamenali sme žiadne problémy s výkonom.
TICK - ideálne pre malé až stredné projekty
Na základe týchto informácií by som usúdil, že TICK stack je ideálny pre relatívne malé projekty alebo projekty, ktoré rozhodne neočakávajú žiadny HighLoad.
Ak nemáte tisíce modulov alebo stovky počítačov, dokonca aj jedna inštancia InfluxDB zvládne záťaž v pohode.
V niektorých prípadoch môžete byť spokojní s Influx Relay ako primitívnym riešením High Availability.
A samozrejme vám nikto nebráni v nastavení „vertikálneho“ škálovania a jednoduchom prideľovaní rôznych serverov pre rôzne typy metrík.
Ak si nie ste istí očakávaným zaťažením monitorovacích služieb, prípadne máte/budete mať veľmi „ťažkú“ architektúru, neodporúčam používať bezplatnú verziu TICK stacku.
Samozrejme, jednoduchým riešením by bola kúpa - ale tu sa nemôžem nejako vyjadriť, pretože sám nie som oboznámený s jemnosťou. Okrem toho, že je veľmi drahý a rozhodne nie je vhodný pre malé firmy.
V tomto prípade by som dnes odporučil zamerať sa na zhromažďovanie metrík prostredníctvom Victoria Metrics a protokolov pomocou Loki.
Pravda, opäť urobím výhradu, že Loki/Grafana sú oveľa menej pohodlné (kvôli väčšej univerzálnosti) ako hotové TICK, ale sú zadarmo.
Je to dôležité,: všetky tu popísané informácie sú relevantné pre verziu Influx 1.8, momentálne sa chystá vydanie Influx 2.0.
Aj keď som to nemal možnosť vyskúšať v bojových podmienkach a je ťažké robiť závery o vylepšeniach, rozhranie sa určite ešte zlepšilo, architektúra sa zjednodušila (bez kapacity a chronografu),
sa objavili šablóny („zabijácka funkcia“ - ). Verzia 2 však, žiaľ, momentálne nemá kľúčovú vec, pre ktorú sme si vybrali prvú verziu – neexistuje zber protokolov.
Táto funkcionalita sa objaví aj v Influx 2.0, no nepodarilo sa nám nájsť žiadne termíny, ani približné.
Ako nevytvárať IoT platformy (teraz)
Nakoniec, po spustení pilotného projektu, sme sami zostavili vlastný plnohodnotný IoT stack, keďže neexistovala alternatíva vhodná podľa našich štandardov.
Nedávno je však k dispozícii v beta verzii - škoda, že tam nebola, keď sme začali s projektom.
Sme úplne spokojní s konečným výsledkom a platformou založenou na Ansible + TICK + WireGuard, ktorú sme sami zostavili. Dnes by som však odporučil bližšie sa pozrieť na Balena predtým, ako sa pokúsite vybudovať vlastnú IoT platformu.
Pretože v konečnom dôsledku dokáže väčšinu toho, čo sme robili my, a OpenBalena je bezplatný a otvorený zdroj.
Už vie, ako nielen odosielať aktualizácie, ale aj VPN je už zabudovaná a prispôsobená na použitie v prostredí IoT.
A len nedávno dokonca vydali svoje , ktorý sa ľahko spája s ich ekosystémom.
Hej, čo ten chýbajúci skúter?
Takže skúter, "Ralph", zmizol bez stopy.
Okamžite sme sa rozbehli pozrieť na mapu v našom „administračnom paneli“ s údajmi o metrikách GPS z InfluxDB.
Vďaka údajom z monitorovania sme ľahko určili, že skúter minulý deň okolo 21:00 opustil parkovisko, išiel asi pol hodiny do nejakej oblasti a bol zaparkovaný do 5:XNUMX pri nejakom nemeckom dome.
Po 5:XNUMX neboli prijaté žiadne monitorovacie údaje – to znamenalo, že buď bola prídavná batéria úplne vybitá, alebo útočník konečne prišiel na to, ako odstrániť inteligentný hardvér zo skútra.
Napriek tomu bola polícia stále privolaná na adresu, kde sa skúter nachádzal. Skúter tam nebol.
Prekvapilo to však aj majiteľa domu, ktorý sa na tomto skútri včera večer skutočne viezol domov z kancelárie.
Ako sa ukázalo, jeden z pomocných zamestnancov prišiel skoro ráno a vyzdvihol skúter, keď videl, že jeho prídavná batéria je úplne vybitá, a vzal ho (peši) na parkovisko. A dodatočná batéria zlyhala kvôli vlhkosti.
Skúter sme si ukradli sami. Mimochodom, neviem, ako a kto potom vyriešil problém s policajným prípadom, ale monitorovanie fungovalo perfektne...
Zdroj: hab.com