Wprowadzenie do InfluxDB

4 lat temu

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). dzięki szeregów czasowych możemy przedstawić np.:

zmiany temperatury powietrza, ciśnienia atmosferycznego, wilgotności, zawartości CO₂, 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. o ile 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 uproszczeniu – 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. o ile pracowałaś kiedyś z np. MySQL, MongoDB czy dowolną inną bazą danych która nie skupia się na szeregach czasowych to wiesz, iż 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ć iż 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 dzięki 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żeli 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 adekwatnymi 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 iż sam InfluxDB jest oprogramowaniem open source, warto więc również wspomnieć iż 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 uproszczeniu 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 dzięki dashboardów. Znajdziemy tu również interesujące 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 dzięki 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 iż masz Dockera i pracujesz na Linuxie. o ile 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, o ile 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. o ile 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: