6 Konfiguracja TimescaleDB

Przegląd

Zabbix obsługuje TimescaleDB, rozwiązanie bazodanowe oparte na PostgreSQL, które automatycznie partycjonuje dane na fragmenty oparte na czasie, aby zapewnić wyższą wydajność przy dużej skali.

Obecnie TimescaleDB nie jest obsługiwany przez Zabbix proxy.

Instrukcje na tej stronie można wykorzystać w następujących scenariuszach:

  • Tworzenie bazy danych TimescaleDB lub migracja z istniejących tabel PostgreSQL do TimescaleDB (zobacz Konfiguracja).
  • Aktualizacja schematu istniejącej bazy danych TimescaleDB podczas aktualizacji Zabbix (zobacz Aktualizacja schematu TimescaleDB).

Konfiguracja

Wymagania wstępne: Zainstalowane rozszerzenie TimescaleDB w obsługiwanej wersji na serwerze bazy danych. Instrukcje instalacji znajdują się w dokumentacji TimescaleDB.

Przed instalacją TimescaleDB zainstaluj obsługiwaną wersję PostgreSQL z repozytorium oficjalnego PostgreSQL.

Włącz rozszerzenie TimescaleDB dla określonej bazy danych, wykonując:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Wykonanie tego polecenia wymaga uprawnień administratora bazy danych.

Jeśli używasz schematu bazy danych innego niż 'public', musisz dodać do powyższego polecenia klauzulę SCHEMA. Na przykład:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb SCHEMA yourschema CASCADE;" | sudo -u postgres psql zabbix

Następnie uruchom skrypt postgresql/timescaledb/schema.sql. W przypadku nowych instalacji skrypt musi zostać uruchomiony po utworzeniu standardowej bazy danych PostgreSQL z początkowym schematem/danymi (zobacz tworzenie bazy danych).

cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbix

Zignoruj komunikaty ostrzegawcze informujące, że podczas uruchamiania skryptu schema.sql w wersji TimescaleDB 2.9.0 i nowszych nie są stosowane najlepsze praktyki. Niezależnie od tego ostrzeżenia konfiguracja zostanie ukończona pomyślnie.

Migracja istniejących danych historycznych, trendów i dziennika audytu może zająć dużo czasu. Serwer Zabbix i frontend muszą być wyłączone na czas migracji.

Skrypt schema.sql ustawia następujące parametry housekeeping:

  • Nadpisz okres przechowywania historii pozycja
  • Nadpisz okres trendów pozycja

Aby używać partycjonowanego housekeeping dla historii i trendów, obie te opcje muszą być włączone. Możliwe jest również włączenie nadpisywania osobno tylko dla historii albo tylko dla trendów.

Skrypt postgresql/timescaledb/schema.sql ustawia dwa dodatkowe parametry:

  • Włącz kompresję
  • Kompresuj rekordy starsze niż 7 dni

Aby housekeeper mógł pomyślnie usuwać skompresowane dane, muszą być włączone obie opcje: Override item history period oraz Override item trend period. Jeśli nadpisywanie jest wyłączone, a tabele zawierają skompresowane fragmenty, housekeeper nie będzie usuwał danych z tych tabel, a ostrzeżenia o nieprawidłowej konfiguracji będą wyświetlane w sekcjach Housekeeping oraz System information.

Wszystkie te parametry można zmienić w Administracja > Housekeeping po instalacji.

Możesz uruchomić narzędzie timescaledb-tune dostarczane przez TimescaleDB, aby zoptymalizować parametry konfiguracji PostgreSQL w pliku postgresql.conf.

Aktualizacja schematu TimescaleDB

Podczas aktualizacji Zabbixa do wersji zawierającej nowe hypertables TimescaleDB, serwer Zabbix nie konfiguruje ich automatycznie (na przykład podczas aktualizacji z Zabbix 6.4 do 7.0.3, ponieważ wersje 7.0.0 i 7.0.2 wprowadziły nowe hypertables).

Aby skonfigurować nowe hypertables TimescaleDB, wykonaj następujące kroki:

  1. Uruchom serwer Zabbix; spowoduje to aktualizację istniejącej bazy danych.
  2. Sprawdź w pliku dziennika serwera, czy aktualizacja bazy danych została zakończona; po zakończeniu zatrzymaj serwer Zabbix. Zwróć uwagę, że serwer zapisuje ostrzeżenie, jeśli próbuje włączyć kompresję dla tabeli, która nie jest hypertable.
  3. Uruchom skrypt postgresql/timescaledb/schema.sql; skonfiguruje on nowe hypertables TimescaleDB. Zwróć uwagę, że od Zabbix 7.0.0 lokalizacja i nazwa skryptu zmieniły się z postgresql/timescaledb.sql na postgresql/timescaledb/schema.sql.

Zignoruj komunikaty ostrzegawcze informujące, że podczas uruchamiania skryptu schema.sql w wersji TimescaleDB 2.9.0 i nowszych nie są przestrzegane najlepsze praktyki. Niezależnie od tego ostrzeżenia konfiguracja zostanie pomyślnie zakończona.

Kompresja TimescaleDB

Natywna kompresja TimescaleDB jest obsługiwana dla wszystkich tabel Zabbix, które są hypertabelami TimescaleDB. Podczas aktualizacji lub migracji do TimescaleDB początkowa kompresja dużych tabel może zająć dużo czasu.

Należy pamiętać, że kompresja jest obsługiwana w ramach licencji społecznościowej Timescale "timescale" i nie jest obsługiwana w ramach licencji Apache 2.0 "apache". Jeśli Zabbix wykryje, że kompresja nie jest obsługiwana, do logu serwera Zabbix zostanie zapisany komunikat ostrzegawczy, a użytkownicy nie będą mogli włączyć kompresji w frontend.

Zaleca się zapoznanie z kompresją w dokumentacji TimescaleDB przed jej użyciem.

Należy pamiętać, że kompresja nakłada pewne ograniczenia, w szczególności:

  • Modyfikacje skompresowanych chunków (wstawianie, usuwanie, aktualizacje) nie są dozwolone
  • Zmiany schematu dla skompresowanych tabel nie są dozwolone.

Ustawienia kompresji można zmienić w bloku Kompresja historii, trendów i dziennika audytu w sekcji Administracja > Housekeeping frontend Zabbix.

Parameter Default Comments
Enable compression Enabled Zaznaczenie lub odznaczenie pola wyboru nie aktywuje/dezaktywuje kompresji natychmiast. Ponieważ kompresją zarządza Housekeeper, zmiany zaczną obowiązywać w ciągu maksymalnie 2 razy HousekeepingFrequency godzin (ustawione w zabbix_server.conf)

Po wyłączeniu kompresji nowe chunki, które trafią do okresu kompresji, nie będą kompresowane. Jednak wszystkie wcześniej skompresowane dane pozostaną skompresowane. Aby zdekompresować wcześniej skompresowane chunki, postępuj zgodnie z instrukcjami w dokumentacji TimescaleDB.

Podczas aktualizacji ze starszych wersji Zabbix z obsługą TimescaleDB kompresja nie będzie domyślnie włączona.
Compress records older than 7d Ten parametr nie może być mniejszy niż 7 dni.

Ze względu na niezmienność skompresowanych chunków wszystkie późne dane (np. dane opóźnione przez proxy), które są starsze niż ta wartość, zostaną odrzucone.

:::note Aby uzyskać lepszą wydajność aktualizacji trendów, warto zmniejszyć wartość "chunk_time_interval" dla tabel trends i trends_uint z 30 dni do 7 dni lub mniej, w zależności od liczby pozycji korzystających z trendów. Celem tego ustawienia jest dostosowanie się do najlepszych praktyk TimescaleDB oraz zapewnienie, że rozmiar chunków pozostaje w granicach dostępnych zasobów systemowych. :::