Před rokem jsme spustili pilotní verzi propagačního projektu pro .
Zpočátku se projekt jmenoval Road-To-Barcelona, později se stal Road-To-Berlin (odtud R2B na screenshotech) a nakonec se jmenoval xRide.
Hlavní myšlenkou projektu bylo toto: namísto centralizovaného půjčování aut nebo skútrů (mluvíme o skútrech alias elektrických motorkách, ne o kickscootrech/skútrech) jsme chtěli vytvořit platformu pro decentralizované půjčování. O potížích, se kterými jsme se setkali .
Zpočátku se projekt zaměřoval na automobily, ale kvůli termínům, extrémně dlouhé komunikaci s výrobci a obrovskému množství bezpečnostních omezení byly pro pilota vybrány elektrické skútry.
Uživatel si na telefon nainstaloval aplikaci pro iOS nebo Android, přiblížil se ke koloběžce, která se mu líbila, načež telefon a koloběžka navázali peer-to-peer spojení, ETH bylo vyměněno a uživatel mohl zahájit jízdu zapnutím koloběžky přes telefon. Na konci cesty bylo také možné zaplatit za cestu pomocí Etherea z peněženky uživatele na telefonu.
Kromě koloběžek uživatel v aplikaci viděl „chytré nabíječky“, jejichž návštěvou si uživatel mohl sám vyměnit aktuální baterii, pokud byla vybitá.
Obecně tak vypadal náš pilotní projekt, který byl spuštěn v září loňského roku ve dvou německých městech: Bonnu a Berlíně.
A pak, jednoho dne, v Bonnu, brzy ráno, byl náš podpůrný tým (umístěný na místě, aby udržoval skútry v provozuschopném stavu) upozorněn: jeden ze skútrů zmizel beze stopy.
Jak to najít a vrátit?
V tomto článku o tom budu mluvit, ale nejprve - o tom, jak jsme vybudovali vlastní platformu IoT a jak jsme ji monitorovali.
Co a proč sledovat: skútry, infrastrukturu, nabíjecí stanice?
Co jsme tedy chtěli v našem projektu sledovat?
Za prvé jsou to samotné koloběžky - elektrokoloběžky samy o sobě jsou poměrně drahé, takový projekt nemůžete spustit bez dostatečné přípravy, pokud je to možné, chcete o koloběžkách nasbírat co nejvíce informací: o jejich umístění, úrovni nabití , atd.
Kromě toho bych rád sledoval stav naší vlastní IT infrastruktury – databází, služeb a všeho, co potřebují k fungování. Bylo také nutné sledovat stav „chytrých nabíječek“, pokud by se porouchaly nebo jim došly plné baterie.
Skútry
Jaké byly naše koloběžky a co jsme o nich chtěli vědět?
První a nejdůležitější věcí jsou GPS souřadnice, protože díky nim můžeme pochopit, kde jsou a kde se pohybují.
Další je nabití baterie, díky kterému můžeme určit, že se nabíjení koloběžek blíží ke konci a poslat odšťavňovač nebo alespoň varovat uživatele.
Samozřejmě je také nutné zkontrolovat, co se děje s našimi hardwarovými komponentami:
- funguje bluetooth?
- funguje samotný GPS modul?
- Měli jsme problém i s tím, že GPS mohla poslat nesprávné souřadnice a zaseknout se a to se dalo zjistit až dodatečnými kontrolami na koloběžce,
a co nejdříve informujte podporu, aby problém vyřešila
- Měli jsme problém i s tím, že GPS mohla poslat nesprávné souřadnice a zaseknout se a to se dalo zjistit až dodatečnými kontrolami na koloběžce,
A nakonec: kontroly softwaru, počínaje OS a procesorem, zatížením sítě a disku, konče kontrolami našich vlastních modulů, které jsou pro nás specifičtější (, ).
technické vybavení
Jaká byla naše „železná“ část?
S ohledem na co nejkratší časový rámec a potřebu rychlého prototypování jsme zvolili nejjednodušší variantu implementace a výběru komponent – Raspberry Pi.
Kromě samotného Rpi jsme měli desku na míru (kterou jsme sami vyvinuli a objednali z Číny, abychom urychlili proces montáže finálního řešení) a sadu komponentů - relé (pro zapnutí/vypnutí koloběžky), čtečka nabití baterie, modem, antény. To vše bylo kompaktně zabaleno ve speciálním „xRide boxu“.
Nutno také podotknout, že celý box poháněla přídavná powerbanka, kterou zase napájela hlavní baterie skútru.
To umožnilo využít monitorování a zapnout skútr i po skončení jízdy, protože hlavní baterie byla vypnuta ihned po otočení klíčku zapalování do polohy „vypnuto“.
Přístavní dělník? Obyčejný Linux? a nasazení
Vraťme se k monitoringu, takže Malina – co máme?
Jednou z prvních věcí, kterou jsme chtěli použít k urychlení procesu nasazování, aktualizace a dodávání komponent na fyzická zařízení, byl Docker.
Bohužel se rychle ukázalo, že Docker na RPi, přestože funguje, má spoustu režií, zejména pokud jde o spotřebu energie.
Rozdíl v použití „nativního“ operačního systému, i když nebyl tak výrazný, byl stále dostatečný, abychom se měli na pozoru před možností příliš rychlé ztráty náboje.
Druhým důvodem byla jedna z našich partnerských knihoven na Node.js (sic!) – jediné součásti systému, která nebyla napsána v Go/C/C++.
Autoři knihovny nestihli poskytnout pracovní verzi v žádném z „nativních“ jazyků.
Nejen, že samotný uzel není nejelegantnějším řešením pro zařízení s nízkým výkonem, ale samotná knihovna byla velmi náročná na zdroje.
Uvědomili jsme si, že i kdybychom chtěli, používání Dockeru by pro nás bylo příliš náročné. Volba byla učiněna ve prospěch nativního OS a práce přímo pod ním.
OS
V důsledku toho jsme opět zvolili nejjednodušší možnost jako OS a použili jsme Raspbian (Debian build pro Pi).
Veškerý náš software píšeme v Go, takže jsme také napsali hlavní modul hardwarového agenta v našem systému v Go.
Je to on, kdo je zodpovědný za práci s GPS, Bluetooth, čtení nabití, zapnutí koloběžky atd.
Nasadit
Okamžitě vyvstala otázka, zda je potřeba implementovat mechanismus pro doručování aktualizací do zařízení (OTA) – jak aktualizace našeho agenta/aplikace samotného, tak aktualizace samotného OS/firmwaru (protože nové verze agenta by mohly vyžadovat aktualizace jádra nebo systémové komponenty, knihovny atd.) .
Po poměrně dlouhé analýze trhu se ukázalo, že řešení pro dodávání aktualizací do zařízení je poměrně dost.
Od relativně jednoduchých, většinou aktualizací/dual-boot orientovaných utilit jako swupd/SWUpdate/OSTree až po plnohodnotné platformy jako Mender a Balena.
V první řadě jsme se rozhodli, že nás zajímají end-to-end řešení, takže volba okamžitě padla na platformy.
Velmi byl vyloučen kvůli skutečnosti, že ve skutečnosti používá stejný Docker ve svém balenaEngine.
Ale podotýkám, že i přes to jsme nakonec jejich produkt používali neustále pro flash firmware na SD kartách - jednoduchý a mimořádně pohodlný nástroj.
Volba proto nakonec padla . Mender je kompletní platforma pro sestavení, dodání a instalaci firmwaru.
Celkově platforma vypadá skvěle, ale trvalo nám asi týden a půl, než jsme vytvořili správnou verzi našeho firmwaru pomocí Mender builderu.
A čím více jsme se ponořili do spletitostí jeho použití, tím více bylo jasné, že k jeho plnému nasazení budeme potřebovat mnohem více času, než jsme měli.
Bohužel, naše krátké termíny znamenaly, že jsme byli nuceni opustit používání Menderu a zvolit ještě jednodušší.
Možná
Nejjednodušším řešením v naší situaci bylo použít Ansible. Pro začátek stačilo pár příruček.
Jejich podstatou bylo, že jsme se jednoduše připojili z hostitele (CI server) přes ssh k našim rasberries a distribuovali jim aktualizace.
Na samém začátku bylo vše jednoduché - museli jste být ve stejné síti se zařízeními, nalévání probíhalo přes Wi-Fi.
V kanceláři bylo prostě tucet testovacích malin připojených ke stejné síti, každé zařízení mělo statickou IP adresu také uvedenou v Ansible Inventory.
Byl to Ansible, kdo dopravil našeho monitorovacího agenta do koncových zařízení
3G / LTE
Bohužel tento případ použití pro Ansible mohl fungovat pouze ve vývojovém režimu, než jsme měli skutečné skútry.
Protože skútry, jak chápete, nesedí připojené k jednomu Wi-Fi routeru a neustále čekají na aktualizace přes síť.
Ve skutečnosti koloběžky nemohou mít vůbec žádné jiné připojení než mobilní 3G/LTE (a ani pak ne pořád).
To okamžitě přináší mnoho problémů a omezení, jako je nízká rychlost připojení a nestabilní komunikace.
Nejdůležitější ale je, že v síti 3G/LTE se nemůžeme jednoduše spoléhat na statickou IP přidělenou síti.
Částečně to řeší někteří poskytovatelé SIM karet, existují dokonce speciální SIM karty určené pro IoT zařízení se statickými IP adresami. K takovým SIM kartám jsme ale neměli přístup a nemohli používat IP adresy.
Samozřejmě existovaly nápady, jak provést nějakou registraci IP adres alias vyhledávání služeb někde jako Consul, ale museli jsme takové nápady opustit, protože v našich testech se IP adresa mohla měnit příliš často, což vedlo k velké nestabilitě.
Z tohoto důvodu by nejpohodlnější použití pro doručování metrik nebylo použití modelu pull, kdy bychom potřebné metriky hledali na zařízeních, ale push, doručování metrik ze zařízení přímo na server.
VPN
Jako řešení tohoto problému jsme zvolili VPN – konkrétně .
Klienti (koloběžky) se při startu systému připojili k VPN serveru a mohli se k nim připojit. Tento tunel byl použit k doručování aktualizací.
Teoreticky by pro monitorování mohl být použit stejný tunel, ale takové spojení bylo komplikovanější a méně spolehlivé než prostý push.
Cloudové zdroje
V neposlední řadě je potřeba monitorovat naše cloudové služby a databáze, jelikož pro ně používáme Kubernetes, ideálně tak, aby nasazení monitoringu v clusteru bylo co nejjednodušší. V ideálním případě pomocí , protože pro nasazení jej ve většině případů používáme. A samozřejmě pro sledování cloudu je potřeba použít stejná řešení jako pro samotné koloběžky.
Dáno
Uf, zdá se, že jsme vyřešili popis, pojďme si udělat seznam toho, co jsme nakonec potřebovali:
- Rychlé řešení, protože monitorování je nutné již během procesu vývoje
- Objem/množství – je potřeba mnoho metrik
- Je vyžadován sběr protokolů
- Spolehlivost – data jsou rozhodující pro úspěch spuštění
- Nemůžete použít tahový model - potřebujete push
- Potřebujeme jednotný monitoring nejen hardwaru, ale i cloudu
Finální obrázek vypadal asi takto
Výběr zásobníku
Stáli jsme tedy před otázkou výběru monitorovacího zásobníku.
V první řadě jsme hledali nejúplnější all-in-one řešení, které by současně pokrylo všechny naše požadavky, ale zároveň bylo dostatečně flexibilní, aby bylo možné jeho použití přizpůsobit našim potřebám. Přesto jsme měli mnoho omezení, která nám ukládal hardware, architektura a termíny.
Existuje obrovská škála monitorovacích řešení, počínaje plnohodnotnými systémy, jako jsou , nebo a konče hotovými řešeními pro správu vozového parku.
Zpočátku se nám to druhé zdálo jako ideální řešení, ale některé neměly plný monitoring, jiné měly značně omezené možnosti bezplatných verzí a další jednoduše nepokryly naše „chceme“ nebo nebyly dostatečně flexibilní, aby vyhovovaly našim scénářům. Některé jsou prostě zastaralé.
Po analýze řady podobných řešení jsme rychle dospěli k závěru, že by bylo jednodušší a rychlejší sestavit podobný zásobník sami. Ano, bude to trochu složitější než nasazení kompletně připravené platformy pro správu vozového parku, ale nebudeme muset dělat kompromisy.
Téměř jistě v tom obrovském množství řešení již existuje nějaké hotové, které by nám zcela vyhovovalo, ale v našem případě bylo mnohem rychlejší si určitý stack sestavit vlastními silami a upravit si ho „pro sebe“, než testování hotových výrobků.
Při tom všem jsme se nesnažili sami sestavit celou monitorovací platformu, ale hledali co nejfunkčnější „hotové“ stacky, pouze s možností je flexibilně konfigurovat.
(B) ELK?
Prvním řešením, které bylo skutečně zvažováno, byl známý ELK stack.
Vlastně by se to mělo jmenovat BELK, protože to všechno začíná Beats -
ELK je samozřejmě jedno z nejznámějších a nejvýkonnějších řešení v oblasti monitoringu a tím spíše ve sběru a zpracování protokolů.
Zamýšleli jsme, že ELK bude sloužit ke shromažďování protokolů a také k dlouhodobému ukládání metrik získaných z Prometheus.
Pro vizualizaci můžete použít Grafan.
Ve skutečnosti může nový zásobník ELK shromažďovat metriky nezávisle (metricbeat) a Kibana je může také zobrazovat.
Ale přesto ELK zpočátku vyrostl z protokolů a zatím má funkčnost metrik řadu vážných nevýhod:
- Výrazně pomalejší než Prometheus
- Integruje se do mnohem menšího počtu míst než Prometheus
- Je obtížné pro ně nastavit upozornění
- Metriky zabírají hodně místa
- Nastavení dashboardů s metrikami v Kibanu je mnohem složitější než v Grafanu
Obecně jsou metriky v ELK těžké a ještě ne tak pohodlné jako v jiných řešeních, kterých je nyní mnohem víc než jen Prometheus: TSDB, Victoria Metrics, Cortex atd., atd. Samozřejmě bych chtěl mít hned plnohodnotné all-in-one řešení, ale v případě metricbeat bylo příliš mnoho kompromisů.
A samotný ELK stack má řadu obtížných momentů:
- Je to těžké, někdy dokonce velmi těžké, pokud shromažďujete poměrně velké množství dat
- Musíte to „umět vařit“ – musíte to škálovat, ale to není triviální
- Odstraněná bezplatná verze – bezplatná verze nemá normální upozornění a v době výběru neexistovalo žádné ověření
Musím říct, že poslední bod se v poslední době zlepšil a navíc (včetně autentizace) se začal měnit samotný cenový model.
Ale v době, kdy jsme se chystali toto řešení nasadit, neprobíhalo vůbec žádné upozornění.
Možná jsme mohli zkusit něco postavit pomocí ElastAlert nebo jiných komunitních řešení, ale přesto jsme se rozhodli zvážit jiné alternativy.
Loki - Grafana - Prometheus
V tuto chvíli by mohlo být dobrým řešením postavit monitorovací zásobník založený čistě na Prometheus jako poskytovateli metrik, Loki pro logy a pro vizualizaci můžete použít stejnou Grafanu.
Bohužel v době zahájení prodejního pilotu projektu (září-říjen 19) byl Loki ještě v beta verzi 0.3-0.4 a v době zahájení vývoje jej nebylo možné považovat za produkční řešení. vůbec.
Ještě nemám zkušenosti se skutečným používáním Lokiho ve vážných projektech, ale mohu říci, že Promtail (agent pro sběr logů) funguje skvěle jak pro bare-metal, tak pro pody v kubernetes.
KLÍŠTĚ
Snad nejhodnější (jediná?) plnohodnotná alternativa k ELK stacku se nyní může jmenovat pouze TICK stack - Telegraf, InfluxDB, Chronograf, Kapacitor.
Všechny komponenty níže popíšu podrobněji, ale obecná myšlenka je tato:
- Telegraf - agent pro sběr metrik
- InfluxDB - databáze metrik
- Kapacitor – procesor metrik v reálném čase pro upozorňování
- Chronograf - webový panel pro vizualizaci
Pro InfluxDB, Kapacitor a Chronograf existují oficiální grafy kormidla, které jsme použili k jejich nasazení.
Je třeba poznamenat, že v nejnovější verzi Influx 2.0 (beta) se Kapacitor a Chronograf staly součástí InfluxDB a již neexistují samostatně
Telegrafovat
je velmi lehký agent pro shromažďování metrik na stavovém stroji.
Dokáže sledovat obrovské množství všeho, od na
server .
Má řadu skvělých výhod:
- Rychlé a lehké (napsáno v Go)
- Jí minimální množství zdrojů
- Push metriky ve výchozím nastavení
- Shromažďuje všechny potřebné metriky
- Systémové metriky bez jakéhokoli nastavení
- Hardwarové metriky, jako jsou informace ze senzorů
- Je velmi snadné přidat vlastní metriky
- Spousta pluginů z krabice
- Sbírá logy
Vzhledem k tomu, že push metriky byly pro nás nezbytné, všechny ostatní výhody byly více než příjemnými doplňky.
Sběr protokolů samotným agentem je také velmi pohodlný, protože není nutné připojovat další nástroje pro protokolování protokolů.
Influx nabízí nejpohodlnější zkušenost pro práci s protokoly, pokud používáte .
Telegraf je obecně skvělý agent pro shromažďování metrik, i když nepoužíváte zbytek ICK stacku.
Mnoho lidí jej pro pohodlí kříží s ELK a různými dalšími databázemi časových řad, protože dokáže zapisovat metriky téměř kdekoli.
InfluxDB
InfluxDB je hlavním jádrem zásobníku TICK, konkrétně databáze časových řad pro metriky.
Kromě metrik může Influx ukládat také protokoly, i když protokoly pro něj jsou v podstatě stejné metriky, pouze místo obvyklých číselných ukazatelů plní hlavní funkci řádek textu protokolu.
InfluxDB je také napsán v Go a zdá se, že běží mnohem rychleji ve srovnání s ELK na našem (ne nejvýkonnějším) clusteru.
Jednou ze skvělých výhod Influxu by bylo také velmi pohodlné a bohaté API pro datové dotazy, které jsme velmi aktivně využívali.
Nevýhody – $$$ nebo škálování?
Zásobník TICK má pouze jednu nevýhodu, kterou jsme objevili - ji miláčku. Ještě více.
Co má placená verze a co bezplatná verze nemá?
Pokud jsme byli schopni pochopit, jediný rozdíl mezi placenou verzí zásobníku TICK a bezplatnou verzí je škálování.
Konkrétně můžete vytvořit cluster s vysokou dostupností pouze v .
Pokud chcete plnohodnotnou HA, musíte buď zaplatit, nebo použít nějaké berličky. Existuje pár komunitních řešení - např vypadá jako kompetentní řešení, ale je napsáno, že není vhodné pro výrobu, stejně jako
- jednoduché řešení s čerpáním dat přes NATS (bude se muset také škálovat, ale dá se to vyřešit).
Je to škoda, ale oba se zdají být opuštěné - nejsou žádné čerstvé commity, předpokládám, že jde o brzké očekávané vydání nové verze Influx 2.0, ve které bude mnoho věcí jinak (neexistují žádné informace o zatím v něm měřítko).
Oficiálně existuje bezplatná verze - ve skutečnosti se jedná o primitivní HA, ale pouze díky vyvážení,
protože všechna data budou zapsána do všech instancí InfluxDB za vyrovnávačem zátěže.
Má nějaké jako potenciální problémy s přepisováním bodů a nutnost vytvořit si předem základy pro metriky
(což se děje automaticky při běžné práci s InfluxDB).
Navíc , to znamená další režii pro duplicitní metriky (zpracování i ukládání), které možná nepotřebujete, ale neexistuje způsob, jak je oddělit.
Victoria Metrics?
Výsledkem bylo, že navzdory skutečnosti, že jsme byli se zásobníkem TICK ve všem jiném než placeném škálování naprosto spokojeni, rozhodli jsme se zjistit, zda existují nějaká bezplatná řešení, která by mohla nahradit databázi InfluxDB, a ponechat zbývající komponenty T_CK.
Existuje mnoho databází časových řad, ale nejslibnější je Victoria Metrics, má řadu výhod:
- Rychle a jednoduše, alespoň podle výsledků
- Existuje clusterová verze, o které jsou nyní dokonce dobré recenze
- Umí stříhat
- Podporuje protokol InfluxDB
Neměli jsme v úmyslu postavit zcela vlastní stack založený na Victorii a hlavní nadějí bylo, že bychom jej mohli použít jako drop-in náhradu za InfluxDB.
Bohužel to není možné, přestože je protokol InfluxDB podporován, funguje pouze pro záznam metrik – „venku“ je dostupné pouze API Prometheus, což znamená, že na něm nebude možné nastavit Chronograf.
Navíc jsou pro metriky podporovány pouze číselné hodnoty (pro vlastní metriky jsme použili řetězcové hodnoty - více v sekci ).
Je zřejmé, že ze stejného důvodu nemůže VM ukládat protokoly jako Influx.
Také je třeba poznamenat, že v době hledání optimálního řešení nebyla Victoria Metrics ještě tak populární, dokumentace byla mnohem menší a funkčnost byla slabší
(Nepamatuji si podrobný popis verze clusteru a shardingu).
Výběr základny
V důsledku toho bylo rozhodnuto, že pro pilotní verzi se stále omezíme na jeden uzel InfluxDB.
Pro tuto volbu bylo několik hlavních důvodů:
- Velmi se nám líbila celá funkčnost zásobníku TICK
- Už se nám to podařilo nasadit a fungovalo to skvěle
- Termíny se krátily a na testování dalších možností nezbývalo mnoho času.
- Tak velkou zátěž jsme nečekali
Pro první fázi pilotu jsme neměli mnoho skútrů a testování během vývoje neodhalilo žádné problémy s výkonem.
Proto jsme se rozhodli, že pro tento projekt nám bude stačit jeden Influx uzel bez nutnosti škálování (viz závěry na konci).
Rozhodli jsme se pro zásobník a základnu - nyní o zbývajících součástech zásobníku TICK.
Kapacitor
Kapacitor je součástí TICK stacku, služby, která dokáže v reálném čase sledovat metriky vstupující do databáze a provádět různé akce na základě pravidel.
Obecně je umístěn jako nástroj pro sledování potenciálních anomálií a strojové učení (nejsem si jistý, zda jsou tyto funkce žádané), ale nejoblíbenější případ jeho použití je běžnější - upozornění.
Tak jsme to použili pro oznámení. Nastavili jsme upozornění Slack, když konkrétní skútr přešel do režimu offline, a totéž bylo provedeno pro chytré nabíječky a důležité součásti infrastruktury.
To umožnilo rychle reagovat na problémy a také dostávat upozornění, že je vše v pořádku.
Jednoduchý příklad: porouchala se nebo se z nějakého důvodu vybila přídavná baterie pro napájení naší „krabičky“; jednoduše instalací nové bychom měli po chvíli obdržet upozornění, že funkčnost koloběžky byla obnovena.
V Influxu 2.0 se Kapacitor stal součástí DB
Chronograf
Viděl jsem mnoho různých UI řešení pro monitorování, ale mohu říci, že z hlediska funkčnosti a UX se Chronografu nic nevyrovná.
Začali jsme používat TICK stack, kupodivu, s Grafanem jako webovým rozhraním.
Jeho funkčnost popisovat nebudu, každý zná jeho široké možnosti nastavení čehokoliv.
Grafana je však stále zcela univerzální nástroj, zatímco Chronograf je určen především pro použití s Influxem.
A samozřejmě si díky tomu může Chronograf dovolit mnohem chytřejší či pohodlnější funkcionalitu.
Snad hlavní výhodou práce s Chronografem je to, že si můžete prohlédnout vnitřky vašeho InfluxDB prostřednictvím Prozkoumat.
Zdálo by se, že Grafana má téměř identickou funkcionalitu, ale ve skutečnosti lze nastavení dashboardu v Chronografu provést na pár kliknutí myší (současně se tam podívat na vizualizaci), zatímco v Grafaně stejně dříve nebo později budete mít upravit konfiguraci JSON (samozřejmě Chronograf umožňuje nahrát vaše ručně nakonfigurované dasha a v případě potřeby je upravit jako JSON - ale po vytvoření v uživatelském rozhraní jsem se jich nikdy nemusel dotknout).
Kibana má mnohem bohatší možnosti pro vytváření dashboardů a ovládacích prvků pro ně, ale UX pro takové operace je velmi složité.
Vytvoření pohodlného dashboardu bude vyžadovat dobré porozumění. A i když je funkčnost dashboardů Chronograf menší, jejich vytváření a přizpůsobení je mnohem jednodušší.
Samotné dashboardy se kromě příjemného vizuálního stylu vlastně nijak neliší od dashboardů v Grafaně nebo Kibaně:
Takto vypadá okno dotazu:
Mimo jiné je důležité poznamenat, že při znalosti typů polí v databázi InfluxDB vám chronograf sám o sobě může někdy automaticky pomoci s psaním dotazu nebo výběrem správné agregační funkce jako průměr.
A samozřejmě Chronograf je pro prohlížení logů maximálně pohodlný. Vypadá to takto:
Ve výchozím nastavení jsou protokoly Influx přizpůsobeny pro použití syslog, a proto mají důležitý parametr - závažnost.
Užitečný je především graf v horní části, na kterém jsou vidět chyby, ke kterým dochází, a barva okamžitě jasně ukazuje, zda je závažnost vyšší.
Několikrát jsme tímto způsobem zachytili důležité chyby, šli jsme si prohlédnout protokoly za poslední týden a viděli jsme červený bodec.
Samozřejmě, v ideálním případě by bylo nastavit upozornění na takové chyby, protože už jsme pro to měli vše.
Dokonce jsme to na chvíli zapnuli, ale v procesu přípravy pilotu se ukázalo, že jsme dostávali poměrně hodně chyb (včetně systémových, jako je nedostupnost LTE sítě), které „spamovaly“ kanál Slack příliš mnoho, aniž by to způsobilo nějaké problémy.velký přínos.
Správným řešením by bylo zvládnout většinu těchto typů chyb, upravit jejich závažnost a teprve poté povolit upozornění.
Tímto způsobem by byly do Slacku zasílány pouze nové nebo důležité chyby. Vzhledem k napjatým termínům na takové nastavení prostě nebylo dost času.
Ověřování
Za zmínku také stojí, že Chronograf podporuje OAuth a OIDC jako autentizaci.
To je velmi pohodlné, protože vám to umožňuje snadno jej připojit k serveru a vytvořit plnohodnotné jednotné přihlašování.
V našem případě to byl server — byl použit pro připojení k monitorování, ale stejný server byl také použit k ověřování skútrů a požadavků na back-end.
"administrátor"
Poslední komponentou, kterou popíšu, je náš samostatně psaný „admin panel“ ve Vue.
V podstatě je to jen samostatná služba, která současně zobrazuje informace o skútrech z našich vlastních databází, mikroslužeb a dat metrik z InfluxDB.
Kromě toho se tam přesunulo mnoho administrativních funkcí, jako je nouzový restart nebo vzdálené otevření zámku pro tým podpory.
Nechyběly ani mapy. Už jsem zmínil, že jsme začali s Grafanou místo Chronografu - protože pro Grafana jsou k dispozici mapy ve formě pluginů, na kterých jsme si mohli prohlížet souřadnice skútrů. Možnosti mapových widgetů pro Grafana jsou bohužel velmi omezené a v důsledku toho bylo mnohem snazší napsat si za pár dní vlastní webovou aplikaci s mapami, abyste v tuto chvíli nejen viděli souřadnice, ale také trasu, kterou skútr urazí, umět filtrovat data na mapě atd. (všechny ty funkce, které jsme nemohli nakonfigurovat na jednoduchém dashboardu).
Jednou z již zmíněných výhod Influxu je možnost jednoduše vytvářet vlastní metriky.
To umožňuje jeho použití pro širokou škálu scénářů.
Snažili jsme se tam zaznamenat všechny užitečné informace: nabití baterie, stav zámku, výkon senzoru, bluetooth, GPS a mnoho dalších zdravotních kontrol.
To vše jsme zobrazili na admin panelu.
Nejdůležitějším kritériem pro nás byl samozřejmě provozní stav skútru - ve skutečnosti to Influx kontroluje sám a ukazuje to „zelenými světly“ v sekci Nodes.
To se provádí funkcí — použili jsme to, abychom pochopili výkon našeho boxu a poslali stejná upozornění Slacku.
Mimochodem, koloběžky jsme pojmenovali podle jmen postav ze Simpsonových - bylo tak pohodlné je od sebe odlišit
A obecně to byla takhle zábavnější. Neustále byly slyšet fráze jako „Kluci, Smithers je mrtvý!“.
Řetězcové metriky
Důležité je, že InfluxDB umožňuje ukládat nejen číselné hodnoty, jako je tomu u Victoria Metrics.
Zdálo by se, že to není tak důležité - vždyť kromě logů lze ukládat jakékoli metriky ve formě čísel (stačí přidat mapování pro známé stavy - jakýsi enum)?
V našem případě existoval alespoň jeden scénář, kde byly řetězcové metriky velmi užitečné.
Náhodou se stalo, že dodavatelem našich „chytrých nabíječek“ byla třetí strana, neměli jsme žádnou kontrolu nad vývojovým procesem a informacemi, které tyto nabíječky mohly poskytovat.
V důsledku toho nebylo nabíjecí API zdaleka ideální, ale hlavním problémem bylo, že jsme ne vždy dokázali pochopit jejich stav.
Tady přišel na pomoc Influx. Stav řetězce, který nám přišel, jsme jednoduše zapsali do pole databáze InfluxDB beze změn.
Nějakou dobu se tam dostaly pouze hodnoty jako „online“ a „offline“, na základě kterých se informace zobrazovaly v našem administračním panelu a upozornění byla odesílána do Slacku. V určitém okamžiku se tam však začaly objevovat i hodnoty jako „odpojeno“.
Jak se později ukázalo, tento stav byl odeslán jednou po ztrátě spojení, pokud se nabíječce po určitém počtu pokusů nepodařilo navázat spojení se serverem.
Pokud bychom tedy používali pouze pevnou sadu hodnot, nemuseli bychom tyto změny ve firmwaru vidět ve správný čas.
A obecně řetězcové metriky poskytují mnohem více možností využití, můžete do nich zaznamenat prakticky jakékoli informace. I když samozřejmě musíte tento nástroj také používat opatrně.
Kromě běžných metrik jsme do InfluxDB zaznamenávali také informace o poloze GPS. To bylo neuvěřitelně užitečné pro sledování polohy skútrů v našem administračním panelu.
Vlastně jsme vždy věděli, kde a která koloběžka je v tu chvíli, kdy jsme to potřebovali.
To se nám velmi hodilo, když jsme sháněli koloběžku (viz závěry na konci).
Monitorování infrastruktury
Kromě samotných koloběžek jsme potřebovali monitorovat i celou naši (spíše rozsáhlou) infrastrukturu.
Velmi obecná architektura vypadala asi takto:
Pokud zvýrazníme čistě monitorovací zásobník, vypadá takto:
V cloudu bychom chtěli zkontrolovat:
- Databáze
- Klíčenka
- Mikroslužby
Vzhledem k tomu, že všechny naše cloudové služby jsou umístěny v Kubernetes, bylo by hezké sbírat informace o jeho stavu.
Naštěstí Telegraf z krabice dokáže shromáždit obrovské množství metrik o stavu clusteru Kubernetes a Chronograf k tomu okamžitě nabízí krásné dashboardy.
Sledovali jsme především výkon podů a spotřebu paměti. V případě pádu výstrahy ve Slacku.
Existují dva způsoby sledování modulů v Kubernetes: DaemonSet a Sidecar.
Obě metody jsou podrobně popsány .
Použili jsme Telegraf Sidecar a kromě metrik jsme sbírali logy z pod.
V našem případě jsme si museli pohrát s kládami. Navzdory skutečnosti, že Telegraf může stahovat protokoly z Docker API, chtěli jsme mít jednotnou kolekci protokolů s našimi koncovými zařízeními a nakonfigurovat k tomu syslog pro kontejnery. Možná toto řešení nebylo krásné, ale na jeho práci nebyly žádné stížnosti a protokoly byly v Chronografu zobrazeny dobře.
Monitorovat sledování???
Nakonec se objevila letitá otázka monitorovacích monitorovacích systémů, ale na to jsme naštěstí, nebo bohužel, neměli dostatek času.
Přestože Telegraf může snadno posílat své vlastní metriky nebo sbírat metriky z databáze InfluxDB pro odeslání buď do stejného Influxu, nebo někam jinam.
Závěry
Jaké závěry jsme vyvodili z výsledků pilotního projektu?
Jak můžete provádět monitorování?
Za prvé, TICK stack plně splnil naše očekávání a dal nám ještě více příležitostí, než jsme původně očekávali.
Všechny funkce, které jsme potřebovali, byly k dispozici. Vše, co jsme s tím dělali, fungovalo bez problémů.
Производительность
Hlavním problémem zásobníku TICK v bezplatné verzi je nedostatek možností škálování. To pro nás nebyl problém.
Nesbírali jsme přesná data/čísla o zatížení, ale sbírali jsme data od asi 30 skútrů najednou.
Každý z nich shromáždil více než tři desítky metrik. Zároveň byly shromažďovány protokoly ze zařízení. Sběr a odesílání dat probíhalo každých 10 sekund.
Je důležité poznamenat, že po týdnu a půl pilotního provozu, kdy byla většina „dětských vředů“ opravena a nejdůležitější problémy již byly vyřešeny, jsme museli snížit frekvenci odesílání dat na server. 30 sekund. To se stalo nezbytným, protože provoz na našich LTE SIM kartách začal rychle mizet.
Převážnou část provozu pohltily logy, samotné metriky i s 10vteřinovým intervalem prakticky neplýtvaly.
V důsledku toho jsme po nějaké době zcela zakázali shromažďování protokolů na zařízeních, protože konkrétní problémy byly již zřejmé i bez neustálého shromažďování.
V některých případech, pokud bylo prohlížení protokolů stále nutné, jsme se jednoduše připojili přes WireGuard přes VPN.
Ještě dodám, že každé samostatné prostředí bylo od sebe odděleno a výše popsaná zátěž byla relevantní pouze pro produkční prostředí.
Ve vývojovém prostředí jsme vytvořili samostatnou instanci InfluxDB, která pokračovala ve sběru dat každých 10 sekund, a nenarazili jsme na žádné problémy s výkonem.
TICK - ideální pro malé až střední projekty
Na základě těchto informací bych usoudil, že TICK stack je ideální pro relativně malé projekty nebo projekty, které rozhodně nečekají žádný HighLoad.
Pokud nemáte tisíce modulů nebo stovky počítačů, i jedna instance InfluxDB zvládne zátěž v pohodě.
V některých případech můžete být spokojeni s Influx Relay jako primitivním řešením High Availability.
A samozřejmě vám nikdo nebrání nastavit „vertikální“ škálování a jednoduše alokovat různé servery pro různé typy metrik.
Pokud si nejste jisti očekávaným zatížením monitorovacích služeb, nebo máte/budete zaručeně mít velmi „těžkou“ architekturu, nedoporučoval bych používat bezplatnou verzi TICK stacku.
Jednoduchým řešením by samozřejmě byla koupě - ale zde se nemohu nějak vyjádřit, protože sám neznám ty jemnosti. Kromě toho, že je velmi drahý a rozhodně není vhodný pro malé firmy.
V tomto případě bych dnes doporučil zaměřit se na shromažďování metrik prostřednictvím Victoria Metrics a protokolů pomocí Loki.
Pravda, opět udělám výhradu, že Loki/Grafana jsou mnohem méně pohodlné (vzhledem k jejich větší univerzálnosti) než hotové TICK, ale jsou zdarma.
Je to důležité,: všechny zde popsané informace jsou relevantní pro verzi Influx 1.8, v tuto chvíli se Influx 2.0 chystá vydání.
I když jsem to neměl možnost vyzkoušet v bojových podmínkách a je těžké dělat závěry o vylepšeních, rozhraní se rozhodně ještě zlepšilo, architektura byla zjednodušena (bez kapacitoru a chronografu),
objevily se šablony („killer feature“ - ). Ale bohužel v tuto chvíli verze 2 nemá klíčovou věc, pro kterou jsme vybrali první verzi - neexistuje sběr protokolů.
Tato funkcionalita se objeví i v Influxu 2.0, ale nepodařilo se nám najít žádné termíny, ani přibližné.
Jak nevytvářet platformy IoT (nyní)
Nakonec jsme po spuštění pilotního projektu sami sestavili náš vlastní plnohodnotný IoT stack, protože neexistovala alternativa vhodná podle našich standardů.
V poslední době je však k dispozici v beta verzi – škoda, že tam nebyla, když jsme projekt začali dělat.
Jsme naprosto spokojeni s konečným výsledkem a platformou založenou na Ansible + TICK + WireGuard, kterou jsme sami sestavili. Dnes bych ale doporučoval podívat se blíže na Balena, než se pokusíte sami vybudovat vlastní IoT platformu.
Protože nakonec dokáže většinu toho, co jsme dělali my, a OpenBalena je bezplatný a open source.
Už ví, jak nejen posílat aktualizace, ale také VPN je již zabudována a přizpůsobena pro použití v prostředí IoT.
A právě nedávno dokonce vydali své , který se snadno napojí na jejich ekosystém.
Hej, co ten chybějící skútr?
Takže skútr, "Ralph", zmizel beze stopy.
Okamžitě jsme se běželi podívat na mapu v našem „administrátorském panelu“ s údaji o metrikách GPS z InfluxDB.
Díky monitorovacím datům jsme snadno určili, že skútr opustil parkoviště minulý den kolem 21:00, jel asi půl hodiny do nějaké oblasti a byl zaparkován do 5:XNUMX u nějakého německého domu.
Po 5:XNUMX nebyla přijata žádná monitorovací data – to znamenalo, že buď byla přídavná baterie zcela vybitá, nebo útočník konečně přišel na to, jak odstranit chytrý hardware ze skútru.
I přes to byla policie stále přivolána na adresu, kde se skútr nacházel. Skútr tam nebyl.
Překvapilo to však i majitele domu, který na této koloběžce skutečně jel včera večer z kanceláře domů.
Jak se ukázalo, jeden ze zaměstnanců podpory dorazil brzy ráno a vyzvedl skútr, když viděl, že jeho přídavná baterie je zcela vybitá, a odnesl jej (pěšky) na parkoviště. A přídavná baterie selhala kvůli vlhkosti.
Ukradli jsme skútr sami sobě. Mimochodem, nevím, jak a kdo pak vyřešil problém s policejním případem, ale sledování fungovalo perfektně...
Zdroj: www.habr.com