Rok temu uruchomiliśmy pilotażową wersję projektu promocyjnego dla .
Początkowo projekt nosił nazwę Road-To-Barcelona, później Road-To-Berlin (stąd na screenach R2B), a ostatecznie otrzymał nazwę xRide.
Główna idea projektu była następująca: zamiast scentralizowanej usługi wynajmu samochodów lub skuterów (mówimy o hulajnogach, czyli motocyklach elektrycznych, a nie o hulajnogach/skuterach), chcieliśmy stworzyć platformę do zdecentralizowanego wynajmu. O trudnościach, jakie napotkaliśmy .
Początkowo projekt skupiał się na samochodach, jednak ze względu na terminy, wyjątkowo długą komunikację z producentami i ogromną liczbę obostrzeń bezpieczeństwa, na pilota wybrano hulajnogi elektryczne.
Użytkownik zainstalował na telefonie aplikację iOS lub Android, podszedł do lubianej przez siebie hulajnogi, po czym telefon i hulajnoga nawiązały połączenie peer-to-peer, doszło do wymiany ETH i użytkownik mógł rozpocząć jazdę włączając hulajnogę poprzez telefon. Na koniec wyjazdu można było także opłacić wyjazd za pomocą Ethereum z portfela użytkownika w telefonie.
Oprócz hulajnóg użytkownik zobaczył w aplikacji „inteligentne ładowarki”, odwiedzając które użytkownik mógł samodzielnie wymienić aktualny stan baterii, gdyby był niski.
Tak mniej więcej wyglądał nasz pilotaż, wystartowany we wrześniu ubiegłego roku w dwóch niemieckich miastach: Bonn i Berlinie.
I wtedy pewnego dnia wczesnym rankiem w Bonn nasz zespół wsparcia (zlokalizowany na miejscu w celu utrzymania hulajnóg w dobrym stanie) został zaalarmowany: jedna ze hulajnóg zniknęła bez śladu.
Jak go znaleźć i zwrócić?
W tym artykule opowiem o tym, ale najpierw – o tym, jak zbudowaliśmy własną platformę IoT i jak ją monitorowaliśmy.
Co i dlaczego monitorować: hulajnogi, infrastrukturę, stacje ładowania?
Co więc chcieliśmy monitorować w naszym projekcie?
Przede wszystkim są to same hulajnogi – hulajnogi elektryczne same w sobie są dość drogie, nie można rozpocząć takiego projektu bez odpowiedniego przygotowania, a jeśli to możliwe, chcemy zebrać jak najwięcej informacji o hulajnogach: o ich lokalizacji, poziomie naładowania itp.
Dodatkowo chciałbym monitorować stan własnej infrastruktury IT - baz danych, usług i wszystkiego co potrzebne do działania. Niezbędne było także monitorowanie stanu „inteligentnych ładowarek”, na wypadek gdyby uległy one awarii lub wyczerpały się pełne akumulatory.
Hulajnogi
Jakie były nasze hulajnogi i co chcieliśmy o nich wiedzieć?
Pierwszą i najważniejszą rzeczą są współrzędne GPS, ponieważ dzięki nim możemy zrozumieć, gdzie się znajdują i dokąd się poruszają.
Następnie następuje ładowanie akumulatora, dzięki któremu możemy stwierdzić, że ładowanie hulajnogi dobiega końca i wysłać sokowirówkę lub przynajmniej ostrzec użytkownika.
Oczywiście konieczne jest również sprawdzenie, co dzieje się z naszymi komponentami sprzętowymi:
- czy bluetooth działa?
- czy sam moduł GPS działa?
- Mieliśmy też problem z tym, że GPS potrafił wysyłać błędne współrzędne i się zawieszał, a to można było stwierdzić dopiero po dodatkowym sprawdzeniu hulajnogi,
i jak najszybciej powiadom obsługę techniczną, aby rozwiązać problem
- Mieliśmy też problem z tym, że GPS potrafił wysyłać błędne współrzędne i się zawieszał, a to można było stwierdzić dopiero po dodatkowym sprawdzeniu hulajnogi,
I na koniec: sprawdzenie oprogramowania, począwszy od systemu operacyjnego i procesora, obciążenia sieci i dysku, a skończywszy na sprawdzeniu własnych modułów, które są dla nas bardziej specyficzne (, ).
sprzęt komputerowy
Jaka była nasza „żelazna” część?
Biorąc pod uwagę możliwie najkrótszy czas i potrzebę szybkiego prototypowania, wybraliśmy najłatwiejszą opcję wdrożenia i doboru komponentów - Raspberry Pi.
Oprócz samego Rpi mieliśmy niestandardową płytkę (którą sami opracowaliśmy i zamówiliśmy z Chin, aby przyspieszyć proces montażu finalnego rozwiązania) oraz zestaw podzespołów - przekaźnik (do włączania/wyłączania hulajnogi), czytnik ładowania akumulatorów, modem, anteny. Wszystko to zostało kompaktowo zapakowane w specjalne „pudełko xRide”.
Warto też zaznaczyć, że całe pudło zasilane było z dodatkowego power banku, który z kolei zasilany był z głównego akumulatora hulajnogi.
Umożliwiło to skorzystanie z monitoringu i włączenie hulajnogi nawet po zakończeniu podróży, gdyż główny akumulator został wyłączony natychmiast po przekręceniu kluczyka w stacyjce do pozycji „wyłączony”.
Doker? Zwykły Linux? i wdrożenie
Wróćmy do monitoringu, a więc Malinka – co mamy?
Jedną z pierwszych rzeczy, które chcieliśmy zastosować, aby przyspieszyć proces wdrażania, aktualizacji i dostarczania komponentów na urządzenia fizyczne, był Docker.
Niestety, szybko stało się jasne, że Docker na RPi, mimo że działa, niesie ze sobą spore obciążenie, szczególnie w zakresie zużycia energii.
Różnica przy korzystaniu z „natywnego” systemu operacyjnego, choć nie tak duża, była jednak wystarczająca, abyśmy uważali na możliwość zbyt szybkiej utraty ładunku.
Drugim powodem była jedna z naszych partnerskich bibliotek na Node.js (sic!) - jedyny komponent systemu, który nie został napisany w Go/C/C++.
Autorom biblioteki nie udało się dostarczyć działającej wersji w żadnym z „rodzimych” języków.
Nie tylko sam węzeł nie jest najbardziej eleganckim rozwiązaniem dla urządzeń o niskiej wydajności, ale sama biblioteka bardzo pochłaniała zasoby.
Zdaliśmy sobie sprawę, że nawet gdybyśmy chcieli, używanie Dockera byłoby dla nas zbyt dużym obciążeniem. Wyboru dokonano na korzyść natywnego systemu operacyjnego i pracy bezpośrednio pod nim.
OS
W rezultacie ponownie wybraliśmy najprostszą opcję jako system operacyjny i użyliśmy Raspbian (kompilacja Debiana dla Pi).
Całe nasze oprogramowanie piszemy w Go, więc w Go napisaliśmy także główny moduł agenta sprzętowego w naszym systemie.
To on odpowiada za pracę z GPS, Bluetooth, odczyt stanu naładowania, włączenie hulajnogi itp.
Wdrożyć
Od razu pojawiło się pytanie o potrzebę wdrożenia mechanizmu dostarczania aktualizacji do urządzeń (OTA) – zarówno aktualizacji samego naszego agenta/aplikacji, jak i aktualizacji samego systemu operacyjnego/firmware (ponieważ nowe wersje agenta mogą wymagać aktualizacji jądra lub komponenty systemu, biblioteki itp.).
Po dość długiej analizie rynku okazało się, że rozwiązań umożliwiających dostarczanie aktualizacji do urządzenia jest całkiem sporo.
Od stosunkowo prostych, zorientowanych głównie na aktualizację/podwójne uruchamianie narzędzi, takich jak swaupd/SWUpdate/OSTree, po pełnoprawne platformy, takie jak Mender i Balena.
Przede wszystkim uznaliśmy, że interesują nas rozwiązania typu end-to-end, dlatego wybór od razu padł na platformy.
Bardzo został wykluczony ze względu na fakt, że faktycznie używa tego samego Dockera w swoim balenaEngine.
Ale zauważam, że mimo to stale korzystaliśmy z ich produktu do oprogramowania sprzętowego flash na kartach SD - proste i niezwykle wygodne narzędzie do tego.
Dlatego ostatecznie wybór padł . Mender to kompletna platforma do montażu, dostarczania i instalowania oprogramowania sprzętowego.
Ogólnie platforma wygląda świetnie, ale zbudowanie poprawnej wersji naszego oprogramowania za pomocą narzędzia Mender Builder zajęło nam około półtora tygodnia.
Im bardziej zagłębialiśmy się w zawiłości jego użycia, tym bardziej stawało się jasne, że aby go w pełni wdrożyć, potrzebowalibyśmy znacznie więcej czasu, niż mieliśmy.
Niestety, nasze napięte terminy sprawiły, że byliśmy zmuszeni zrezygnować z korzystania z Mendera i wybrać jeszcze prostszy.
Wiarygodne
Najprostszym rozwiązaniem w naszej sytuacji było użycie Ansible. Na początek wystarczyło kilka podręczników.
Ich istotą było to, że po prostu łączyliśmy się z hosta (serwer CI) przez ssh z naszymi rasberrymi i rozprowadzaliśmy do nich aktualizacje.
Na samym początku wszystko było proste – trzeba było być w tej samej sieci co urządzenia, nalewanie odbywało się poprzez Wi-Fi.
W biurze było po prostu kilkanaście testowych malin podłączonych do tej samej sieci, każde urządzenie miało statyczny adres IP również określony w Inwentarzu Ansible.
To właśnie Ansible dostarczyło naszego agenta monitorującego na urządzenia końcowe
3G / LTE
Niestety, ten przypadek użycia Ansible mógł działać tylko w trybie programistycznym, zanim mieliśmy rzeczywiste hulajnogi.
Ponieważ hulajnogi, jak rozumiesz, nie są podłączone do jednego routera Wi-Fi, ciągle czekając na aktualizacje w sieci.
W rzeczywistości hulajnogi nie mogą mieć w ogóle żadnego połączenia poza mobilnym 3G/LTE (a nawet wtedy nie zawsze).
To od razu narzuca wiele problemów i ograniczeń, takich jak niska prędkość połączenia i niestabilna komunikacja.
Ale najważniejsze jest to, że w sieci 3G/LTE nie możemy po prostu polegać na statycznym IP przypisanym do sieci.
Częściowo rozwiązują to niektórzy dostawcy kart SIM, istnieją nawet specjalne karty SIM przeznaczone dla urządzeń IoT ze statycznymi adresami IP. Ale nie mieliśmy dostępu do takich kart SIM i nie mogliśmy korzystać z adresów IP.
Oczywiście były pomysły, aby zrobić jakąś rejestrację adresów IP, czyli odkrywanie usług gdzieś jak Consul, ale musieliśmy porzucić takie pomysły, ponieważ w naszych testach adres IP mógł się zbyt często zmieniać, co prowadziło do dużej niestabilności.
Z tego powodu najwygodniejszym zastosowaniem do dostarczania metryk nie byłoby użycie modelu pull, w którym udajemy się do urządzeń po niezbędne metryki, ale push, dostarczając metryki z urządzenia bezpośrednio na serwer
VPN
Jako rozwiązanie tego problemu wybraliśmy VPN - konkretnie .
Klienci (skutery) na starcie systemu łączyli się z serwerem VPN i mogli się z nimi połączyć. Ten tunel był używany do dostarczania aktualizacji.
Teoretycznie ten sam tunel mógłby służyć do monitoringu, ale takie połączenie było bardziej skomplikowane i mniej niezawodne niż proste push.
Zasoby w chmurze
Na koniec konieczne jest monitorowanie naszych usług chmurowych i baz danych, ponieważ używamy do nich Kubernetesa, idealnie, aby wdrożenie monitorowania w klastrze było jak najprostsze. Idealnie, używając , ponieważ w większości przypadków używamy go do wdrożenia. No i oczywiście do monitorowania chmury trzeba zastosować te same rozwiązania, co w przypadku samych hulajnóg.
Dany
Uff, chyba uporządkowaliśmy opis, zróbmy listę tego, czego potrzebowaliśmy:
- Szybkie rozwiązanie, ponieważ monitorowanie jest konieczne już w procesie rozwoju
- Objętość/ilość – potrzebnych jest wiele wskaźników
- Wymagane jest zbieranie dzienników
- Niezawodność — dane mają kluczowe znaczenie dla powodzenia uruchomienia
- Nie możesz używać modelu pull - potrzebujesz push
- Potrzebujemy ujednoliconego monitorowania nie tylko sprzętu, ale także chmury
Ostateczny obraz wyglądał mniej więcej tak
Wybór stosu
Stanęliśmy więc przed pytaniem o wybór stosu monitorującego.
Przede wszystkim szukaliśmy najbardziej kompletnego rozwiązania typu all-in-one, które jednocześnie zaspokoi wszystkie nasze wymagania, ale jednocześnie będzie na tyle elastyczne, aby dostosować jego zastosowanie do naszych potrzeb. Mimo to mieliśmy wiele ograniczeń nałożonych na nas ze względu na sprzęt, architekturę i terminy.
Istnieje ogromna różnorodność rozwiązań monitorujących, zaczynając od pełnoprawnych systemów, takich jak , lub a kończąc na gotowych rozwiązaniach do zarządzania flotą.
Początkowo to drugie wydawało się dla nas idealnym rozwiązaniem, jednak niektóre nie miały pełnego monitoringu, inne miały mocno ograniczone możliwości darmowych wersji, a jeszcze inne po prostu nie pokrywały naszych „potrzeb” lub nie były wystarczająco elastyczne, aby dopasować się do naszych scenariuszy. Niektóre są po prostu przestarzałe.
Po przeanalizowaniu szeregu podobnych rozwiązań szybko doszliśmy do wniosku, że łatwiej i szybciej byłoby samemu złożyć podobny stos. Tak, będzie to trochę bardziej skomplikowane niż wdrożenie całkowicie gotowej platformy do zarządzania flotą, ale nie będziemy musieli iść na kompromisy.
Niemal na pewno w całej ogromnej obfitości rozwiązań znalazło się już gotowe rozwiązanie, które w pełni by nam odpowiadało, jednak w naszym przypadku znacznie szybciej było samemu złożyć konkretny stos i dostosować go „dla siebie”, niż testowanie gotowych produktów.
Przy tym wszystkim nie dążyliśmy do samodzielnego złożenia całej platformy monitorującej, ale poszukiwaliśmy jak najbardziej funkcjonalnych „gotowych” stosów, jedynie z możliwością ich elastycznej konfiguracji.
(B) ELK?
Pierwszym rozwiązaniem, które faktycznie brano pod uwagę, był dobrze znany stos ELK.
Właściwie to powinno się nazywać BELK, bo od Beatsów wszystko się zaczyna -
Oczywiście ELK to jedno z najsłynniejszych i najpotężniejszych rozwiązań w zakresie monitoringu, a tym bardziej gromadzenia i przetwarzania logów.
Zamierzaliśmy, aby ELK służył do gromadzenia logów i długoterminowego przechowywania metryk uzyskanych z Prometheusa.
Do wizualizacji możesz użyć Grafana.
W rzeczywistości nowy stos ELK może niezależnie zbierać metryki (metricbeat), a Kibana może je również wyświetlać.
Mimo to ELK początkowo wyrósł z logów i jak dotąd funkcjonalność metryk ma wiele poważnych wad:
- Znacząco wolniejszy od Prometeusza
- Integruje się w znacznie mniejszej liczbie miejsc niż Prometeusz
- Trudno jest skonfigurować dla nich alerty
- Metryki zajmują dużo miejsca
- Konfigurowanie dashboardów z metrykami w Kibanie jest znacznie bardziej skomplikowane niż w Grafanie
Ogólnie metryki w ELK są ciężkie i jeszcze nie tak wygodne jak w innych rozwiązaniach, których jest teraz znacznie więcej niż tylko Prometheus: TSDB, Victoria Metrics, Cortex itp. itd. Oczywiście bardzo chciałbym mieć od razu pełnoprawne rozwiązanie typu all-in-one, jednak w przypadku metricbeat było za dużo kompromisów.
A sam stos ELK ma wiele trudnych momentów:
- Jest ciężki, czasem nawet bardzo ciężki, jeśli zbierzesz dość dużą ilość danych
- Trzeba „wiedzieć, jak to ugotować” – trzeba to skalować, ale nie jest to trywialne
- Okrojona wersja darmowa - wersja darmowa nie posiada normalnego powiadamiania, a w momencie wyboru nie było uwierzytelniania
Muszę powiedzieć, że ostatnio ostatni punkt stał się lepszy i na dodatek (w tym uwierzytelnianie) sam model cenowy zaczął się zmieniać.
Ale w momencie, gdy mieliśmy wdrożyć to rozwiązanie, nie było żadnego alertu.
Być może moglibyśmy spróbować zbudować coś przy użyciu ElastAlert lub innych rozwiązań społecznościowych, ale mimo to zdecydowaliśmy się rozważyć inne alternatywy.
Loki – Grafana – Prometeusz
W tej chwili dobrym rozwiązaniem mogłoby być zbudowanie stosu monitorującego opartego wyłącznie na Prometheusie jako dostawcy metryk, Lokim na logi, a do wizualizacji można wykorzystać tę samą Grafanę.
Niestety w momencie rozpoczęcia pilotażu sprzedażowego projektu (wrzesień-październik 19) Loki znajdował się jeszcze w wersji beta 0.3-0.4 i w momencie rozpoczęcia rozwoju nie można go było uważać za rozwiązanie produkcyjne w ogóle.
Nie mam jeszcze doświadczenia w używaniu Lokiego w poważnych projektach, ale mogę powiedzieć, że Promtail (agent do zbierania logów) świetnie sprawdza się zarówno w przypadku bare-metalu, jak i podów w kubernetesie.
KLESZCZ
Być może najbardziej godną (jedyną?) w pełni funkcjonalną alternatywę dla stosu ELK można teraz nazwać jedynie stosem TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Poniżej opiszę wszystkie komponenty bardziej szczegółowo, ale ogólny pomysł jest taki:
- Telegraf - agent do zbierania metryk
- InfluxDB - baza metryk
- Kapacitor - procesor metryk w czasie rzeczywistym do alertów
- Chronograf - panel internetowy do wizualizacji
W przypadku InfluxDB, Kapacitor i Chronograf istnieją oficjalne wykresy steru, których użyliśmy do ich wdrożenia.
Należy zaznaczyć, że w najnowszej wersji Influx 2.0 (beta) Kapacitor i Chronograf stały się częścią InfluxDB i nie istnieją już osobno
telegraf
jest bardzo lekkim agentem do zbierania metryk na maszynie stanów.
Może monitorować ogromną ilość wszystkiego, od do
serwer .
Ma wiele fajnych zalet:
- Szybki i lekki (napisany w Go)
- Zjada minimalną ilość zasobów
- Domyślnie przesyłaj metryki
- Zbiera wszystkie niezbędne metryki
- Dane systemowe bez żadnych ustawień
- Metryki sprzętowe, takie jak informacje z czujników
- Dodawanie własnych wskaźników jest bardzo łatwe
- Wiele wtyczek od razu po wyjęciu z pudełka
- Zbiera logi
Ponieważ metryki push były dla nas niezbędne, wszystkie inne zalety były więcej niż przyjemnymi dodatkami.
Zbieranie logów przez samego agenta jest również bardzo wygodne, ponieważ nie ma potrzeby podłączania dodatkowych narzędzi do rejestrowania logów.
Influx oferuje najwygodniejszy sposób pracy z dziennikami, jeśli z niego korzystasz .
Telegraf jest ogólnie świetnym agentem do zbierania metryk, nawet jeśli nie korzystasz z reszty stosu ICK.
Wiele osób dla wygody łączy go z ELK i różnymi innymi bazami danych szeregów czasowych, ponieważ może zapisywać metryki niemal wszędzie.
NapływDB
InfluxDB jest głównym rdzeniem stosu TICK, a mianowicie bazą danych szeregów czasowych dla metryk.
Oprócz metryk Influx może również przechowywać logi, chociaż w istocie logi dla niego to tylko te same metryki, tylko zamiast zwykłych wskaźników numerycznych, główną funkcję pełni wiersz tekstu dziennika.
InfluxDB jest również napisany w Go i wydaje się działać znacznie szybciej w porównaniu do ELK w naszym (nie najpotężniejszym) klastrze.
Jedną z fajnych zalet Influxa byłoby także bardzo wygodne i bogate API do zapytań o dane, z którego korzystaliśmy bardzo aktywnie.
Wady - $$$ czy skalowanie?
Stos TICK ma tylko jedną wadę, którą odkryliśmy – to kochanie. Nawet więcej.
Co ma wersja płatna, czego nie ma wersja darmowa?
O ile udało nam się zrozumieć, jedyną różnicą pomiędzy płatną wersją stosu TICK a bezpłatną wersją są możliwości skalowania.
Mianowicie możesz utworzyć klaster z wysoką dostępnością tylko w .
Jeśli chcesz pełnowartościowego HA, musisz albo zapłacić, albo użyć kul. Istnieje kilka rozwiązań społecznościowych - na przykład wygląda na kompetentne rozwiązanie, ale jest napisane, że nie nadaje się do produkcji, a także
- proste rozwiązanie z pompowaniem danych przez NATS (to też będzie trzeba skalować, ale da się to rozwiązać).
Szkoda, ale obydwa wydają się porzucone - nie ma świeżych commitów, zakładam, że problemem jest niedługo oczekiwana premiera nowej wersji Influxa 2.0, w której wiele rzeczy będzie się różnić (nie ma informacji o skalowanie w nim jeszcze).
Oficjalnie istnieje darmowa wersja - tak naprawdę jest to prymitywny HA, ale tylko poprzez zrównoważenie,
ponieważ wszystkie dane zostaną zapisane we wszystkich instancjach InfluxDB za modułem równoważenia obciążenia.
Ma trochę jak potencjalne problemy z nadpisywaniem punktów i konieczność wcześniejszego tworzenia baz pod metryki
(co dzieje się automatycznie podczas normalnej pracy z InfluxDB).
Ponadto oznacza to dodatkowe obciążenie w przypadku zduplikowanych metryk (zarówno przetwarzania, jak i przechowywania), których możesz nie potrzebować, ale nie ma sposobu, aby je oddzielić.
Wskaźniki Wiktorii?
W rezultacie, mimo że byliśmy w pełni usatysfakcjonowani stosem TICK pod każdym względem poza płatnym skalowaniem, postanowiliśmy sprawdzić, czy istnieją jakieś bezpłatne rozwiązania, które mogłyby zastąpić bazę danych InfluxDB, pozostawiając pozostałe komponenty T_CK.
Baz danych szeregów czasowych jest wiele, ale najbardziej obiecującą z nich jest Victoria Metrics, która ma szereg zalet:
- Szybko i łatwo, przynajmniej według wyników
- Istnieje wersja klasterowa, o której są już nawet dobre recenzje
- Potrafi odłamki
- Obsługuje protokół InfluxDB
Nie zamierzaliśmy budować całkowicie niestandardowego stosu opartego na Victorii, a główną nadzieją było to, że będziemy mogli go użyć jako zamiennika InfluxDB.
Niestety nie jest to możliwe, pomimo tego, że wspierany jest protokół InfluxDB, działa on jedynie do rejestracji metryk – jedynie API Prometheus jest dostępne „na zewnątrz”, co oznacza, że nie będzie możliwości ustawienia na nim Chronografu.
Co więcej, dla metryk obsługiwane są wyłącznie wartości liczbowe (dla metryk niestandardowych użyliśmy wartości łańcuchowych - więcej na ten temat w dziale ).
Oczywiście z tego samego powodu maszyna wirtualna nie może przechowywać dzienników tak, jak robi to Influx.
Należy także zaznaczyć, że w momencie poszukiwań optymalnego rozwiązania Victoria Metrics nie była jeszcze tak popularna, dokumentacja była znacznie mniejsza, a funkcjonalność słabsza
(Nie pamiętam szczegółowego opisu wersji klastra i shardingu).
Wybór bazy
W rezultacie zdecydowano, że w przypadku pilotażu nadal będziemy ograniczać się do jednego węzła InfluxDB.
Za takim wyborem przemawiało kilka głównych powodów:
- Bardzo spodobała nam się cała funkcjonalność stosu TICK
- Udało nam się już to wdrożyć i działało świetnie
- Terminy uciekały, a czasu na testowanie innych opcji pozostało niewiele.
- Nie spodziewaliśmy się tak dużego obciążenia
W pierwszej fazie pilotażu nie mieliśmy zbyt wielu hulajnóg, a testy w trakcie opracowywania nie wykazały żadnych problemów z wydajnością.
Dlatego uznaliśmy, że dla tego projektu wystarczy nam jeden węzeł Influx bez konieczności skalowania (patrz wnioski na końcu).
Zdecydowaliśmy się na stos i bazę - teraz o pozostałych elementach stosu TICK.
Kondensator
Kapacitor jest częścią stosu TICK, usługi, która może monitorować metryki wprowadzane do bazy danych w czasie rzeczywistym i wykonywać różne akcje w oparciu o reguły.
Generalnie pozycjonuje się go jako narzędzie do śledzenia potencjalnych anomalii i uczenia maszynowego (nie jestem pewien, czy na te funkcje jest zapotrzebowanie), ale najpopularniejszy przypadek jego użycia jest bardziej powszechny – alarmowanie.
W ten sposób używaliśmy go do powiadomień. Skonfigurowaliśmy alerty Slack, gdy konkretna hulajnoga przejdzie w tryb offline, to samo zrobiono w przypadku inteligentnych ładowarek i ważnych elementów infrastruktury.
Dzięki temu możliwe było szybkie reagowanie na problemy, a także otrzymywanie powiadomień, że wszystko wróciło do normy.
Prosty przykład: zepsuł się dodatkowy akumulator zasilający naszą „pudełko” lub z jakiegoś powodu się rozładował – wystarczy założyć nowy, a po chwili powinniśmy otrzymać informację, że hulajnoga została przywrócona.
W Influx 2.0 Kapacitor stał się częścią DB
Chronograf
Widziałem wiele różnych rozwiązań UI do monitorowania, ale mogę powiedzieć, że pod względem funkcjonalności i UX nic nie może się równać z Chronografem.
Co dziwne, zaczęliśmy używać stosu TICK z Grafanem jako interfejsem internetowym.
Nie będę opisywał jego funkcjonalności, wszyscy znają jego szerokie możliwości konfiguracji czegokolwiek.
Grafana jest jednak nadal instrumentem w pełni uniwersalnym, natomiast Chronograf przeznaczony jest głównie do współpracy z Influxem.
I oczywiście dzięki temu Chronograf może sobie pozwolić na znacznie mądrzejszą czy też wygodniejszą funkcjonalność.
Być może główną wygodą pracy z Chronografem jest to, że możesz przeglądać wnętrze swojej InfluxDB poprzez Explore.
Wydawać by się mogło, że Grafana ma niemal identyczną funkcjonalność, jednak w rzeczywistości ustawienie dashboardu w Chronografie można wykonać kilkoma kliknięciami myszki (w tym samym czasie patrząc na znajdującą się tam wizualizację), natomiast w Grafanie i tak prędzej czy później będziesz miał edytować konfigurację JSON (oczywiście Chronograf umożliwia przesyłanie ręcznie skonfigurowanych dash i edytowanie ich w formacie JSON, jeśli to konieczne - ale nigdy nie musiałem ich dotykać po utworzeniu ich w interfejsie użytkownika).
Kibana ma znacznie bogatsze możliwości tworzenia dla nich dashboardów i kontrolek, jednak UX dla takich operacji jest bardzo skomplikowany.
Stworzenie wygodnego pulpitu nawigacyjnego wymaga dobrego zrozumienia. I choć funkcjonalność dashboardów Chronograf jest mniejsza, ich tworzenie i dostosowywanie jest znacznie prostsze.
Same dashboardy poza przyjemnym stylem wizualnym w zasadzie niczym nie różnią się od dashboardów w Grafanie czy Kibanie:
Tak wygląda okno zapytania:
Warto zwrócić uwagę m.in., że znając rodzaje pól w bazie InfluxDB, sam chronograf może czasem automatycznie pomóc w napisaniu Zapytania czy wybraniu właściwej funkcji agregującej np. średniej.
I oczywiście Chronograf jest tak wygodny, jak to tylko możliwe do przeglądania logów. To wygląda tak:
Domyślnie logi Influx są dostosowane do korzystania z syslog i dlatego mają ważny parametr - ważność.
Szczególnie przydatny jest wykres u góry, na którym widać pojawiające się błędy, a kolor od razu wyraźnie pokazuje, czy ich istotność jest większa.
Kilka razy wyłapaliśmy w ten sposób ważne błędy, przeglądając logi z ostatniego tygodnia i zauważając czerwony skok.
Oczywiście idealnie byłoby skonfigurować alerty o takich błędach, ponieważ mieliśmy już wszystko na ten temat.
Nawet na chwilę to włączyliśmy, ale w trakcie przygotowywania pilota okazało się, że wywala nam całkiem sporo błędów (w tym systemowych, jak niedostępność sieci LTE), które „spamowały” także kanał Slack dużo, nie powodując żadnych problemów, wielka korzyść.
Prawidłowym rozwiązaniem byłoby obsłużenie większości tego typu błędów, dostosowanie ich wagi i dopiero wtedy włączenie alarmowania.
W ten sposób do Slacka zostaną przesłane tylko nowe lub ważne błędy. Ze względu na napięte terminy po prostu nie było wystarczająco dużo czasu na taką konfigurację.
Uwierzytelnianie
Warto również wspomnieć, że Chronograf obsługuje jako uwierzytelnianie OAuth i OIDC.
Jest to bardzo wygodne, ponieważ pozwala łatwo podłączyć go do swojego serwera i stworzyć pełnoprawne SSO.
W naszym przypadku serwer był — służył do łączenia się z monitoringiem, ale ten sam serwer służył także do uwierzytelniania hulajnogów i żądań do back-endu.
"Admin"
Ostatnim elementem, który opiszę, jest nasz samodzielnie napisany „panel administracyjny” w Vue.
Zasadniczo jest to samodzielna usługa, która jednocześnie wyświetla informacje o hulajnodze z naszych własnych baz danych, mikrousług i danych metryk z InfluxDB.
Dodatkowo przeniesiono tam wiele funkcji administracyjnych, jak np. awaryjne ponowne uruchomienie czy zdalne otwarcie zamka dla zespołu wsparcia.
Były też mapy. Wspomniałem już, że zaczęliśmy od Grafany, a nie Chronografu – bo dla Grafany dostępne są mapy w formie wtyczek, na których mogliśmy zobaczyć współrzędne hulajnogów. Niestety możliwości widżetów map dla Grafany są bardzo ograniczone, w efekcie znacznie łatwiej było napisać w ciągu kilku dni własną aplikację internetową z mapami, aby nie tylko zobaczyć w danej chwili współrzędne, ale także wyświetlić trasę przebytą przez hulajnogę, możliwość filtrowania danych na mapie itp. (wszystkie te funkcjonalności, których nie mogliśmy skonfigurować w prostym dashboardzie).
Jedną z już wspomnianych zalet Influxu jest możliwość łatwego tworzenia własnych metryk.
Dzięki temu można go używać w bardzo różnorodnych scenariuszach.
Próbowaliśmy zapisać tam wszystkie przydatne informacje: stan naładowania baterii, stan blokady, działanie czujnika, Bluetooth, GPS i wiele innych kontroli stanu.
Wszystko to wyświetlaliśmy na panelu administracyjnym.
Oczywiście najważniejszym kryterium był dla nas stan pracy hulajnogi – tak naprawdę Influx sam to sprawdza i pokazuje „zielonymi światełkami” w sekcji Węzły.
Robi się to za pomocą funkcji — użyliśmy go, aby zrozumieć działanie naszego urządzenia i wysłać te same alerty do Slacka.
Nawiasem mówiąc, nazwaliśmy hulajnogi imionami postaci z „Simpsonów” - tak wygodnie było je od siebie odróżnić
I ogólnie tak było zabawniej. Ciągle słyszano zwroty takie jak „Chłopaki, Smithers nie żyje!”.
Metryki ciągów
Co ważne, InfluxDB umożliwia przechowywanie nie tylko wartości liczbowych, jak ma to miejsce w przypadku Victoria Metrics.
Wydawałoby się, że nie jest to aż tak istotne – w końcu poza logami można przechowywać w postaci liczbowej dowolne metryki (wystarczy dodać mapowanie dla znanych stanów – coś w rodzaju wyliczenia)?
W naszym przypadku istniał co najmniej jeden scenariusz, w którym metryki łańcuchowe były bardzo przydatne.
Tak się złożyło, że dostawcą naszych „inteligentnych ładowarek” była strona trzecia, nie mieliśmy kontroli nad procesem rozwoju i informacjami, jakie te ładowarki mogły dostarczać.
W rezultacie interfejs API ładowania był daleki od ideału, ale głównym problemem było to, że nie zawsze mogliśmy zrozumieć ich stan.
I tu z pomocą przyszedł Influx. Po prostu zapisaliśmy status stringu, który do nas przyszedł, w polu bazy danych InfluxDB bez zmian.
Przez jakiś czas trafiały tam tylko wartości typu „online” i „offline”, na podstawie których wyświetlała się informacja w naszym panelu administracyjnym, a powiadomienia trafiały do Slacka. Jednak w pewnym momencie zaczęły się tam pojawiać także wartości takie jak „rozłączony”.
Jak się później okazało, status ten był wysyłany jednorazowo po utracie połączenia, jeśli ładowarka po określonej liczbie prób nie mogła nawiązać połączenia z serwerem.
Zatem gdybyśmy użyli tylko ustalonego zestawu wartości, moglibyśmy nie zauważyć tych zmian w oprogramowaniu sprzętowym we właściwym czasie.
Ogólnie rzecz biorąc, metryki łańcuchowe dają znacznie więcej możliwości wykorzystania, można w nich zapisać praktycznie każdą informację. Chociaż oczywiście trzeba również ostrożnie korzystać z tego narzędzia.
Oprócz zwykłych danych, w InfluxDB zarejestrowaliśmy również informacje o lokalizacji GPS. Było to niezwykle przydatne do monitorowania lokalizacji hulajnóg w naszym panelu administracyjnym.
Tak naprawdę zawsze wiedzieliśmy gdzie i jaka hulajnoga jest w danym momencie nam potrzebna.
Bardzo nam się to przydało, gdy szukaliśmy hulajnogi (patrz wnioski na końcu).
Monitorowanie infrastruktury
Oprócz samych hulajnóg musieliśmy także monitorować całą naszą (dość rozbudowaną) infrastrukturę.
Bardzo ogólna architektura wyglądała mniej więcej tak:
Jeśli podświetlimy czysty stos monitorowania, wygląda to tak:
To co chcielibyśmy sprawdzić w chmurze to:
- Bazy danych
- Keyclock
- Mikrousługi
Ponieważ wszystkie nasze usługi chmurowe zlokalizowane są w Kubernetesie, miło byłoby zebrać informacje o jego stanie.
Na szczęście Telegraf od razu po wyjęciu z pudełka potrafi zebrać ogromną ilość metryk o stanie klastra Kubernetes, a Chronograf od razu oferuje do tego piękne dashboardy.
Monitorowaliśmy głównie wydajność podów i zużycie pamięci. W przypadku upadku alerty w aplikacji Slack.
Istnieją dwa sposoby śledzenia podów w Kubernetes: DaemonSet i Sidecar.
Obie metody zostały szczegółowo opisane .
Korzystaliśmy z Telegraf Sidecar i oprócz metryk zebraliśmy logi podów.
W naszym przypadku musieliśmy majstrować przy kłodach. Pomimo tego, że Telegraf może pobierać logi z Docker API, chcieliśmy mieć jednolite gromadzenie logów na naszych urządzeniach końcowych i skonfigurowaliśmy w tym celu syslog dla kontenerów. Być może to rozwiązanie nie było piękne, ale nie było żadnych skarg na jego działanie, a logi dobrze wyświetlały się w Chronografie.
Monitorować monitorowanie???
W końcu pojawiło się odwieczne pytanie dotyczące systemów monitorowania i monitorowania, ale na szczęście lub niestety po prostu nie mieliśmy na to wystarczająco dużo czasu.
Chociaż Telegraf może z łatwością wysyłać własne metryki lub zbierać metryki z bazy danych InfluxDB w celu wysłania ich do tego samego Influxu lub gdzie indziej.
odkrycia
Jakie wnioski wyciągnęliśmy z wyników pilotażu?
Jak można prowadzić monitoring?
Przede wszystkim stos TICK w pełni spełnił nasze oczekiwania i dał nam jeszcze więcej możliwości niż początkowo oczekiwaliśmy.
Dostępna była cała funkcjonalność, której potrzebowaliśmy. Wszystko co z nim zrobiliśmy działało bez problemów.
produktywność
Głównym problemem stosu TICK w wersji darmowej jest brak możliwości skalowania. Dla nas to nie był problem.
Nie zebraliśmy dokładnych danych/liczb dotyczących obciążenia, ale jednocześnie zbieraliśmy dane z około 30 hulajnóg.
Każdy z nich zebrał ponad trzy tuziny wskaźników. Jednocześnie zbierane były logi z urządzeń. Zbieranie i wysyłanie danych odbywało się co 10 sekund.
Warto zaznaczyć, że po półtora tygodnia pilotażu, kiedy większość „wrzodów z dzieciństwa” została naprawiona, a najważniejsze problemy już rozwiązane, musieliśmy zmniejszyć częstotliwość wysyłania danych na serwer, aby 30 sekund. Stało się to konieczne, bo ruch na naszych kartach SIM LTE zaczął szybko znikać.
Większość ruchu pochłaniały logi, same metryki, nawet z 10-sekundowym odstępem, praktycznie go nie marnowały.
W rezultacie po pewnym czasie całkowicie wyłączyliśmy zbieranie logów na urządzeniach, ponieważ określone problemy były już oczywiste nawet bez ciągłego zbierania.
W niektórych przypadkach, jeśli przeglądanie logów było nadal konieczne, po prostu łączyliśmy się przez WireGuard przez VPN.
Dodam też, że każde osobne środowisko było od siebie odseparowane, a opisane powyżej obciążenie dotyczyło tylko środowiska produkcyjnego.
W środowisku programistycznym uruchomiliśmy osobną instancję InfluxDB, która w dalszym ciągu zbierała dane co 10 sekund i nie napotkaliśmy żadnych problemów z wydajnością.
TICK – idealny do małych i średnich projektów
Na podstawie tych informacji wnioskuję, że stos TICK jest idealny do stosunkowo małych projektów lub projektów, które zdecydowanie nie oczekują żadnego HighLoad.
Jeśli nie masz tysięcy podów ani setek maszyn, nawet jedna instancja InfluxDB poradzi sobie z obciążeniem.
W niektórych przypadkach możesz zadowolić się Influx Relay jako prymitywnym rozwiązaniem zapewniającym wysoką dostępność.
I oczywiście nikt nie stoi na przeszkodzie, aby skonfigurować skalowanie „pionowe” i po prostu przydzielić różne serwery dla różnych typów metryk.
Jeśli nie masz pewności co do oczekiwanego obciążenia usług monitorowania lub masz gwarancję, że masz/będziesz mieć bardzo „ciężką” architekturę, nie polecam korzystania z darmowej wersji stosu TICK.
Oczywiście prostym rozwiązaniem byłby zakup - ale tutaj nie mogę się jakoś wypowiedzieć, ponieważ sam nie jestem zaznajomiony z subtelnościami. Poza tym, że jest bardzo drogi i zdecydowanie nie nadaje się dla małych firm.
W takim przypadku dzisiaj zalecałbym skupienie się na zbieraniu metryk za pomocą Victoria Metrics i logów za pomocą Lokiego.
Co prawda ponownie zastrzeżę, że Loki/Grafana są znacznie mniej wygodne (ze względu na większą uniwersalność) niż gotowy TICK, ale są darmowe.
To jest ważne: wszystkie informacje tutaj opisane dotyczą wersji Influx 1.8, w chwili obecnej Influx 2.0 ma zostać wydany.
Choć nie miałem okazji wypróbować go w warunkach bojowych i trudno wyciągać wnioski co do ulepszeń, to interfejs zdecydowanie stał się jeszcze lepszy, uproszczona została architektura (bez kondensatora i chronografu),
pojawiły się szablony („zabójcza funkcja” - ). Ale niestety w tej chwili wersja 2 nie ma kluczowej rzeczy, dla której wybraliśmy pierwszą wersję - nie ma zbierania logów.
Funkcjonalność ta pojawi się także w Influxie 2.0, jednak nie udało nam się znaleźć żadnych terminów, nawet przybliżonych.
Jak nie tworzyć platform IoT (teraz)
Ostatecznie po uruchomieniu pilotażu sami zmontowaliśmy własny, pełnoprawny stos IoT, w przypadku braku alternatywy odpowiadającej naszym standardom.
Jednak od niedawna dostępna jest w wersji Beta — szkoda, że nie było jej tam, kiedy zaczynaliśmy realizację projektu.
Jesteśmy w pełni usatysfakcjonowani efektem końcowym i platformą opartą na Ansible + TICK + WireGuard, którą sami zmontowaliśmy. Ale dzisiaj polecam przyjrzeć się bliżej Balenie, zanim spróbujesz samodzielnie zbudować własną platformę IoT.
Ponieważ ostatecznie może zrobić większość tego, co zrobiliśmy, a OpenBalena jest darmowym i otwartym oprogramowaniem.
Wie już, jak nie tylko wysyłać aktualizacje, ale także VPN jest już wbudowany i dostosowany do użytku w środowisku IoT.
A niedawno nawet wydali swój , który łatwo łączy się z ich ekosystemem.
Hej, a co z zaginionym skuterem?
I tak skuter „Ralph” zniknął bez śladu.
Od razu pobiegliśmy obejrzeć mapę w naszym „panelu administracyjnym”, z danymi metryk GPS z InfluxDB.
Dzięki danym z monitoringu bez trudu ustaliliśmy, że hulajnoga opuściła parking około godziny 21:00 ostatniego dnia, po około pół godzinie pojechała w jakieś miejsce i do godziny 5 rano stała zaparkowana obok jakiegoś niemieckiego domu.
Po godzinie 5 rano nie otrzymano żadnych danych z monitoringu — oznaczało to, że albo dodatkowy akumulator został całkowicie rozładowany, albo atakujący w końcu wymyślił, jak usunąć inteligentny sprzęt ze hulajnogi.
Mimo to pod adres, pod którym znajdowała się hulajnoga, nadal wzywana była policja. Hulajnogi nie było.
Jednak właściciel domu również był tym zaskoczony, ponieważ wczoraj wieczorem przyjechał z biura do domu na hulajnodze.
Jak się okazało, jeden z pracowników supportu przyjechał wcześnie rano, odebrał hulajnogę widząc, że jej dodatkowy akumulator był całkowicie rozładowany i zabrał go (na piechotę) na parking. Dodatkowy akumulator uległ awarii z powodu wilgoci.
Ukradliśmy sobie skuter. Swoją drogą nie wiem jak i kto w takim razie rozwiązał sprawę z policją, ale monitoring zadziałał znakomicie...
Źródło: www.habr.com