ClickHouse хранит историю Zabbix 8 без трендов

Zabbix 8 добавил встроенную поддержку отправки истории измерений в ClickHouse. Это позволяет разгрузить основную PostgreSQL или MySQL от потока сырых значений, сохранив сбор данных, обработку и срабатывание триггеров на сервере. Решение закрывает задачу долгосрочного хранения метрик большого объема без перегрузки реляционной базы. При этом числовые данные, ушедшие в ClickHouse, пока не участвуют в расчете штатных трендов. Перед внедрением важно понять, насколько критична потеря автоматических агрегатов и хватит ли ресурсов на поддержку двух систем одновременно.

Разделение потоков между базами

В классической схеме Zabbix вся нагрузка ложится на одну реляционную СУБД: конфигурация, события, история и часовые агрегаты. После подключения ClickHouse история выбранных типов значений уходит в отдельное хранилище, а конфигурация и события остаются в PostgreSQL. Сервер продолжает обрабатывать значения и проверять триггеры, но записи измерений формируются пакетами и отправляются через HTTP. Такой подход снижает размер таблиц в основной базе и ускоряет ее обслуживание. При этом proxy не использует ClickHouse напрямую и передает данные только серверу. В результате архитектура становится гибче, однако требует дополнительного контроля за двумя хранилищами одновременно.

Разделение потоков помогает при высокой интенсивности записи метрик, когда таблицы истории в PostgreSQL или MySQL быстро растут и замедляют запросы. ClickHouse здесь выступает как специализированное хранилище временных рядов, оптимизированное под большие объемы данных и быстрый поиск по диапазонам времени. Для администратора это означает, что нужно следить за синхронизацией конфигурации обеих систем и планировать мониторинг доступности каждого хранилища. Если в инфраструктуре уже есть опыт эксплуатации ClickHouse, переход упрощается; в противном случае добавляется новая точка отказа и необходимость обучения команды. Решение стоит рассматривать, когда объем сырых данных превышает возможности реляционной базы, но при этом не требуется сохранять все типы значений в одном месте.

Выбор типов через HistoryProvider

Механизм HistoryProvider привязывает тип значения к конкретному провайдеру. Один тип можно направить только одному хранилищу: все uint идут в одну таблицу, все dbl — в другую. Невозможно разделить значения одного типа между PostgreSQL и ClickHouse или назначить отдельные элементы данных. Таблицы ClickHouse используют MergeTree с ключом из itemid и времени с наносекундной точностью. Партиционирование по умолчанию суточное, TTL — 31 день, но эти параметры меняются при создании схемы. Бинарные значения провайдер не поддерживает. Такой механизм упрощает настройку, но ограничивает гибкость при выборе, какие именно метрики вынести.

HistoryProvider определяет, куда именно попадают измерения определенного типа, и это решение принимается на уровне всего сервера. Для практики это значит, что нельзя отправить в ClickHouse только самые тяжелые элементы данных одного типа, оставив остальные в реляционной базе. Если в мониторинге преобладают числовые метрики одного формата, механизм работает эффективно; при смешанных типах приходится либо переносить все значения типа, либо оставлять их в PostgreSQL. Отсутствие поддержки бинарных данных исключает хранение логов или снимков в том же потоке. При оценке решения стоит проверить, какие именно типы значений генерируют наибольший объем, и убедиться, что потеря гибкости не создаст дополнительных сложностей при масштабировании.

Тренды и работа триггеров

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

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

Применимость в российских установках

В российских контурах решение полезно при большом потоке метрик и дефиците ресурсов PostgreSQL. ClickHouse легко развернуть на собственных серверах, не прибегая к недоступным SaaS. Настройка требует синхронизации параметров в zabbix_server.conf и zabbix.conf.php, иначе веб-интерфейс не увидит данные. Отсутствие трендов вынуждает либо оставлять критичные числовые элементы в реляционной базе, либо строить собственные агрегаты в ClickHouse. При планировании стоит оценить объем истории, требования к срокам хранения и готовность команды поддерживать две СУБД. В текущем виде интеграция подходит для разгрузки, но не для полного отказа от расчета трендов.

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

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: ClickHouse хранит историю Zabbix 8 без трендов.

Курс по теме — Построение DWH на ClickHouse