Как использовать TimescaleDB в Zabbix

Зачем использовать TimescaleDB в Zabbix

TimescaleDB представляет собой расширение PostgreSQL для работы с временными рядами. Для Zabbix это особенно интересно, поскольку значительная часть базы данных состоит именно из данных, привязанных ко времени.

Вместо хранения больших таблиц истории как обычных таблиц PostgreSQL TimescaleDB позволяет преобразовать их в hypertable и автоматически распределять данные между отдельными временными чанками.

Это даёт несколько преимуществ:

эффективную работу с большими объёмами временных рядов;
разбиение больших таблиц на временные chunks;
возможность сжатия исторических данных;
удобное удаление старых данных по временным диапазонам;
сохранение привычной экосистемы PostgreSQL.

Как работают hypertable и chunks

Одна из основных возможностей TimescaleDB — hypertable.

Для приложения hypertable выглядит как обычная таблица PostgreSQL, но внутри TimescaleDB автоматически распределяет её данные между более мелкими физическими таблицами — chunks.

Упрощённо это можно представить так:

history
│
├── chunk 1
├── chunk 2
├── chunk 3
├── chunk 4
└── ...

Каждый chunk содержит данные определённого временного диапазона.

Для Zabbix такая модель хорошо подходит к таблицам истории, поскольку новые значения постоянно добавляются с временной меткой.

Что такое chunk_time_interval

При создании hypertable задаётся параметр:

chunk_time_interval

Он определяет временной диапазон данных, помещаемых в один chunk.

Например:

chunk_time_interval => 86400

Значение 86400 секунд соответствует одним суткам.

При таком значении TimescaleDB создаёт временные чанки примерно по одному дню данных.

Какие таблицы Zabbix переводятся в TimescaleDB

Zabbix предоставляет собственный SQL-скрипт, который создаёт необходимые hypertable и выполняет связанные с TimescaleDB настройки.

Для современных версий Zabbix путь выглядит так:

/usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql

Скрипт преобразует необходимые таблицы Zabbix в hypertable и выполняет дополнительную настройку TimescaleDB.

history

Таблица history хранит числовые значения с плавающей точкой: загрузку CPU, показания датчиков, различные коэффициенты и другие числовые метрики.

Принцип создания hypertable выглядит примерно так:

PERFORM create_hypertable('history', 'clock',
    chunk_time_interval => 86400,
    migrate_data => true,
    if_not_exists => true);

history_uint

history_uint используется для хранения беззнаковых целочисленных значений — например счётчиков и других количественных показателей.

PERFORM create_hypertable('history_uint', 'clock',
    chunk_time_interval => 86400,
    migrate_data => true,
    if_not_exists => true);

history_log

Таблица history_log предназначена для значений элементов данных типа Log.

PERFORM create_hypertable('history_log', 'clock',
    chunk_time_interval => 86400,
    migrate_data => true,
    if_not_exists => true);

history_text

history_text хранит длинные текстовые значения.

PERFORM create_hypertable('history_text', 'clock',
    chunk_time_interval => 86400,
    migrate_data => true,
    if_not_exists => true);

history_str

history_str используется для строковых значений.

PERFORM create_hypertable('history_str', 'clock',
    chunk_time_interval => 86400,
    migrate_data => true,
    if_not_exists => true);

history_bin

Таблица history_bin предназначена для бинарных значений.

PERFORM create_hypertable('history_bin', 'clock',
    chunk_time_interval => 86400,
    migrate_data => true,
    if_not_exists => true);

auditlog

TimescaleDB также может использоваться для таблицы аудита auditlog.

Здесь используется другая схема временного разбиения:

PERFORM create_hypertable('auditlog', 'auditid',
    chunk_time_interval => 604800,
    time_partitioning_func => 'cuid_timestamp',
    migrate_data => true,
    if_not_exists => true);

trends и trends_uint

Таблицы trends и trends_uint содержат агрегированные значения, используемые для долгосрочного хранения статистики.

Для них также создаются hypertable.

PERFORM create_hypertable('trends', 'clock',
    chunk_time_interval => 2592000,
    migrate_data => true,
    if_not_exists => true);

PERFORM create_hypertable('trends_uint', 'clock',
    chunk_time_interval => 2592000,
    migrate_data => true,
    if_not_exists => true);

Что делают migrate_data и if_not_exists

В SQL-скрипте можно встретить параметры:

migrate_data => true
if_not_exists => true

migrate_data указывает TimescaleDB перенести существующие записи обычной таблицы при её преобразовании в hypertable.

Это особенно важно при переходе уже работающего Zabbix с обычного PostgreSQL на TimescaleDB.

if_not_exists позволяет избежать попытки повторно создать уже существующую hypertable.

Сжатие данных TimescaleDB

Ещё одна важная возможность TimescaleDB — сжатие старых временных рядов.

Для системы мониторинга это особенно полезно: свежая история постоянно записывается и активно используется, а старые значения значительно реже изменяются.

Zabbix умеет управлять сжатием поддерживаемых TimescaleDB hypertable через настройки Housekeeping.

При этом у сжатия есть важное ограничение: работа со сжатыми chunks отличается от работы с обычными данными, а некоторые операции изменения над ними ограничены.

Установка TimescaleDB для Zabbix

Теперь перейдём к практической части.

В нашем примере используется PostgreSQL на системе семейства RHEL, например Rocky Linux.

Перед началом предполагается, что:

PostgreSQL уже установлен;
создана база данных Zabbix;
установлен пакет SQL-скриптов Zabbix;
выбрана версия TimescaleDB, поддерживаемая используемой версией Zabbix.

Шаг 1. Добавляем репозиторий TimescaleDB

Добавляем репозиторий TimescaleDB:

tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOL
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/$(rpm -E %{rhel})/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOL

Шаг 2. Устанавливаем TimescaleDB

В нашем примере используется PostgreSQL 16:

dnf install timescaledb-2-postgresql-16 timescaledb-2-loader-postgresql-16

Шаг 3. Настраиваем PostgreSQL через timescaledb-tune

После установки можно использовать утилиту:

timescaledb-tune

Она анализирует конфигурацию PostgreSQL и предлагает параметры для работы TimescaleDB.

В нашей тестовой конфигурации использовалась команда:

timescaledb-tune --pg-config /usr/pgsql-16/bin --max-conns=125

Настройка PostgreSQL для TimescaleDB с помощью timescaledb-tune

Шаг 4. Перезапускаем PostgreSQL

После изменения конфигурации перезапускаем PostgreSQL:

systemctl restart postgresql-16.service

И проверяем состояние:

systemctl status postgresql-16.service

Подключаем TimescaleDB к базе Zabbix

Установка пакетов TimescaleDB ещё не означает, что база Zabbix начала использовать hypertable.

Сначала необходимо активировать расширение в конкретной базе данных:

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

Проверить подключённое расширение можно через PostgreSQL:

sudo -u postgres psql -d zabbix -c "\dx timescaledb"

После этого необходимо выполнить штатный SQL-скрипт Zabbix.

Миграция существующей базы Zabbix в TimescaleDB

Если база уже содержит историю, преобразование таблиц может занять значительное время.

Перед началом:

сделайте резервную копию PostgreSQL;
убедитесь, что резервная копия пригодна для восстановления;
оцените размер таблиц истории;
запланируйте технологическое окно;
остановите Zabbix Server и frontend;
только после этого запускайте миграцию.

Для современной структуры пакетов Zabbix выполняем:

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

Во время выполнения скрипта на TimescaleDB 2.9 и новее могут появляться предупреждения о best practices. Для предупреждений, непосредственно описанных документацией Zabbix при выполнении этого штатного скрипта, это ожидаемое поведение.

Выполнение schema.sql для преобразования базы Zabbix в TimescaleDB

Проверяем, что таблицы стали hypertable

После выполнения миграции полезно проверить результат непосредственно в PostgreSQL.

Например:

sudo -u postgres psql -d zabbix -c "
SELECT hypertable_name
FROM timescaledb_information.hypertables
ORDER BY hypertable_name;"

В результате должны отображаться таблицы Zabbix, которые были преобразованы в hypertable.

Также можно проверить установленную версию расширения:

sudo -u postgres psql -d zabbix -c "
SELECT extname, extversion
FROM pg_extension
WHERE extname='timescaledb';"

Настройка Housekeeping в Zabbix

После подключения TimescaleDB часть настроек можно контролировать через веб-интерфейс Zabbix:

Administration → Housekeeping

Скрипт TimescaleDB настраивает параметры:

Override item history period;
Override item trend period;
Enable compression;
Compress records older than.

По умолчанию для сжатия используется период старше семи дней, если compression поддерживается используемой конфигурацией.

Override item history period

Параметр позволяет глобально переопределить период хранения history.

Override item trend period

Аналогичный параметр задаёт глобальное управление периодом хранения trends.

Для использования partitioned housekeeping одновременно для истории и трендов необходимо корректно настроить соответствующие override-параметры.

Удаление сжатых данных

Для удаления сжатых исторических данных через механизм Housekeeper необходимо правильно настроить параметры хранения.

В частности, для корректной работы с history и trends важны:

Override item history period;
Override item trend period.

Если в таблицах уже существуют сжатые chunks, а необходимые настройки housekeeping отключены, Zabbix может сообщать о некорректной конфигурации и не удалять ожидаемые данные.

Предупреждение о неподдерживаемой версии TimescaleDB

Отдельно стоит разобрать ситуацию, когда после обновления TimescaleDB Zabbix сообщает, что используемая версия базы данных не поддерживается.

В конфигурации Zabbix Server действительно существует параметр:

AllowUnsupportedDBVersions=1

Он позволяет Zabbix Server работать с версией базы данных, которую текущая версия Zabbix считает неподдерживаемой.

Если появилось предупреждение о версии TimescaleDB, правильный порядок действий следующий:

определить точную версию Zabbix;
проверить версию PostgreSQL;
проверить версию TimescaleDB;
свериться с матрицей поддерживаемых версий Zabbix;
при необходимости обновить Zabbix или использовать поддерживаемую версию TimescaleDB.

Проверить версию TimescaleDB можно командой:

sudo -u postgres psql -d zabbix -c "
SELECT extversion
FROM pg_extension
WHERE extname='timescaledb';"

Параметр AllowUnsupportedDBVersions имеет смысл использовать только осознанно, когда администратор понимает последствия работы на неподдерживаемой комбинации версий.

Что проверить после миграции

После завершения преобразования запускаем Zabbix Server и frontend и проверяем работу системы.

В первую очередь стоит проверить:

запуск Zabbix Server без ошибок;
поступление новых значений history;
построение графиков;
Latest data;
работу Housekeeper;
состояние compression;
журнал PostgreSQL;
журнал Zabbix Server;
рост размера базы данных.

Журнал Zabbix Server при systemd можно проверить командой:

journalctl -u zabbix-server -n 100 --no-pager

Если используется отдельный файл журнала, смотрим путь, заданный параметром LogFile в zabbix_server.conf.

Нужно ли использовать TimescaleDB на каждом Zabbix

TimescaleDB особенно интересна там, где база Zabbix активно растёт и необходимо эффективно работать с большим объёмом history и trends.

При этом устанавливать TimescaleDB только потому, что такая возможность существует, необязательно.

Перед миграцией стоит учитывать:

текущий размер базы;
скорость её роста;
количество новых значений в секунду;
периоды хранения history и trends;
производительность дисковой подсистемы;
объём доступной оперативной памяти;
сложность резервного копирования и восстановления;
готовность сопровождать PostgreSQL и TimescaleDB.

Для небольшой установки обычного PostgreSQL может быть вполне достаточно. TimescaleDB становится особенно полезной при росте объёма временных рядов и требований к длительному хранению.

FAQ

Что такое TimescaleDB в Zabbix?

TimescaleDB — расширение PostgreSQL для работы с временными рядами. Zabbix может использовать его hypertable для хранения history, trends и других поддерживаемых данных.

TimescaleDB заменяет PostgreSQL?

Нет. TimescaleDB устанавливается как расширение PostgreSQL и использует его инфраструктуру и инструменты администрирования.

Можно ли перевести существующую базу Zabbix на TimescaleDB?

Да. Штатный schema.sql Zabbix поддерживает преобразование существующих таблиц в hypertable. При большом объёме history, trends и auditlog миграция может занять значительное время.

Нужно ли останавливать Zabbix во время миграции?

Да. При миграции существующих данных Zabbix Server и frontend должны быть остановлены на время преобразования таблиц.

Где находится schema.sql для TimescaleDB?

Для современных версий Zabbix используется путь /usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql. В старых версиях расположение и имя файла могли отличаться.

Можно ли включить AllowUnsupportedDBVersions=1 при слишком новой TimescaleDB?

Технически параметр позволяет Zabbix работать с неподдерживаемой версией базы данных, но это не делает такую комбинацию официально поддерживаемой. Сначала лучше подобрать совместимые версии Zabbix, PostgreSQL и TimescaleDB.

Стоит ли включать сжатие TimescaleDB?

Сжатие может существенно уменьшить объём исторических данных, однако перед его использованием необходимо учитывать ограничения compressed chunks и правильно настроить Housekeeping.

Заключение

TimescaleDB хорошо подходит для Zabbix благодаря тому, что большая часть данных мониторинга представляет собой временные ряды. Hypertable и chunks позволяют эффективнее организовать хранение больших объёмов history и trends, а механизм compression помогает уменьшить объём старых данных.

При этом TimescaleDB нельзя рассматривать как кнопку «ускорить Zabbix». Перед внедрением необходимо правильно подобрать совместимые версии Zabbix, PostgreSQL и TimescaleDB, оценить размер существующей базы, подготовить резервную копию и запланировать время на миграцию.

Для существующей базы особенно важно выполнять преобразование штатным schema.sql из установленной версии Zabbix, остановить сервер и frontend на время миграции и проверить созданные hypertable после завершения процесса.

Отдельное внимание стоит уделить Housekeeping и compression. Именно корректное сочетание периодов хранения, разбиения данных и сжатия позволяет получить реальную пользу от TimescaleDB при росте инфраструктуры мониторинга.

Также рекомендую статью Как настроить двухфакторную аутентификацию (2FA) в Zabbix 7.0.