Egy évvel ezelőtt elindítottuk egy promóciós projekt kísérleti verzióját .
Kezdetben a projekt a Road-To-Barcelona nevet viselte, később Road-To-Berlin lett (innen R2B a képernyőképeken), végül pedig xRide néven.
A projekt fő gondolata a következő volt: a központosított autó- vagy robogóbérlés helyett (robogókról, más néven elektromos motorokról beszélünk, nem robogókról/robogókról) a decentralizált bérlés platformját akartuk létrehozni. Azokról a nehézségekről, amelyekkel szembesültünk .
Kezdetben a projekt az autókra összpontosított, de a határidők, a gyártókkal folytatott rendkívül hosszú kommunikáció és a rengeteg biztonsági korlátozás miatt elektromos robogókat választottak a pilóta számára.
A felhasználó iOS vagy Android alkalmazást telepített a telefonjára, megkereste a neki tetsző robogót, ami után a telefon és a robogó peer-to-peer kapcsolatot létesített, az ETH cseréje megtörtént és a felhasználó a roller bekapcsolásával megkezdhette az utazást. a telefon. Az utazás végén az Ethereummal is lehetett fizetni az utazást a felhasználó pénztárcájából a telefonon.
A felhasználó a robogók mellett „okostöltőket” látott az alkalmazásban, amelyek felkeresésével a felhasználó maga cserélhette ki az aktuális akkumulátort, ha az alacsony volt.
Általában így nézett ki a tavaly szeptemberben elindított pilotunk két német városban: Bonnban és Berlinben.
Aztán egy nap Bonnban, kora reggel riasztották a támogató csapatunkat (amely a helyszínen volt, hogy a robogókat üzemképes állapotban tartsa): az egyik robogó nyomtalanul eltűnt.
Hogyan lehet megtalálni és visszavinni?
Ebben a cikkben erről fogok beszélni, de először arról, hogyan építettük fel saját IoT-platformunkat, és hogyan figyeltük azt.
Mit és miért figyeljünk: robogókat, infrastruktúrát, töltőállomásokat?
Tehát mit akartunk nyomon követni a projektünkben?
Először is, ezek maguk a robogók - maguk az elektromos robogók meglehetősen drágák, kellő felkészültség nélkül nem lehet elindítani egy ilyen projektet; ha lehetséges, a lehető legtöbb információt szeretne összegyűjteni a robogókról: a helyükről, a töltöttségi szintről stb.
Помимо этого, хотелось бы отслеживать состояние нашей собственной IT инфраструктуры — базы, сервисы и все что им необходимо для работы. Нужно было отслеживать и состояние "умных зарядок", на случай если они сломались или в них кончились полные батареи.
Robogók
Mik voltak a robogóink, és mit szerettünk volna tudni róluk?
Az első és legfontosabb dolog a GPS koordináták, hiszen ezeknek köszönhetően tudjuk, hogy hol vannak és merre mozognak.
Далее — заряд батареи, благодаря ему мы можем определять, что зарядка скутеров подходит к концу и отправить juicer’а или хотя бы предупредить пользователя.
Természetesen azt is ellenőrizni kell, hogy mi történik a Hardver komponenseinkkel:
- működik a bluetooth?
- maga a GPS modul működik?
- Az is gondunk volt, hogy a GPS hibás koordinátákat küldhetett és elakadt, ezt pedig csak a robogó további ellenőrzésével lehetett megállapítani,
és a lehető leghamarabb értesítse az ügyfélszolgálatot a probléma megoldása érdekében
- Az is gondunk volt, hogy a GPS hibás koordinátákat küldhetett és elakadt, ezt pedig csak a robogó további ellenőrzésével lehetett megállapítani,
И последнее: проверки софтверной части, начиная с ОС и загрузки процессора, сети и диска, заканчивая уже более специфичными для нас проверками наших собственных модулей (, ).
hardver
Mi volt a „vas” részünk?
Figyelembe véve a lehető legrövidebb időkeretet és a gyors prototípuskészítés szükségességét, a legegyszerűbb lehetőséget választottuk a megvalósításhoz és az összetevők kiválasztásához - a Raspberry Pi-t.
Magán az Rpi-n kívül volt egy egyedi tábla (melyet mi magunk fejlesztettünk és rendeltünk Kínából, hogy felgyorsítsuk a végső megoldás összeszerelési folyamatát) és egy komponenskészlet - egy relé (a robogó be- és kikapcsolásához), akkumulátortöltő olvasó, modem, antennák. Mindezt kompaktan egy speciális „xRide dobozba” csomagolták.
Azt is meg kell jegyezni, hogy az egész dobozt egy további power bank táplálta, amelyet viszont a robogó fő akkumulátora táplált.
Это позволяло использовать мониторинг и включать скутер, даже после окончания поездки, так как основная батарея отключалась сразу после поворота ключа зажигания в положение "off".
Dokkmunkás? Sima Linux? és a telepítés
Térjünk vissza a monitorozáshoz, szóval Málna – mi van?
Az egyik első dolog, amit az összetevők telepítésének, frissítésének és fizikai eszközökre történő szállításának felgyorsítására használni akartunk, a Docker volt.
К сожалению, довольно быстро стало ясно что Docker на RPi хоть и работает, но дает достаточно много накладных расходов, в частности по энергопотреблению.
A „natív” operációs rendszert használó különbség, bár nem volt olyan erős, még mindig elegendő volt ahhoz, hogy óvakodjunk a töltés túl gyors elvesztésének lehetőségétől.
A második ok a Node.js (sic!) egyik partnerkönyvtárunk volt – a rendszer egyetlen olyan összetevője, amely nem Go/C/C++ nyelven íródott.
Авторы библиотеки не успели вовремя предоставить рабочую версию на любом из "нативных" языков.
Nemcsak maga a csomópont nem a legelegánsabb megoldás az alacsony teljesítményű eszközökhöz, de maga a könyvtár is nagyon erőforrás-éhes volt.
Rájöttünk, hogy még ha akarnánk is, a Docker használata túl sok költséget jelentene számunkra. A választás a natív operációs rendszer mellett történt, és közvetlenül az alatt működött.
OS
Ennek eredményeként ismét a legegyszerűbb opciót választottuk operációs rendszerként, és a Raspbiant (Debian build Pi-hez) használtuk.
Minden szoftverünket Go-ban írjuk, így a fő hardverügynök modult is Go-ban írtuk meg rendszerünkben.
Ő a felelős a GPS-szel, Bluetooth-al való munkavégzésért, a töltés leolvasásáért, a robogó bekapcsolásáért stb.
Telepítés
Azonnal felmerült a kérdés, hogy szükség van-e egy olyan mechanizmus megvalósítására, amely a frissítéseket eljuttatja az eszközökhöz (OTA) – mind magának az ügynökünknek/alkalmazásunknak, mind magának az operációs rendszernek/firmware-nek a frissítését (mivel az ügynök új verziói megkövetelhetik a kernel frissítését vagy rendszerösszetevők, könyvtárak stb.) .
Elég hosszas piacelemzés után kiderült, hogy elég sok megoldás létezik a készülék frissítésére.
A viszonylag egyszerű, többnyire frissítés/kettős rendszerindítás-orientált segédprogramoktól, mint például a swupd/SWUpdate/OSTree, a teljes értékű platformokig, mint például a Mender és a Balena.
Először is úgy döntöttünk, hogy a végpontok közötti megoldások érdekelnek minket, így a választás azonnal a platformokra esett.
A lényeg kizárták, mivel valójában ugyanazt a Dockert használja a balenaEngine-jében.
De megjegyzem, ennek ellenére végül folyamatosan használtuk a terméküket для флеша прошивок на SD карты — простая и крайне удобная утилита для этого.
Поэтому в итоге выбор пал на . Mender представляет из себя полноценную платформу для сборки, доставки и установки прошивок.
Összességében a platform remekül néz ki, de körülbelül másfél hétbe telt, mire elkészítettük firmware-ünk megfelelő verzióját a mender builder segítségével.
És minél jobban belemerültünk használatának bonyodalmaiba, annál világosabbá vált, hogy a teljes üzembe helyezéséhez sokkal több időre lesz szükségünk, mint amennyi volt.
Sajnos a szűkös határidők miatt kénytelenek voltunk lemondani a Mender használatáról, és egy még egyszerűbbet választani.
Ansible
Самым простым решением в нашей ситуации оказалось использование Ansible. Пары playbook’ов для начала было вполне достаточно.
A lényegük az volt, hogy egyszerűen csatlakoztunk a gazdagéptől (CI-szerver) ssh-n keresztül a Rasberry-inkhez, és kiosztottuk nekik a frissítéseket.
A legelején minden egyszerű volt - ugyanabban a hálózatban kellett lenni az eszközökkel, a kiöntés Wi-Fi-n keresztül történt.
Az irodában egyszerűen egy tucat tesztmálna csatlakozott ugyanahhoz a hálózathoz, minden eszköznek volt egy statikus IP-címe, amelyet az Ansible Inventory-ban is megadtak.
Az Ansible szállította a felügyeleti ügynökünket a végberendezésekhez
3G / LTE
Sajnos ez az Ansible használati esete csak fejlesztői módban működhetett, mielőtt tényleges robogóink voltak.
Mivel a robogók, amint megérti, nem csatlakoznak egyetlen Wi-Fi útválasztóhoz, és folyamatosan a hálózaton keresztül várják a frissítéseket.
A valóságban a robogóknak a mobil 3G/LTE-n kívül más kapcsolata sem lehet (és még akkor sem mindig).
Ez azonnal számos problémát és korlátot vet fel, például alacsony kapcsolati sebességet és instabil kommunikációt.
De a legfontosabb dolog az, hogy egy 3G/LTE hálózatban nem hagyatkozhatunk egyszerűen a hálózathoz rendelt statikus IP-re.
Ezt részben megoldják egyes SIM-kártya-szolgáltatók, léteznek speciális, statikus IP-című IoT-eszközökhöz tervezett SIM-kártyák is. De nem fértünk hozzá ilyen SIM-kártyákhoz, és nem tudtunk IP-címeket használni.
Természetesen voltak ötletek valamiféle IP-címek regisztrációjára, más néven szolgáltatásfelfedezésre valahol, mint a Consul, de el kellett hagynunk az ilyen ötleteket, mivel tesztjeink során az IP-cím túl gyakran változott, ami nagy instabilitáshoz vezetett.
Emiatt nem a pull modell használata lenne a legkényelmesebb a mérőszámok szállítására, ahol az eszközökre mennénk a szükséges mérőszámokért, hanem push, közvetlenül a szerverre szállítva a mérőszámokat az eszközről.
VPN
A probléma megoldásaként a VPN-t választottuk – konkrétan .
A kliensek (robogók) a rendszer elején csatlakoztak a VPN szerverhez, és csatlakozni tudtak hozzájuk. Ezt az alagutat használták a frissítések szállítására.
Elméletileg ugyanazt az alagutat lehetne használni megfigyelésre, de egy ilyen kapcsolat bonyolultabb és kevésbé megbízható, mint az egyszerű push.
Felhőforrások
Végül pedig szükség van felhőszolgáltatásaink és adatbázisaink monitorozására, mivel ezekhez Kubernetes-et használunk, ideális esetben azért, hogy a monitorozás telepítése a klaszterben a lehető legegyszerűbb legyen. Ideális esetben használja , так как для деплоя, мы в большинстве случаев используем его. И, само собой, для мониторинга облака нужно использовать те же решения, что и для самих скутеров.
Adott
Fú, úgy tűnik, a leírást rendeztük, a végén készítsünk egy listát arról, hogy mire volt szükségünk:
- Gyors megoldás, hiszen a monitorozás már a fejlesztési folyamat során szükséges
- Mennyiség/mennyiség – sok mérőszámra van szükség
- Naplógyűjtés szükséges
- Megbízhatóság – az adatok kulcsfontosságúak a sikeres elindításhoz
- Nem használhatja a húzó modellt – lökésre van szüksége
- Nemcsak a hardver, hanem a felhő egységes felügyeletére is szükségünk van
Конечная картинка выглядела примерно так
Verem kiválasztása
Tehát a megfigyelési verem kiválasztásának kérdésével kellett szembenéznünk.
Mindenekelőtt a legteljesebb all-in-one megoldást kerestük, amely egyszerre fedezi minden igényünket, ugyanakkor kellően rugalmas ahhoz, hogy felhasználását az igényeinkre szabjuk. Ennek ellenére sok korlátozást szabtak ránk a hardver, az architektúra és a határidők miatt.
Nagyon sokféle megfigyelési megoldás létezik, kezdve a teljes értékű rendszerekkel, mint pl , vagy és befejezve a flottakezelés kész megoldásaival.
Kezdetben ez utóbbi tűnt ideális megoldásnak számunkra, de volt, aki nem rendelkezett teljes körű monitorozással, másoknak erősen korlátozottak voltak az ingyenes verziók lehetőségei, mások pedig egyszerűen nem fedték le „kívánságainkat”, vagy nem voltak elég rugalmasak ahhoz, hogy megfeleljenek a forgatókönyveinknek. Némelyik egyszerűen elavult.
Számos hasonló megoldás elemzése után gyorsan arra a következtetésre jutottunk, hogy egyszerűbb és gyorsabb lenne magunknak összeállítani egy hasonló köteget. Igen, ez egy kicsit bonyolultabb lesz, mint egy teljesen kész Fleet Management platform bevezetése, de nem kell kompromisszumot kötnünk.
Szinte biztos, hogy a megoldások hatalmas bőségében van már olyan kész, ami teljesen megfelel nekünk, de esetünkben sokkal gyorsabb volt, ha magunk összeállítottunk egy bizonyos köteget, és „magunkra” szabtuk, mintsem. kész termékek tesztelése.
Mindezzel nem arra törekedtünk, hogy magunk állítsunk össze egy teljes felügyeleti platformot, hanem a legfunkcionálisabb „ready-made” stackeket kerestük, csak a rugalmas konfigurálás lehetőségével.
(B)ELK?
Az első tényleges megoldás a jól ismert ELK verem volt.
На самом деле он должен называться BELK, ведь начинается все с Beats -
Конечно, ELK это одно из самых известных и мощных решений в области мониторинга, а уж в сборе и обработке логов, так и самое.
Azt terveztük, hogy az ELK-t naplók gyűjtésére, valamint a Prometheustól kapott mérőszámok hosszú távú tárolására használjuk.
Для визуализации можно использовать Grafan’у.
Valójában az új ELK verem képes önállóan is gyűjteni a mutatókat (metricbeat), és a Kibana is képes megjeleníteni azokat.
Ennek ellenére az ELK kezdetben naplókból nőtt ki, és eddig a mérőszámok funkcionalitásának számos komoly hátránya van:
- Lényegesen lassabb, mint Prometheus
- Sokkal kevesebb helyre integrálódik, mint a Prometheus
- Nehéz figyelmeztetést beállítani számukra
- A mérőszámok sok helyet foglalnak el
- Az irányítópultok mérőszámokkal történő beállítása a Kibanban sokkal bonyolultabb, mint a Grafanban
Általánosságban elmondható, hogy az ELK mérőszámai nehézek, és még nem olyan kényelmesek, mint más megoldásokban, amelyekből ma már sokkal több van, mint csak a Prometheus: TSDB, Victoria Metrics, Cortex stb., stb. Természetesen nagyon szeretnék azonnal egy teljes értékű all-in-one megoldást, de a metricbeat esetében túl sok volt a kompromisszum.
És magának az ELK-stacknek is van néhány nehéz pillanata:
- Nehéz, néha még nagyon nehéz is, ha meglehetősen nagy mennyiségű adatot gyűjt össze
- Tudnod kell főzni - méretezni kell, de ez nem triviális
- Урезанная бесплатная версия — в бесплатной версии нет нормального алертинга, на момент выбора не было и аутентификации
Надо сказать, что в последнее время с последним пунктом стало получше и помимо (beleértve a hitelesítést is) maga az árképzési modell kezdett megváltozni.
De abban az időben, amikor ezt a megoldást telepítettük, egyáltalán nem volt riasztás.
Возможно, можно было попробовать собрать что-то с использованием ElastAlert или других community решений, но все же решили рассмотреть другие альтернативы.
Loki - Grafana - Prométheusz
Jelenleg jó megoldás lehet, ha pusztán a Prometheusra, mint metrikaszolgáltatóra, a Lokira építünk egy felügyeleti veremet, a naplókhoz pedig a vizualizációhoz ugyanazt a Grafana-t használhatjuk.
Sajnos a projekt értékesítési pilotjának indulásakor (19. szeptember-október) a Loki még a 0.3-0.4 béta verzióban volt, és a fejlesztés megkezdésekor még nem tekinthető gyártási megoldásnak. egyáltalán.
Még nincs tapasztalatom a Loki használatában komoly projektekben, de azt mondhatom, hogy a Promtail (rönkgyűjtő ügynök) kiválóan működik mind a bare-metal, mind a kubernetes pod-ok esetében.
KETYEGÉS
Az ELK stack talán legméltóbb (egyetlen?) teljes értékű alternatívája most már csak a TICK stack - Telegraf, InfluxDB, Chronograf, Kapacitor névre hallgatható.
Az alábbiakban részletesebben leírom az összes összetevőt, de az általános ötlet a következő:
- Telegraf - mérőszámok gyűjtésére szolgáló ügynök
- InfluxDB - metrika adatbázis
- Kapacitor – valós idejű metrika processzor a riasztáshoz
- Chronograf - web panel a vizualizációhoz
Az InfluxDB, a Kapacitor és a Chronograf esetében léteznek hivatalos kormánydiagramok, amelyeket a telepítésükhöz használtunk.
Megjegyzendő, hogy az Influx 2.0 (béta) legújabb verziójában a Kapacitor és a Chronograf az InfluxDB részévé vált, és már nem létezik külön-külön
Távíró
egy nagyon könnyű ágens mérőszámok gyűjtésére állapotgépen.
Rengeteg mindent tud figyelni, kezdve a
szerver .
Számos nagyszerű előnye van:
- Gyors és könnyű (Go-ban írva)
- Minimális mennyiségű erőforrást eszik
- A mérőszámok leküldése alapértelmezés szerint
- Összegyűjti az összes szükséges mérőszámot
- Rendszermetrikák beállítások nélkül
- Hardveres mutatók, például az érzékelőktől származó információk
- Nagyon egyszerű saját mérőszámok hozzáadása
- Rengeteg plugin a dobozból
- Rönköket gyűjt
Mivel szükségünk volt a push metrikákra, minden más előny több volt, mint kellemes kiegészítés.
A naplók gyűjtése az ügynök által szintén nagyon kényelmes, mivel nincs szükség további segédprogramok csatlakoztatására a naplózáshoz.
Az Influx a legkényelmesebb élményt kínálja a naplókkal való munkavégzéshez, ha használja .
A Telegraf általában egy nagyszerű eszköz a mérőszámok gyűjtésére, még akkor is, ha nem használja az ICK verem többi részét.
Sokan keresztezik az ELK-val és sok más idősoros adatbázissal a kényelem kedvéért, mivel szinte bárhol tud mérőszámokat írni.
InfluxDB
Az InfluxDB a TICK-verem fő magja, nevezetesen a metrikák idősoros adatbázisa.
Az Influx a mérőszámok mellett naplókat is tud tárolni, bár a naplók számára lényegében ugyanazok a mérőszámok, csak a szokásos numerikus mutatók helyett a fő funkciót egy naplószöveg sora látja el.
Az InfluxDB szintén Go nyelven íródott, és úgy tűnik, hogy sokkal gyorsabban fut az ELK-hoz képest a (nem a legerősebb) fürtünkön.
Az Influx egyik nagyszerű előnye egy nagyon kényelmes és gazdag API adatlekérdezéshez is, amelyet nagyon aktívan használtunk.
Hátrányok - $$$ vagy méretezés?
У TICK стека есть только один обнаруженный нами недостаток — он kedves. Még több.
Mi van a fizetős verzióban, ami az ingyenes verzióban nincs?
Amennyire meg tudtuk érteni, az egyetlen különbség a TICK verem fizetős verziója és az ingyenes verzió között a skálázási képességekben van.
Nevezetesen, magas rendelkezésre állású fürtöt csak itt hozhat létre .
Ha teljes értékű HA-t szeretne, akkor vagy fizetnie kell, vagy mankókat kell használnia. Van pár közösségi megoldás – pl kompetens megoldásnak tűnik, de azt írják, hogy gyártásra nem alkalmas, valamint
- egyszerű megoldás NATS-en keresztüli adatpumpálással (ezt is méretezni kell majd, de ez megoldható).
Kár, de mindkettő elhagyottnak tűnik - nincs friss commit, feltételezem, hogy a probléma az Influx 2.0 új verziójának hamarosan várható megjelenése, amelyben sok minden más lesz (nincs információ méretezés még benne).
Hivatalosan is létezik ingyenes verzió - Valójában ez egy primitív HA, de csak egyensúlyozás révén,
mivel minden adat a terheléselosztó mögötti összes InfluxDB-példányba lesz írva.
У него есть некоторые mint a pontok felülírásával kapcsolatos lehetséges problémák és a metrikák alapjainak előzetes létrehozásának szükségessége
(ami automatikusan megtörténik az InfluxDB-vel végzett normál munka során).
Ezen kívül , ez további többletköltséget jelent a duplikált metrikákhoz (mind a feldolgozás, mind a tárolás), amelyekre esetleg nincs szüksége, de nincs mód szétválasztásukra.
Victoria Metrics?
Ennek eredményeként annak ellenére, hogy a fizetős skálázáson kívül mindenben teljesen elégedettek voltunk a TICK stack-el, úgy döntöttünk, hogy megnézzük, vannak-e olyan ingyenes megoldások, amelyek helyettesíthetik az InfluxDB adatbázist, miközben elhagyjuk a többi T_CK komponenst.
Sok idősoros adatbázis létezik, de a legígéretesebb a Victoria Metrics, amely számos előnnyel rendelkezik:
- Быстрая и легкая, по крайней мере по результатам
- Létezik egy fürt verzió, amiről most még jó kritikák is születnek
- Tud szilánkokra törni
- Поддерживает InfluxDB протокол
Nem szándékoztunk teljesen egyedi veremeket építeni Victoria alapján, és a fő remény az volt, hogy az InfluxDB beugró helyettesítőjeként használhatjuk.
Sajnos ez nem lehetséges, annak ellenére, hogy az InfluxDB protokoll támogatott, csak a mérőszámok rögzítésére működik - csak a Prometheus API érhető el „kívül”, ami azt jelenti, hogy nem lehet rá állítani a Chronograft.
Ezenkívül a metrikák csak numerikus értékeket támogatnak (egyéni metrikákhoz karakterlánc-értékeket használtunk - erről bővebben a részben ).
Nyilvánvalóan ugyanezen okból a virtuális gép nem tud naplókat tárolni, mint az Influx.
Azt is meg kell jegyezni, hogy az optimális megoldás keresése idején a Victoria Metrics még nem volt annyira népszerű, a dokumentáció sokkal kisebb volt és a funkcionalitás is gyengébb volt.
(Nem emlékszem a klaszterverzió és a sharding részletes leírására).
Alap kiválasztása
Ennek eredményeként az a döntés született, hogy a pilot esetében továbbra is egyetlen InfluxDB csomópontra korlátozzuk magunkat.
Ennek a választásnak több fő oka is volt:
- Nagyon tetszett nekünk a TICK verem teljes funkcionalitása
- Sikerült már telepítenünk, és remekül működött
- A határidők fogytak, és nem sok idő maradt más lehetőségek tesztelésére.
- Nem számítottunk ekkora terhelésre
Nem sok robogónk volt a pilot első fázisában, és a fejlesztés során végzett tesztelés sem tárt fel teljesítménybeli problémát.
Ezért úgy döntöttünk, hogy ehhez a projekthez elegendő egy Influx csomópont, anélkül, hogy skálázásra lenne szükség (lásd a következtetéseket a végén).
Döntöttünk a veremről és az alapról – most a TICK verem többi összetevőjéről.
Kondenzátor
A Kapacitor a TICK verem része, egy olyan szolgáltatás, amely valós időben képes figyelni az adatbázisba belépő mérőszámokat, és szabályok alapján különféle műveleteket végrehajtani.
Általánosságban elmondható, hogy az esetleges anomáliák nyomon követésére és a gépi tanulásra szolgáló eszközként van elhelyezve (nem vagyok benne biztos, hogy ezekre a funkciókra van kereslet), de használatának legnépszerűbb esete általánosabb - riasztás.
Így használtuk az értesítésekhez. Slack riasztásokat állítottunk be, amikor egy adott robogó offline állapotba került, és ugyanez történt az intelligens töltők és a fontos infrastruktúra-elemek esetében is.
Ez lehetővé tette a problémák gyors reagálását, valamint értesítések fogadását arról, hogy minden visszatért a normális kerékvágásba.
Egy egyszerű példa: elromlott vagy valamilyen oknál fogva lemerült a „dobozunk” tápellátására szolgáló kiegészítő akkumulátor; egyszerűen egy új beszerelésével egy idő után kapunk értesítést, hogy a robogó működése helyreállt.
Az Influx 2.0-ban a Kapacitor a DB részévé vált
Kronográf
Sokféle UI-megoldást láttam megfigyelésre, de elmondhatom, hogy funkcionalitás és UX tekintetében semmi sem hasonlítható a Chronografhoz.
Elkezdtük használni a TICK veremét, furcsa módon a Grafan webes felülettel.
Nem írom le a funkcionalitását, mindenki ismeri a széles körű beállítási lehetőségeit.
A Grafana azonban továbbra is teljesen univerzális hangszer, míg a Chronograf elsősorban az Influx-szal való használatra készült.
És természetesen ennek köszönhetően a Chronograf sokkal okosabb vagy kényelmesebb funkcionalitást engedhet meg magának.
A Chronograf-pal való munka során talán az a fő kényelem, hogy megtekintheti az InfluxDB belsejét az Explore segítségével.
Úgy tűnik, hogy a Grafana szinte azonos funkcionalitással rendelkezik, de a valóságban a Chronografban a műszerfal beállítása néhány egérkattintással elvégezhető (egyidejűleg az ottani vizualizációt nézve), míg a Grafana esetében előbb-utóbb a JSON-konfiguráció szerkesztéséhez (természetesen a Chronograf lehetővé teszi a kézzel konfigurált dashák feltöltését és szükség esetén JSON-ként való szerkesztését - de soha nem kellett hozzájuk nyúlnom, miután létrehoztam őket a felhasználói felületen).
A Kibana sokkal gazdagabb képességekkel rendelkezik a műszerfalak és vezérlők létrehozásához, de az ilyen műveletek felhasználói élménye nagyon összetett.
Egy kényelmes irányítópult létrehozásához alapos ismeretekre lesz szükség. És bár a Chronograf műszerfalainak funkcionalitása kisebb, készítésük és testreszabásuk sokkal egyszerűbb.
Maguk a műszerfalak a kellemes vizuális stíluson kívül valójában nem különböznek a Grafana vagy Kibana műszerfalaitól:
Így néz ki a lekérdező ablak:
Fontos megjegyezni többek között, hogy az InfluxDB adatbázisban található mezők típusának ismeretében maga a kronográf is néha automatikusan segíthet a Lekérdezés megírásában vagy a megfelelő összesítő függvény, például az átlag kiválasztásában.
És természetesen a Chronograf a lehető legkényelmesebb a naplók megtekintéséhez. Ez így néz ki:
По умолчанию Influx логи заточны под использование syslog и поэтому в них есть важный параметр — severity.
Különösen hasznos a felül található grafikon, amelyen láthatók a fellépő hibák, és a szín azonnal jól mutatja, ha nagyobb a súlyosság.
Néhányszor fontos hibákat fogtunk így, amikor megnéztük az elmúlt hét naplóit, és egy piros tüskét láttunk.
Конечно, в идеале было бы настроить алертинг на такие ошибки, благо у нас уже было все для этого.
Egy darabig még ezt is bekapcsoltuk, de a pilot előkészítése során kiderült, hogy elég sok hibát kapunk (többek között olyan rendszerhibákat is, mint az LTE hálózat elérhetetlensége), ami a Slack csatornát is „spammel” sokat, anélkül, hogy bármilyen problémát okozna.
A helyes megoldás az lenne, ha kezelnénk a legtöbb ilyen típusú hibát, beállítanánk a súlyosságukat, és csak ezután engedélyeznénk a riasztást.
Ily módon csak az új vagy fontos hibák kerülnek a Slackbe. Egyszerűen nem volt elég idő egy ilyen beállításra a szűkös határidők miatt.
Hitelesítés
Azt is érdemes megemlíteni, hogy a Chronograf támogatja az OAuth-ot és az OIDC-t hitelesítésként.
Ez nagyon kényelmes, mivel lehetővé teszi, hogy egyszerűen csatolja a szerverhez, és teljes értékű SSO-t hozzon létre.
В нашем случае — сервером был — a megfigyeléshez való csatlakozáshoz használták, de ugyanezt a szervert használták a robogók és a háttérbe irányuló kérések hitelesítésére is.
"Adminisztrátor"
Последний компонент, который я опишу — это наша самописная "админка" на Vue.
Alapvetően ez csak egy önálló szolgáltatás, amely egyszerre jeleníti meg a robogó-információkat saját adatbázisainkból, mikroszolgáltatásainkból és az InfluxDB-ből származó metrikaadatokat.
Ezen kívül számos adminisztratív funkciót áthelyeztek ide, például a vészhelyzeti újraindítást vagy a zár távolról történő kinyitását a támogató csapat számára.
Voltak térképek is. Említettem már, hogy a Chronograf helyett a Grafana-val kezdtük, mert a Grafana számára elérhetőek a térképek plugin formájában, amelyeken a robogók koordinátáit láthattuk. Sajnos a Grafana térkép widgetek képességei nagyon korlátozottak, és ennek eredményeként néhány nap alatt sokkal könnyebb volt saját webes alkalmazást írni térképekkel, hogy ne csak a koordinátákat láthassa, hanem megjelenítse is. a robogó által megtett útvonalat, képes legyen szűrni az adatokat a térképen stb. (mindegy olyan funkció, amit egy egyszerű műszerfalon nem tudtunk konfigurálni).
Az Influx egyik már említett előnye, hogy könnyedén létrehozhatja saját mérőszámait.
Это позволяет использовать его для огромного множества сценариев.
Igyekeztünk ott minden hasznos információt rögzíteni: akkumulátor töltöttséget, zár állapotát, érzékelők teljesítményét, bluetooth-ot, GPS-t és sok egyéb állapotfelmérést.
Mindezt megjelenítettük az adminisztrációs panelen.
Számunkra természetesen a robogó üzemállapota volt a legfontosabb kritérium - sőt, az Influx ezt maga is ellenőrzi, és a Nodes részben „zöld lámpákkal” jelzi.
Ezt a függvény végzi el - arra használtuk, hogy megértsük a dobozunk teljesítményét, és ugyanezeket a figyelmeztetéseket küldjük a Slacknek.
Кстати, мы называли скутеры по именами персонажей из Симпсонов — так их было удобно отличать друг от друга
És általában szórakoztatóbb volt így. Állandóan hallatszottak az olyan mondatok, mint „Srácok, Smithers meghalt!”.
Karakterlánc metrikák
Fontos, hogy az InfluxDB lehetővé tegye nem csak numerikus értékek tárolását, mint a Victoria Metrics esetében.
Úgy tűnik, ez nem olyan fontos - elvégre a naplókon kívül bármilyen mérőszám tárolható számok formájában (csak hozzá kell adni az ismert állapotokhoz való leképezést - egyfajta enum)?
A mi esetünkben volt legalább egy forgatókönyv, amikor a karakterlánc-metrikák nagyon hasznosak voltak.
Történt ugyanis, hogy „okostöltőink” szállítója egy harmadik fél volt, nem rendelkeztünk a fejlesztési folyamattal és azokkal az információkkal, amelyeket ezek a töltők szolgáltathatnak.
Ennek eredményeként a töltési API messze nem volt ideális, de a fő probléma az volt, hogy nem mindig tudtuk megérteni az állapotukat.
Тут на помощь и пришел Influx. Мы просто-напросто записывали приходящий нам строковый status в поле базы InfluxDB без изменений.
Egy ideig csak olyan értékek kerültek oda, mint az „online” és az „offline”, amelyek alapján az adminisztrációs panelünkön információk jelennek meg, és értesítéseket küldtek a Slacknek. Egy ponton azonban ott is megjelentek az olyan értékek, mint a „lekapcsolva”.
Mint később kiderült, ezt az állapotot a kapcsolat megszakadása után egyszer küldték el, ha a töltő bizonyos számú próbálkozás után nem tudott kapcsolatot létesíteni a szerverrel.
Így, ha csak egy rögzített értékkészletet használunk, előfordulhat, hogy ezeket a változásokat nem látjuk a megfelelő időben a firmware-ben.
És általában a karakterlánc-metrikák sokkal több felhasználási lehetőséget biztosítanak, gyakorlatilag bármilyen információt rögzíthetünk bennük. Bár természetesen ezt az eszközt is óvatosan kell használni.
Az InfluxDB-ben a szokásos mérőszámok mellett GPS helyadatokat is rögzítettünk. Ez hihetetlenül hasznos volt a robogók helyzetének figyeléséhez az adminisztrációs panelünkön.
Valójában mindig tudtuk, hol és melyik robogó van abban a pillanatban, amikor szükségünk van rá.
Ez nagyon hasznos volt számunkra, amikor robogót kerestünk (lásd a következtetéseket a végén).
Мониторинг инфраструктуры
Magukon a robogókon kívül a teljes (meglehetősen kiterjedt) infrastruktúránkat is figyelemmel kellett kísérnünk.
Egy nagyon általános architektúra valahogy így nézett ki:
Если выделить чисто стек мониторинга, то он выглядит следующим образом:
Amit szeretnénk ellenőrizni a felhőben:
- adatbázisok
- Kulcsköpeny
- Mikroszolgáltatások
Mivel minden felhőszolgáltatásunk Kubernetesben található, jó lenne információkat gyűjteni az állapotáról.
Szerencsére a Telegraf már a dobozból is rengeteg mérőszámot tud összegyűjteni a Kubernetes-fürt állapotáról, a Chronograf pedig azonnal gyönyörű műszerfalakat kínál ehhez.
Elsősorban a podok teljesítményét és a memóriafelhasználást figyeltük. Esés esetén Slack riasztás.
Для отслеживания подов в Kubernetes есть два пути: DaemonSet и Sidecar.
Mindkét módszert részletesen ismertetjük .
Telegraf Sidecart használtunk, és a mérőszámok mellett pod naplókat is gyűjtöttünk.
A mi esetünkben a rönkökkel kellett bütykölnünk. Annak ellenére, hogy a Telegraf képes lekérni a naplókat a Docker API-ból, egy egységes naplógyűjteményt akartunk létrehozni a végeszközeinkkel, és ehhez konfiguráltuk a syslog-ot a konténerekhez. Lehet, hogy ez a megoldás nem volt szép, de a munkájára nem lehetett panasz, és a naplók jól megjelentek a Chronografban.
Monitor monitorozás???
A végén felmerült a monitoring rendszerek ősrégi kérdése, de szerencsére vagy sajnos egyszerűen nem volt erre elég időnk.
Bár a Telegraf könnyedén elküldheti saját mérőszámait, vagy mérőszámokat gyűjthet az InfluxDB adatbázisból, hogy elküldje akár ugyanannak az Influxnak, vagy valahova máshová.
Álláspontja
Milyen következtetéseket vontunk le a pilot eredményeiből?
Hogyan lehet monitorozni?
Először is, a TICK stack teljes mértékben megfelelt az elvárásainknak, és még több lehetőséget adott nekünk, mint amire eredetileg számítottunk.
Minden funkció megvolt, amire szükségünk volt. Minden, amit vele csináltunk, probléma nélkül működött.
termelékenység
Az ingyenes verzióban található TICK-verem fő problémája a méretezési képességek hiánya. Ez nem jelentett problémát számunkra.
Pontos terhelési adatokat/számokat nem gyűjtöttünk, de egyszerre kb 30 robogóról gyűjtöttünk adatokat.
Mindegyikük több mint három tucat mérőszámot gyűjtött össze. Ezzel egy időben az eszközökről naplókat is gyűjtöttek. Az adatgyűjtés és -küldés 10 másodpercenként történt.
Fontos megjegyezni, hogy másfél hetes pilot után, amikor a „gyerekkori problémák” nagy részét kijavították, és a legfontosabb problémák már megoldódtak, csökkenteni kellett a szerverre való adatküldés gyakoriságát. 30 másodperc. Ez azért vált szükségessé, mert az LTE SIM-kártyáink forgalma gyorsan eltűnt.
A forgalom nagy részét a naplók emésztették fel, maguk a mérőszámok még 10 másodperces időközönként sem pazarolták el.
Ennek eredményeként egy idő után teljesen letiltottuk a naplók gyűjtését az eszközökön, mivel a konkrét problémák már folyamatos gyűjtés nélkül is nyilvánvalóak voltak.
Egyes esetekben, ha a naplók megtekintése továbbra is szükséges volt, egyszerűen WireGuard-on keresztül csatlakoztunk VPN-en keresztül.
Hozzáteszem azt is, hogy az egyes környezetek elkülönültek egymástól, és a fent leírt terhelés csak az éles környezetre vonatkozott.
A fejlesztői környezetben külön InfluxDB példányt hoztunk létre, amely továbbra is 10 másodpercenként gyűjtött adatokat, és nem ütköztünk teljesítményproblémákba.
TICK – ideális kis és közepes projektekhez
Ezen információk alapján arra a következtetésre jutok, hogy a TICK-verem ideális viszonylag kis projektekhez, vagy olyan projektekhez, amelyeknél semmiféle HighLoad nem várható.
Ha nincs több ezer pod-ja vagy több száz gépe, még egy InfluxDB-példány is tökéletesen kezeli a terhelést.
Egyes esetekben elégedett lehet az Influx Relay-vel, mint primitív magas rendelkezésre állású megoldással.
És természetesen senki sem akadályozza meg abban, hogy „függőleges” skálázást állítson be, és egyszerűen különböző szervereket rendeljen hozzá a különböző típusú metrikákhoz.
Ha nem biztos a monitorozási szolgáltatások várható terhelésében, vagy garantáltan nagyon „nehéz” architektúrája lesz/lesz, nem javaslom a TICK verem ingyenes verziójának használatát.
Természetesen egyszerű megoldás a vásárlás — но тут я не могу как-то прокомментировать, так как сам не знаком с тонкостями. Кроме того, что это очень дорого и точно не подойдет для мелких компаний.
Ebben az esetben ma azt javaslom, hogy a Victoria Metrics segítségével gyűjtsön metrikákat és a Loki használatával naplózza.
Правда, снова оговорюсь, что Loki/Grafana значительно менее удобны (в виду своей большей универсальности) чем готовый TICK, но зато они бесплатны.
Fontos: az itt leírt összes információ az Influx 1.8-as verziójára vonatkozik, jelenleg az Influx 2.0 megjelenése előtt áll.
Bár nem volt alkalmam kipróbálni harci körülmények között, és nehéz következtetéseket levonni a fejlesztésekről, a felület határozottan még jobb lett, az architektúra egyszerűsödött (kapacitor és kronográf nélkül),
появились темплейты ("киллер фича" — ). De sajnos jelenleg a 2-es verzióban nincs meg az a kulcs, amiért az első verziót választottuk – nincs naplógyűjtemény.
Ez a funkció az Influx 2.0-ban is megjelenik, de még csak hozzávetőleges határidőket sem találtunk.
Hogyan ne készítsünk IoT-platformokat (most)
Végül a pilot elindítása után mi magunk állítottuk össze saját teljes értékű IoT stackünket, szabványunknak megfelelő alternatíva hiányában.
A közelmúltban azonban béta verzióban is elérhető - kár, hogy nem volt ott, amikor elkezdtük a projektet.
Teljesen elégedettek vagyunk a végeredménnyel és a saját magunk által összeállított Ansible + TICK + WireGuard alapú platformmal. De ma azt javaslom, hogy nézze meg közelebbről a Balenát, mielőtt saját maga építi fel saját IoT-platformját.
Mert végső soron a legtöbbet képes elvégezni, és az OpenBalena ingyenes és nyílt forráskódú.
Már tudja, hogyan kell nem csak frissítéseket küldeni, hanem a VPN már be van építve és IoT-környezetben való használatra szabott.
És nemrég még ki is adták a sajátjukat , amely könnyen csatlakozik ökoszisztémájukhoz.
Hé, mi van az eltűnt robogóval?
Így a robogó, "Ralph", nyomtalanul eltűnt.
Azonnal rohantunk megnézni a térképet az „admin panelünkben”, az InfluxDB GPS-metrikus adataival.
A megfigyelési adatoknak köszönhetően könnyen megállapítottuk, hogy a robogó múlt nap 21 óra körül hagyta el a parkolót, körülbelül fél órát ment valamelyik területre és hajnali 00-ig állt valamelyik német ház mellett.
Hajnali 5 óra után nem érkezett megfigyelési adat – ez azt jelentette, hogy vagy a kiegészítő akkumulátor teljesen lemerült, vagy a támadó végre rájött, hogyan távolítsa el az intelligens hardvert a robogóról.
Несмотря на это, по тому адресу, где находился скутер все же была вызвана полиция. Скутера там не оказалось.
Ezen azonban a ház tulajdonosa is meglepődött, hiszen tegnap este valóban ezzel a robogóval ment haza az irodából.
Как выяснилось, один из сотрудников поддержки приехал рано утром и забрал скутер, увидев, что у него полностью разрядилась дополнительная батарея и повез его (пешком) на парковку. А дополнительная батарея вышла из строя из-за попадания влаги.
Elloptuk magunktól a robogót. Egyébként nem tudom, hogyan és ki oldotta meg a kérdést a rendőrségi üggyel kapcsolatban, de a megfigyelés tökéletesen működött...
Forrás: will.com