Wprowadzenie do InfluxDB

InfluxDB intro - title

InfluxDB to baza danych stworzona do przechowywania szereg├│w czasowych. Posiada otwarty kod ┼║r├│d┼éowy, chod┼║ jej dostawca (InfluxData) oferuje r├│wnie┼╝ rozwi─ůzanie Enterprise. W tym artykule opisz─Ö do czego s┼éu┼╝y InfluxDB, w jaki spos├│b przechowuje dane, jak realizuje funkcje wizualizacji, alertowania czy transportu (a wi─Öc niegdy┼Ť TICK stack: Telegraf, InfluxDB, Chronograf, Kapacitor) oraz jak go zainstalowa─ç wraz z przyk┼éadami prostej architektury. Napisze tak┼╝e kilka s┼é├│w o wychodz─ůcej niebawem wersji InfluxDB 2.0 (obecnie beta) i najwa┼╝niejszych r├│┼╝nicach pomi─Ödzy InfluxDB 1.0 i 2.0. Wspomn─Ö tak┼╝e na temat Flux – nowy, zunifikowany w wersji 2.0 j─Özyk zapyta┼ä.

Czym s─ů szeregi czasowe?

Po obowi─ůzuj─ůce definicje odsy┼éam Ciebie do s┼éownika, Wikipedii czy innego powa┼╝nego ┼║r├│d┼éa. Na nasze potrzeby mo┼╝emy za┼éo┼╝y─ç, ┼╝e: szereg czasowy, seria czasowa, czy po angielsku time series to ka┼╝dy zbi├│r danych gdzie dziedzin─ů (o┼Ť X wykresu) jest czas a warto┼Ť─ç (o┼Ť Y) odpowiada pomiarowi pewnego zjawiska. Szereg jest uporz─ůdkowany, a pomiary rejestrowane s─ů z okre┼Ťlonym interwa┼éem (w r├│wnych odst─Öpach czasu). Za pomoc─ů szereg├│w czasowych mo┼╝emy przedstawi─ç np.:

  • zmiany temperatury powietrza, ci┼Ťnienia atmosferycznego, wilgotno┼Ťci, zawarto┼Ťci CO2, etc.
  • zmiany w wykorzystaniu mocy obliczeniowych procesora czy innych parametr├│w pracy komputera
  • dowolne inne dane pochodz─ůce z czujnik├│w i urz─ůdze┼ä Internet-of-Things (IoT)
  • ceny aktyw├│w finansowych, np. warto┼Ť─ç akcji CDPROJEKT czy kurs Bitcoin’a

W skr├│cie – mo┼╝e opisywa─ç dowolny mierzalny proces na przestrzeni czasu. W nomenklaturze InfluxDB takie szeregi nazywane s─ů metrykami (metrics), w przeciwie┼ästwie do zdarze┼ä (events). Zdarzenia nie s─ů rejestrowane w okre┼Ťlonych interwa┼éach, natomiast wci─ů┼╝ tworz─ů ci─ůg uporz─ůdkowanych na przestrzeni czasu pomiar├│w. Od strony teoretycznej m├│wimy wtedy o szeregu czasowym rozmytym. W praktyce – interwa┼é jest zmienny, a wi─Öc to kiedy otrzymamy kolejne zdarzenie jest niewiadome. St─ůd metryki s─ů nazywane danymi regularnymi a zdarzenia – nieregularnymi.

Jakie s─ů przewagi InfluxDB

InfluxDB pozwala nam pracowa─ç zar├│wno z metrykami jak i zdarzeniami. Dlaczego do takich w┼éa┼Ťnie typ├│w danych potrzebny jest inny, specjalistyczny rodzaj bazy danych? W ko┼äcu mo┼╝emy np. w MySQL doda─ç kolumn─Ö typu DATETIME kt├│ra mo┼╝e przechowywa─ç dat─Ö i czas z precyzj─ů na poziomie mikrosekundy. InfluxDB ma przewag─Ö nad tradycyjnymi bazami danych w dw├│ch obszarach.

Wydajno┼Ť─ç

a wi─Öc efektywno┼Ť─ç zapyta┼ä. W zdecydowanej wi─Ökszo┼Ťci przypadk├│w kiedy m├│wimy o szeregach czasowych nie interesuje nas pojedynczy pomiar, chcemy analizowa─ç przebieg zjawiska na przestrzeni czasu a wi─Öc wykonywa─ç zapytania na du┼╝ej ilo┼Ťci danych. Je┼╝eli chcemy do bazy pod┼é─ůczy─ç np. nowe urz─ůdzenie IIoT raportuj─ůce stan maszyny na hali produkcyjnej, musimy liczy─ç si─Ö ze strumieniem danych rz─Ödu 10 pomiar├│w, raz na 5 sekund. Czyli w ci─ůgu doby dostaniemy 172820 pomiar├│w. Z jednego urz─ůdzenia! Ten strumie┼ä danych nigdy nie zwolni, i tak d┼éugo jak urz─ůdzenie jest pod┼é─ůczone, ka┼╝dego dnia dostaniemy kolejne 172k rekord├│w w bazie. W skr├│cie – praca z szeregami czasowymi charakteryzuje si─Ö du┼╝─ů liczb─ů operacji zapisu oraz odczytu. InfluxDB jest stworzony pod k─ůtem wydajno┼Ťci w przetwarzaniu tak obszernych szereg├│w czasowych, ale posiada te┼╝ intuicyjne narz─Ödzia ustalania polityki retencji czy tzw. downsampling. Dzi─Öki tym mechanizmom po up┼éywie np. jednego tygodnia wszystkie pomiary zostan─ů zagregowane do ┼Ťrednich minutowych czy dziesi─Öciominutowych (redukuj─ůc obj─Öto┼Ť─ç danych o dwa rz─Ödy wielko┼Ťci) a po kolejnym miesi─ůcu mog─ů zostana─ç skasowane.

Ergonomia pracy z czasem

Drug─ů istotn─ů zalet─ů InfluxDB jest mo┼╝liwo┼Ť─ç prostego tworzenia zapyta┼ä kt├│rych podstaw─ů jest czas. Je┼╝eli pracowa┼éa┼Ť kiedy┼Ť z np. MySQL, MongoDB czy dowoln─ů inn─ů baz─ů danych kt├│ra nie skupia si─Ö na szeregach czasowych to wiesz, ┼╝e budowanie zapyta┼ä uwzgl─Ödniaj─ůcych czas (a wi─Öc bior─ůcych pod uwag─Ö zakresy, interwa┼éy, czasy trwania, uwzgl─Ödnianie brakuj─ůcych pomiar├│w etc.) nie jest trywialne.

Agregacja i inne zastosowania

Warto wspomnie─ç ┼╝e w przypadku tworzenia agregacji powinni┼Ťmy ogranicza─ç si─Ö do pracy z metrykami – dzi─Öki sta┼éym interwa┼éom informacje zagregowanie kt├│re dzi─Öki nim uzyskamy b─Öd─ů przydatne. Zdarzenia do tworzenia agregacji raczej si─Ö nie nadaj─ů, ze wzgl─Ödu na zmienne odst─Öpy pomi─Ödzy pomiarami. S─ů one natomiast cz─Östo ┼║r├│d┼éem alert├│w, kt├│re r├│wnie┼╝ bardzo sprawnie wykryjemy i obs┼éu┼╝ymy za pomoc─ů InfluxDB (a dok┼éadniej rzecz bior─ůc – Kapacitor ze stacku TICK).

S─ů jeszcze dwa zastosowania InfluxDB o kt├│rych wspomina sam zesp├│┼é InfluxData, a mianowicie tracing (lub distributed tracing) oraz przetwarzanie log├│w. Tracing to proces pomiaru i profilowania odpowiedzi serwis├│w na zapytania, zw┼éaszcza je┼Ťli takie zapytanie w─Ödruje pomi─Ödzy rozmaitymi serwisami b─Öd─ůcymi np. cz─Ö┼Ťci─ů architektury mikroserwis├│w. Logi (inaczej journale, dzienniki zdarze┼ä, rejestry zdarze┼ä) to po prostu chronologiczny zapis wszystkich zdarze┼ä i akcji kt├│re wyst─ůpi┼éy w danej aplikacji czy systemie.

TICK Stack is dead – czyli Influx 2.0 (+ Telegraf ­čśë)

We wprowadzeniu u┼╝y┼éem sformu┼éowania „a wi─Öc niegdy┼Ť TICK stack”, by─ç mo┼╝e troch─Ö za wcze┼Ťnie. Kiedy pisz─Ö ten artyku┼é we wrze┼Ťniu 2020 InfluxDB w wersji 2.0 jest wci─ů┼╝ w fazie beta. Jedn─ů z najwi─Ökszych zmian w wersji 2.0 jest w┼éa┼Ťnie po┼é─ůczenie odr─Öbnych wcze┼Ťniej komponent├│w stacku TICK w jedn─ů aplikacj─Ö nazywan─ů po prostu InfluxDB. Czym jest (bo jednak wci─ů┼╝ „obowi─ůzuje”) TICK stack? To zestaw czterech komponent├│w:

T jak Telegraf

Telegraf can collect metrics from a wide array of inputs and write them into a wide array of outputs.

Fragment opisu ze strony InfluxData

Telegraf jest aplikacj─ů pozwalaj─ůc─ů na zbieranie danych (metryk, zdarze┼ä) z rozmaitych ┼║r├│de┼é i przesy┼éanie ich dalej, np. do bazy danych InfluxDB. Podstaw─ů jego architektury jest bardzo obszerna biblioteka plug-in├│w, czyli wtyczek umo┼╝liwiaj─ůcych akwizycj─Ö danych oraz ich zapis. W tej chwili biblioteka plugin├│w liczy sobie ponad 200+ pozycji. Praca z telegrafem jest bardzo intuicyjna, sprowadza si─Ö do edycji jednego pliku konfiguracyjnego w kt├│rym wskazujemy nasze wej┼Ťcia i wyj┼Ťcia wraz z parametrami w┼éa┼Ťciwymi dla wykorzystanych wtyczek. Co ciekawe, Telegraf sam mo┼╝e wygenerowa─ç domy┼Ťlny plik konfiguracyjny:

kuba@local:~$ telegraf config > telegraf.conf

Telegraf jest napisany w Go, a wi─Öc sk┼éada si─Ö z jednego pliku binarnego nie wymagaj─ůcego dodatkowych bibliotek czy zale┼╝no┼Ťci. Mo┼╝emy go zainstalowa─ç na docelowej maszynie poprzez skopiowanie – nie musimy bawi─ç si─Ö w zarz─ůdzanie pakietami, instalacje przez pip, npm, apt-get etc..

Mo┼╝e tak┼╝e parsowa─ç dane, a wi─Öc przetwarza─ç np. wej┼Ťcie w postaci pliku JSON i wysy┼éa─ç je dalej do InfluxDB.

Najcz─Ö┼Ťciej w architekturze TICK stack Telegraf jest uruchamiany na wielu maszynach czy urz─ůdzeniach IoT kt├│rych parametry nie pozwalaj─ů na odpalenie tam lokalnego InfluxDB. Jedn─ů z zalet Telegraf jest zreszt─ů bardzo ma┼ée zapotrzebowanie na pami─Ö─ç co znacznie u┼éatwia prac─Ö na urz─ůdzeniach z ograniczonymi zasobami. Z tego te┼╝ powodu kiedy m├│wimy o unifikacji TICK stack w wersji InfluxDB 2.0 chodzi tak na prawd─Ö o unifikacj─Ö pozosta┼éych komponent├│w. Telegraf wci─ů┼╝ pozostanie odr─Öbnym plikiem binarnym.

I jak InfluxDB

A wi─Öc sama baza danych o kt├│rej ju┼╝ by┼éo sporo – stworzona do pracy z szeregami czasowymi, radz─ůca sobie z du┼╝─ů ilo┼Ťci─ů operacji zapisu i odczytu. Posiada sw├│j w┼éasny j─Özyk do przetwarzania i interakcji z danymi – InfluxQL w wersji 1.0 oraz Flux w wersji 2.0.

Wspomnia┼éem ┼╝e sam InfluxDB jest oprogramowaniem open source, warto wi─Öc r├│wnie┼╝ wspomnie─ç ┼╝e istnieje komercyjna propozycja (closed source) o nazwie InfluxDB Enterprise. Najwi─Öksza pomi─Ödzy propozycj─ů open source a wersj─ů Enterpsie to horyzontalna skalowalno┼Ť─ç – Enterprise pozwala tworzy─ç klastry (clusters) instancji bazy danych, dzi─Öki czemu poza skalowaln─ů wydajno┼Ťci─ů uzyskujemy r├│wnie┼╝ wysok─ů dost─Öpno┼Ť─ç platformy. A wi─Öc dok┼éadnie to czego spodziewaliby┼Ťmy si─Ö w ofercie dla du┼╝ych klient├│w.

Oczywi┼Ťcie zgodnie z panuj─ůcymi trendami mo┼╝emy r├│wnie┼╝ korzysta─ç z InfluxDB we w┼éasnej chmurze oferowanej przez InfluxData: InfluxDB Cloud.

C jak Chronograf

Chronograf is the complete interface for the InfluxDB 1.x Platform

Opis Chronograf na stronie InfluxData

Chronograf to w skr├│cie warstwa interfejsu u┼╝ytkownika dla InfluxDB, wcze┼Ťniej odr─Öbna aplikacja a ju┼╝ nied┼éugo integralna cze┼Ť─ç InfluxDB 2.0.

Cze┼Ť─ç funkcjonalno┼Ťci jest podobna do np. Grafany – poniewa┼╝ spory obszar zastosowa┼ä Chronograf to w┼éa┼Ťnie wizualizacje danych za pomoc─ů dashboard├│w. Znajdziemy tu r├│wnie┼╝ ciekawe funkcje data exploration – a wi─Öc wspieraj─ůce odnajdywanie interesuj─ůcych zjawisk w naszych danych. Oczywi┼Ťcie Chronograf to tak┼╝e (a mo┼╝e przede wszystkim) administracja nasz─ů instancj─ů InfluxDB. Mo┼╝emy tutaj tworzy─ç u┼╝ytkownik├│w, przypisywa─ç im uprawnienia czy zak┼éada─ç nowe bazy danych (w 2.0 tzw. buckety). Tutaj r├│wnie┼╝ zarz─ůdzamy alertami, za kt├│re wcze┼Ťniej odpowiada┼é…

K jak Kapacitor

Kapacitor is a native data processing engine for InfluxDB 1.x and is an integrated component in the InfluxDB 2.0 platform.

Opis Kapacitor na stronie InfluxData

Podobnie jak Chronograf, w 1.0 stanowi┼é odr─Öbn─ů aplikacj─Ö, nied┼éugo b─Ödzie integraln─ů cz─Ö┼Ťci─ů InfluxDB 2.0. Kapacitor potrafi przetwarza─ç strumienie danych (takie jak np. metryki) w czasie rzeczywistym. Oczywi┼Ťcie potrafi to samo zrobi─ç z batchami. W rezultacie, najcz─Östszym owocem jego pracy s─ů alerty, kt├│re pozwalaj─ů wychwyci─ç interesuj─ůce nas zdarzenia z ogromnej ilo┼Ťci surowych rekord├│w. Alerty Kapacitora s─ů dost─Öpne we wzorcu publikacji/subskrypcji, a wi─Öc podobnym do np. kolejek MQTT. Kapacitor mo┼╝e by─ç u┼╝yty zar├│wno jako pre-procesor (a wi─Öc przed zapisem do InfluxDB) jak i post-procesor za pomoc─ů kt├│rego przygotujemy dane dla innego ┼║r├│d┼éa.

Od strony technicznej

Powy┼╝ej troch─Ö teorii oraz informacji na temat komponent├│w InfluxDB. Teraz przejd┼║my do rzeczy. Pierwszy punkt to instalacja InfluxDB. Zapraszam Ci─Ö do mojego wprowadzenia do Dockera i Docker Compose gdzie wspominam mi─Ödzy innymi o tym jak w prosty spos├│b, dzi─Öki Dockerowi oraz Docker Hub mo┼╝na stworzy─ç sobie eksperymentalne ┼Ťrodowisko do test├│w czy nauki. Wykorzystamy t─ů metod─Ö aby zainstalowa─ç InfluxDB w wersji 2.0.

Instalacja przy pomocy Dockera

Zakładam że masz Dockera i pracujesz na Linuxie. Jeżeli szukasz innej metody instalacji lub używasz innego systemu operacyjnego zajrzyj do dokumentacji InfluxDB 2.0. Po pierwsze pobierzmy obraz InfluxDB w wersji 2.0 beta. Kiedy piszę ten artykuł obraz w wersji 2.0 nie jest on dostępny na Docker Hub, dokumentacja wskazuje nam natomiast link do obrazu na quay.io:

kuba@local:~$ docker pull quay.io/influxdb/influxdb:2.0.0-beta
2.0.0-beta: Pulling from influxdb/influxdb
50c5b17671b8: Pull complete 
389413946050: Pull complete 
e85c19e34f0c: Pull complete 
8d2a1df5c214: Pull complete 
Digest: sha256:b36aadabaea1d583440271b29b178c9877abf8120402358565bb5ad970668622
Status: Downloaded newer image for quay.io/influxdb/influxdb:2.0.0-beta
quay.io/influxdb/influxdb:2.0.0-beta

Je┼╝eli chcesz, u┼╝yj polecenia docker images --all aby zobaczy─ç list─Ö wszystkich obraz├│w Dockera dost─Öpnych na Twojej maszynie. Mo┼╝esz tak┼╝e u┼╝y─ç | grep je┼Ťli, tak jak u mnie, ta lista jest d┼éuga:

kuba@local:~$ docker images --all | grep influx
quay.io/influxdb/influxdb   2.0.0-beta          2941dc3d72f7        6 weeks ago         217MB
min_influxdb                latest              ec25d761bc08        2 months ago        304MB
influxdb                    latest              c84fa3cbe963        2 months ago        304MB

Teraz mo┼╝emy uruchomi─ç kontener w oparciu o obraz 2.0:

kuba@local:~$ docker run --name influxdb \
>      -p 9999:9999 \
>      -v $PWD/influx2.0:/var/lib/influxdb \
>      quay.io/influxdb/influxdb:2.0.0-beta \
>      --reporting-disabled

Korzystamy z docker run, mapujemy port 9999 (pod kt├│rym kontener wystawia interfejs u┼╝ytkownika) oraz mapujemy foldfer lokalny na wystawiony przez obraz wolument /var/lib/influxdb. $PWD to ┼Ťcie┼╝ka do Twojego folderu domowego na Linuxie (mo┼╝esz to sprawdzi─ç komend─ů echo $PWD). Ja stworzy┼éem w nim podfolder influx2.0, je┼╝eli tego nie zrobi┼ée┼Ť – komenda mkdir influx2.0. Kolejny parametr to nazw─Ö obrazu wraz z wersj─ů, tzn. quay.io/influxdb/influxdb:2.0.0-beta. Ostatni parametr –--reporting-disabled, nie jest ju┼╝ parametrem Dockera a samego obrazu. W ten spos├│b mo┼╝emy wy┼é─ůczy telemetri─Ö. Nasza testowa instancja InfluxDB nie b─Ödzie komunikowa┼éa si─Ö z InfluxData i przekazywa┼éa danych. Dane s─ů oczywi┼Ťcie anonimowe i statystyczne, ja mimo wszystko zawsze wy┼é─ůczam telemetri─Ö tam gdzie to jest tylko mo┼╝liwe.

Ostatnia uwaga – tak uruchomiony kontener b─Ödzie aktywny w Twoim bie┼╝─ůcym oknie terminala. B─Ödziemy na ┼╝ywo widzieli logi kontenera, co na potrzeby test├│w i ─çwicze┼ä jest jak najbardziej OK. Je┼╝eli b─Ödziesz chcia┼é zrobi─ç co┼Ť innego w terminalu – rozpocznij jego drug─ů instancj─Ö. Alternatywnie mo┼╝esz uruchomi─ç ten kontener w trybie detached, a wi─Öc w tle. U┼╝yj wtedy parametru -d, np. docker run -d --name influxdb \ (...).

Je┼╝eli wszystko p├│jdzie zgodnie z planem zobaczysz co┼Ť takiego:

kuba@local:~$ docker run --name influxdb \
>       -p 9999:9999 \
>       -v $PWD/influx2.0:/var/lib/influxdb \
>       quay.io/influxdb/influxdb:2.0.0-beta \
>       --reporting-disabled
ts=2020-09-23T10:18:05.601736Z lvl=info msg="Welcome to InfluxDB" log_id=0PQcN5dG000 version=2.0.0-beta.16 commit=50964d732c build_date=2020-08-07T20:18:07Z
ts=2020-09-23T10:18:05.609793Z lvl=info msg="Resources opened" log_id=0PQcN5dG000 service=bolt path=/root/.influxdbv2/influxd.bolt
(...)
ts=2020-09-23T10:18:06.015406Z lvl=info msg=Listening log_id=0PQcN5dG000 transport=http addr=:9999 port=9999

Konfiguracja

S─ů dwa sposoby konfiguracji naszej ┼Ťwie┼╝ej instancji InfluxDB – poprzez CLI, przy u┼╝yciu j─Özyka flux oraz poprzez interfejs u┼╝ytkownika wystawiony na porcie 9999. Oczywi┼Ťcie wybieramy ten drugi spos├│b. Otwieramy przegl─ůdark─Ö i w pasku adresu wpisujemy localhost:9999. Mnie powita┼é taki widok:

blue screen of death

…CDN… lub nie ­čśą tak to bywa jak si─Ö artyku┼é 2 lata pisze ­čĹ║


Autor: kuba

Pracuj─Ö w IT, sprzedaj─ůc oprogramowanie klasy APS/MES firmom produkcyjnym. Nie jestem software developerem ale odk─ůd zacz─ů┼éem w Turbo Pascalu zawsze co┼Ť pisz─Ö - ostatnio w Pythonie. Lubi─Ö technologie, mocn─ů kaw─Ö i dobre zdj─Öcia ­čĄÖ

Dodaj komentarz

Tw├│j adres e-mail nie zostanie opublikowany.