InfluxDB jako rozwiązanie dla metryk

Zaktualizowaliśmy ten tekst dla Ciebie!
Data aktualizacji: 30.12.2024
Autor aktualizacji: Maciej Jankosz

Istnieje wiele narzędzi do przechowywania i analizy metryk. Dziś chciałbym przedstawić InfluxDB – rozwiązanie, które było używane w firmie, w której kiedyś pracowałem. W listopadzie 2020 roku wydano wersję 2.0 InfluxDB. Podzielę się także swoimi doświadczeniami z wersją 1.0 w kontekście najnowszej wersji.

Zacznijmy od podstaw.

InfluxDB

Czym jest InfluxDB? To nierelacyjna baza danych przeznaczona do szeregów czasowych. Struktura rekordów jest dość prosta:

[pomiar],[tagi][pola][znacznik czasu]
weather,location=us-midwest temperature=82 1465839830100400200

Wyjaśnienie:

• Pomiar (measurement) – reprezentacja tabeli w InfluxDB.
• Tagi (tags) – wartości używane w filtrach.
• Pola (fields) – dane wykorzystywane jako punkty w wykresach, statystykach itp.
• Znacznik czasu (timestamp) – ponieważ InfluxDB to baza danych szeregów czasowych, jest on niezbędny.

Wypełnianie bazy danych

Początkowo najlepszym sposobem wprowadzania rekordów do naszej bazy danych było użycie Telegrafu – prostego narzędzia z potężną możliwością konfiguracji, które przesyłało dane do InfluxDB z wielu różnych źródeł (na przykład plików z dysku lub danych z Kafki). Od wersji 2.0 mamy kolejną świetną opcję. Ale najpierw najważniejsze.

Telegraf

Jak już wspomniałem, dzięki elastycznej konfiguracji, możemy zdefiniować wiele źródeł naszych danych. Spójrzmy na fragment przykładowej konfiguracji:

[[outputs.kafka]]
  ## Adresy URL brokerów Kafka
  brokers = ["localhost:9092"]
  ## Topic Kafka dla producentów wiadomości
  topic = "telegraf"

  ## Opcjonalny identyfikator klienta
  # client_id = "Telegraf"

  ## Ustawienie minimalnej obsługiwanej wersji Kafki.
  ## Ustawienie to umożliwia korzystanie z nowej wersji
  ## funkcji i interfejsów API Kafki.
  ## Szczególnie interesująca jest kompresja lz4
  ## wymaga co najmniej wersji 0.10.0.0.
  ##   ex: version = "1.1.0"
  # version = ""

  ## Opcjonalna konfiguracja sufiksu tematu.
  ## Jeśli sekcja zostanie pominięta, sufiks nie zostanie użyty.
  ## Obsługiwane są następujące metody sufiksu tematu:
  ## measurement – sufiks równy separatowori + nazwa pomiaru
  ## tags – sufiks równy separatorowi + wartości określonych tagów
  ## przeplatane z separatorem
 
  ## suffix równy „_” + nazwa pomiaru
  # [outputs.kafka.topic_suffix]
  #   method = "measurement"
  #   separator = "_"

  ## Sufiks równa się "__" + wartość znacznika pomiaru “foo”
  ## Jeśli nie ma takiego tagu, suffix jest równy pustemu ciągowi znaków    # [outputs.kafka.topic_suffix]
  #   method = "tags"
  #   keys = ["foo"]
  #   separator = "__"


  ## Suffix równa się „_” + pomiar „foo” i „bar”
  ## wartości tagów, oddzielone znakiem „_”. Jeśli nie ma takich tagów,     # ich wartości są traktowane jako puste ciągi.
  # [outputs.kafka.topic_suffix]
  #   method = "tags"
  #   keys = ["foo", "bar"]
  #   separator = "_"

  ## tag do użycia jako klucz routingu w Telegrafie
  ## tzn. jeśli ten tag istnieje, jego wartość zostanie użyta jako klucz routingu.
  routing_tag = "host"

  ## Statyczny klucz routingu. Używany, gdy nie jest ustawiony żaden routing_tag lub jako klucz awaryjny
  ## gdy tag określony w tagu routingu nie zostanie znaleziony.
  ## Jeśli ustawiony na „random”,
  ## losowa wartość zostanie wygenerowana dla każdej wiadomości.
  ##   ex: routing_key = "random"
  ##       routing_key = "telegraf"
  # routing_key = ""

  ## CompressionCodec reprezentuje różne kodeki kompresji rozpoznawane przez Kafkę w wiadomościach.
  ## 0 : Brak kompresji
  ## 1 : Kompresja Gzip
  ## 2 : Kompresja Snappy
  ## 3 : Kompresja LZ4 n
  # compression_codec = 0

  ## RequiredAcks jest używane w Produce Requests, aby powiedzieć brokerowi ile potwierdzeń repliki, które musi zobaczyć przed udzieleniem odpowiedzi
  ## 0 : producent nigdy nie czeka na potwierdzenie od brokera.
  ## Ta opcja zapewnia najniższe opóźnienie, ale najsłabszą trwałość
  ## (niektóre dane zostaną utracone, gdy serwer ulegnie awarii).
  ## 1 : producent otrzymuje potwierdzenie po otrzymaniu danych przez replikę lidera.
  ## Ta opcja zapewnia lepszą trwałość, ponieważ
  ## klient czeka, aż serwer potwierdzi, że żądanie się powiodło
  ## (tylko wiadomości, które zostały zapisane do martwego lidera, ale nie zostały jeszcze replikowane zostaną utracone).
  -1: producent otrzymuje potwierdzenie po tym, jak wszystkie zsynchronizowane repliki otrzymały dane.
Ta opcja zapewnia najlepszą trwałość,
gwarantowane, że żadna wiadomość nie zostanie utracona, dopóki instnieje przynajmniej jedna zsynchronizowana replika 
  # required_acks = -1

  ## Maksymalna liczba ponownych prób wysłania metryki przed niepowodzeniem do następnego zapisu danych
  # max_retry = 3

  ## Opcjonalna konfiguracja TLS
  # tls_ca = "/etc/telegraf/ca.pem"
  # tls_cert = "/etc/telegraf/cert.pem"
  # tls_key = "/etc/telegraf/key.pem"
  ## Użyj TLS, ale pomiń weryfikację łańcucha i hosta
  # insecure_skip_verify = false

  ## Opcjonalna konfiguracja SASL
  # sasl_username = "kafka"
  # sasl_password = "secret"

  ## Wersja protokołu SASL. Podczas łączenia się z Azure EventHub ustawiona na 0.
  # sasl_version = 1

  ## Format danych wyjściowych.
  ## Każdy format danych ma swój własny, unikalny zestaw opcji konfiguracyjnych.
  ## więcej na ich temat tutaj:   https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md
  # data_format = "influx"

Jak widzimy, można konfigurować wiele parametróe. Możemy nawet zdefiniować dodatkowe tagi.  

Wtyczek i opcji konfiguracyjnych jest znacznie więcej! Ale czekaj, to nie wszystko! Od wersji v2 możemy konfigurować telegraf i jego wtyczki za pomocą GUI (o czym napiszę później).

Scrapers

W wersji 2.0 dostępne są Scrapers – narzędzie, które co 10 sekund (domyślnie) pobiera dane w formacie Prometheus z określonego punktu końcowego REST. Konfiguracja odbywa się w GUI, co zajmuje zaledwie kilka chwil.

I to właściwie wszystko – prosto i szybko.

Flux

Flux to język zapytań stworzony dla InfluxDB. Jego struktura jest intuicyjna dla tego typu bazy danych. Przykład:

from(bucket:"example-bucket")
  |> range(start: -15m)
  |> filter(fn: (r) =>
    r._measurement == "cpu" and
    r._field == "usage_system" and
    r.cpu == "cpu-total"
  )

Oczywiście z Flux można zrobić o wiele, wiele więcej. Wszystkie niezbędne informacje znajdują się w dokumentacji flux-documentation. (w Influx v3, Flux nie będzie obsługiwany, więc warto o tym pamiętać)

Kapacitor

Kapacitor jest doskonałym narzędziem do agregacji i manipulacji zebranymi danymi. Od wersji 2.0 Kapacitor jest zintegrowany w jednym pakiecie wraz z GUI i InfluxDB. Wcześniej chodziło o tworzenie plików konfiguracyjnych z regułami dla naszego zadania, a ponieważ jest to teraz bardziej przyjazne dla użytkownika, skupię się na wersji 2.0. Przyjrzyjmy się przykładowemu zadaniu:

option task = {name: "test_task", every: 10m, offset: 1m}

data = from(bucket: "bucky")
    |> range(start: -task.every)
    |> filter(fn: (r) =>
        (r._measurement == "cpu" and r._field == "usage_idle"))

data
    |> aggregateWindow(every: 5m, fn: mean)
    |> to(bucket: "bucky_aggregated")

W tym przykładzie widzimy, że co 10 m będziemy agregować 5 m danych dla cpu idle, a wynik zapiszemy w bucket bucky_aggregated.

Rzućmy okiem na sposób tworzenia zadania za pomocą GUI

Chronograf

Chronograf (zintegrowany w wersji 2.0) to narzędzie GUI dla InfluxDB. Miało kilka dobrych stron, chociaż ponieważ InfluxDB w wersji 1.0 było samodzielną aplikacją, mogliśmy łatwo zintegrować ją z Grafaną – bardziej popularnym narzędziem do reprezentacji metryk. Ale szczerze mówiąc, użycie Chronografu w wersji 2.0 w tym momencie ma o wiele więcej sensu. Dzięki możliwościom łatwej konfiguracji Telegrafa, Scraperów i zadań apacitora, łatwej definicji zapytań i nie tylko, o wiele bardziej efektywne jest pozostanie przy nim. Dla przykładu, oto strona główna Chronografu w wersji 2.0 

OK, ale co z HA?

Cóż, to jest główny powód, dla którego wspominam o InfluxDB 1.0. Opcje wysokiej dostępności (High Availability) są zaimplementowane w wersji enterprise, chociaż dla wersji 1.0 stworzono rozwiązanie influx-ha, które spełniało wymagania systemów produkcyjnych. W wersji 2.0 InfluxDB wydała funkcję o nazwie Edge Data Replication. Edge Data Replication pozwala skonfigurować „bucket” w instancji open source InfluxDB, aby automatycznie replikować dane z tego bucket’u do bucket’u w instancji Cloud InfluxDB. 

Podsumowanie

InfluxDB to solidne rozwiązanie dla danych szeregów czasowych, szczególnie od wersji 2.0. Jest bardzo wydajna, potrafi obsłużyć miliony punktów danych na sekundę i sprawdza się w środowiskach produkcyjnych wymagających wysokiej wydajności.