ClickHouse в Zabbix 8: как устроено хранение истории и что происходит с трендами

В Zabbix 8 появилась штатная возможность хранить историю элементов данных в ClickHouse. Это позволяет вынести поток измерений в отдельное хранилище, сохранив привычные механизмы сбора данных, обработки значений и проверки триггеров.

При проектировании такой системы нужно учитывать важную особенность: для числовых данных, история которых направлена в ClickHouse, Zabbix не рассчитывает новые штатные тренды. Пока что так.

Меня зовут Антон Касимов, я работаю в Gals Software, веду телеграм‑канал Zabbix Recipes, посвященный Zabbix, где делюсь своим опытом. В этой статье поговорим об особенностях работы Clickhouse с новой версией Zabbix.

В обычной установке Zabbix реляционная база обслуживает разные задачи: хранит конфигурацию мониторинга, пользователей, события, историю измерений и часовые агрегаты. С подключением ClickHouse эти обязанности разделяются. Основная PostgreSQL/MySQL остаётся необходимой, а историю выбранных типов значений можно направить в ClickHouse или ElasticSearch.

Упрощённо движение данных выглядит так:

Выбор хранилища реализован через механизм HistoryProvider. Он сопоставляет тип значения с провайдером: например, все значения uint отправляются одному провайдеру, а все text — другому. Один тип нельзя одновременно назначить двум провайдерам. Типы, для которых отдельное назначение не задано, обслуживает SQL-провайдер по умолчанию.

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

Поддерживаются следующие соответствия:

Хранение бинарных значений этим провайдером не поддерживается. Zabbix proxy также не использует ClickHouse как собственное хранилище истории: он передаёт собранные значения серверу Zabbix.

После получения и обработки измерений сервер формирует пакеты записи. Текущий ClickHouse-провайдер отправляет их через HTTP/HTTPS, используя INSERT с форматом RowBinary. При чтении он строит запросы по идентификатору элемента данных и временному диапазону, получая результат в формате JSONCompactEachRow.

Обработка триггеров при этом остаётся на сервере Zabbix. Для вычислений используется кэш значений (value cache): нужные значения сохраняются в памяти, а при их отсутствии запрашиваются из хранилища. Подключение ClickHouse не означает, что каждое вычисление триггера обязательно будет вызывать отдельный запрос к нему. Размер и эффективность кеша вы по-прежнему определяете самостоятельно в конфигурации.

На стороне ClickHouse базовая схема использует таблицы семейства MergeTree. Например, для чисел с плавающей точкой сохраняются три основных поля:

• itemid — идентификатор элемента данных;

• clock_ns — время измерения с наносекундной точностью, тип DateTime64(9);

• value — значение Float64.

Первичный ключ состоит из itemid и clock_ns. Такой же в общем-то подход как для реляционных вариантов хранения.

В текущих скриптах начальные параметры — суточное партиционирование и TTL 31 день. Их можно изменить при создании схемы. Это значения по умолчанию, а срок хранения вы можете выбрать сами исходя из требований мониторинга и доступного дискового пространства.

Подключение на стороне сервера задаётся в zabbix_server.conf. Ниже пример для всех поддерживаемых типов:

HistoryProvider=clickhouse;value_types="uint,dbl,str,log,text,json",url=http://clickhouse.internal:8123,db=zabbix,username=zabbix,password=CHANGE_ME

Параметр поддерживает HTTP и HTTPS, а также настройки проверки сертификатов. Опция precache, включённая по умолчанию, позволяет предварительно загружать историю в value cache пакетами и ускорять его заполнение после перезапуска.

Отдельно настраивается PHP-интерфейс Zabbix. В zabbix.conf.php ему нужно указать соответствующее хранилище:

$HISTORY_PROVIDERS[] = [    'types' => ['uint', 'dbl', 'str', 'log', 'text', 'json'],    'provider' => 'clickhouse',    'url' => 'http://clickhouse.internal:8123',    'db' => 'zabbix',    'username' => 'zabbix',    'password' => 'CHANGE_ME'];

Сервер записывает историю, а веб-интерфейс обращается к ней при отображении данных. Поэтому очевидно, что настройки должны соответствовать друг другу.

Особого внимания требуют тренды в силу небольшого ограничения с их использованием. Напомню, что история сохраняет отдельные измерения (сырые данные), а тренды содержат часовые агрегаты числовых значений: минимум, максимум, среднее и количество измерений.

Например, при опросе раз в минуту один показатель создаёт 1440 исторических значений за сутки. При непрерывном поступлении данных им соответствуют 24 часовые записи трендов. Поэтому в традиционной схеме можно хранить подробную историю недолго, а агрегаты — несколько лет.

В текущей реализации ClickHouse-провайдер не включает возможность хранения трендов. В итоге, после переноса числового типа в ClickHouse новые тренды для него перестают формироваться. Они также не начинают автоматически записываться в PostgreSQL/MySQL.

Практические варианты получаются такими:

Если нужны многолетние штатные тренды, можно оставить uint и dbl в SQL, направив в ClickHouse только остальные типы:

HistoryProvider=clickhouse;value_types="str,log,text,json",url=http://clickhouse.internal:8123,db=zabbix,username=zabbix,password=CHANGE_ME

В конфигурации frontend тогда также указываются только str, log, text, json. Числовые значения продолжит обслуживать SQL-провайдер по умолчанию.

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

Удалением истории в ClickHouse управляет TTL. Housekeeper Zabbix эти данные не удаляет. В разделе Administration → Housekeeping интерфейс показывает срок хранения для соответствующих типов значений. Поэтому изменение периода в настройках элемента данных нельзя считать заменой настройке TTL таблицы. Например, срок хранения текстовой истории можно установить в 90 суток:

ALTER TABLE zabbix.history_textMODIFY TTL clock_ns + toIntervalSecond(7776000);

Физическое удаление просроченных данных выполняется во время фоновых слияний частей таблицы. Освобождение места может происходить после момента истечения TTL. Учитывайте это при расчёте дисковой ёмкости.

Миграция существующей инсталляции требует отдельного плана. При подготовке схемы учитывайте, что текущие скрипты её создания содержат удаление существующих таблиц (а вдруг).

Выбор архитектуры начинайте с требований к данным: если нужны штатные многолетние тренды Zabbix, числовую историю храните в SQL. Если требуется длительно хранить подробные измерения в ClickHouse, необходимо заложить соответствующий TTL, ёмкость хранилища и способ работы с долгосрочными агрегатами. Выбор, как всегда, остается за вами.

Спасибо за внимание!