Zabbix 6.4 -> 7.0 LTS: схема БД, нулевой простой и нативный HA-кластер

Zabbix 7.0 LTS вышел в июне 2024-го, и для нас это был первый LTS в новой мажорной ветке с действительно интересным изменением - нативным HA-кластером, который не требует Pacemaker, Corosync и всего сопутствующего зоопарка. После нескольких месяцев работы с 7.0 в тестовых контурах мы начали переводить production-инсталляции клиентов с 6.4. Вот что из этого вышло.

Что изменилось в схеме БД

Обновление с 6.4 на 7.0 LTS включает миграцию схемы - это не опция, это обязательный шаг, который выполняется автоматически при первом старте нового zabbix-server. Скрипт миграции прогоняет несколько ALTER TABLE, и на больших инсталляциях это занимает время.

Главные структурные изменения в 7.0:

Таблица history_text объединена с history_str. В 6.x они хранились отдельно - строковые значения до 255 символов в history_str, длинные тексты в history_text. В 7.0 это единая таблица с типом TEXT. Для инсталляций с большим количеством строковых метрик (log monitoring, трапы) - существенный рефакторинг, который затрагивает партиционирование если оно было настроено вручную.

Расширенная таблица auditlog для аудита конфигурации. Zabbix 7.0 добавил встроенный audit log с хранением в отдельной таблице. Если раньше использовался внешний аудит через action log, теперь есть нативный механизм - но нужно учесть что таблица будет расти и требует отдельной политики ретеншн.

Изменения в triggers и functions. Синтаксис выражений в триггерах изменился ещё в 6.x, но 7.0 добавил несколько новых встроенных функций и убрал часть устаревших. При обновлении с 6.4 несовместимых выражений обычно нет - 6.4 уже использует новый синтаксис - но если у клиента была инсталляция старше, обновлявшаяся поэтапно, стоит проверить.

На одной из наших инсталляций - PostgreSQL 15, около 200 хостов, история за 90 дней - миграция схемы заняла чуть больше 20 минут. Это важно закладывать в окно обслуживания: zabbix-server не стартует до завершения миграции, и в этот период мониторинг не работает.

Процедура обновления с минимальным простоем

Сразу про «нулевой простой»: полностью без простоя обновить одиночный Zabbix-сервер нельзя - миграция схемы требует эксклюзивного доступа. Но можно свести окно до времени миграции схемы, и для этого нужна правильная последовательность.

Мы применяем такую процедуру:

Шаг 1: обновить Zabbix-прокси. Если используются прокси - они совместимы вверх (proxy 7.0 работает с server 6.4). Обновляем прокси заранее, до основного окна. Буферизация данных на прокси означает, что данные не теряются, пока server недоступен.

Шаг 2: остановить zabbix-server, не трогая frontend. Frontend 6.4 на время миграции останется доступен для чтения уже собранных данных. Пользователи видят актуальные данные до момента остановки server-а, а не пустой экран.

Шаг 3: сделать pg_dump или снапшот диска. Без этого шага не двигаться дальше. Миграция схемы необратима в рамках той же инсталляции.

Шаг 4: установить новые пакеты, запустить zabbix-server 7.0. Сервер выполнит миграцию и поднимется. Время зависит от размера БД.

Шаг 5: обновить frontend. Frontend 7.0 несовместим с server 6.4, но совместим в обратную сторону - обновляем после того как убедились что server поднялся.

На практике у нас это укладывается в 25-40 минут в зависимости от размера БД. Agents при этом продолжают работать и накапливают данные в своём буфере (параметр BufferSize), так что метрики с периодом сбора до нескольких минут не теряются.

Нативный HA-кластер: наконец-то без Pacemaker

До 7.0, если нужен был HA для Zabbix-сервера, стандартный путь - Pacemaker + Corosync + shared storage или репликация PostgreSQL с failover. Это работает, но администрировать это поверх самого Zabbix - отдельная работа.

В 7.0 встроенный HA включается через HANodeName в конфиге zabbix-server:

HANodeName=node1
NodeAddress=192.168.1.10:10051

Каждый узел кластера запускается с уникальным HANodeName. Координация - через общую БД: узлы пишут heartbeat в таблицу ha_node, один из них становится active, остальные в standby. Нет отдельного кластерного ПО, нет fencing, нет stonith.

Что важно понимать про ограничения:

Shared-nothing архитектура не поддерживается. HA работает через общую БД - PostgreSQL должен быть доступен всем узлам. То есть это HA для Zabbix-сервера, не для всего стека. БД всё равно нужно защищать отдельно - Patroni, pgpool, или managed PostgreSQL.

Failover - не мгновенный. По умолчанию timeout на переключение - 60 секунд (параметр HAFailoverDelay). В это время новые данные не собираются, алерты не генерируются. Для большинства задач это приемлемо.

Frontend нужно конфигурировать отдельно. Frontend не знает про HA-кластер автоматически - нужно либо ставить load balancer перед несколькими frontend-инстансами, либо принять что frontend один и не является частью HA. В нашей практике frontend за nginx с health check на /api_jsonrpc.php - при падении основного узла переключаем nginx на вторичный вручную или через простой скрипт.

Мы настроили двухузловой кластер на одной из инсталляций: два Zabbix-сервера, общий PostgreSQL 15 (Patroni-кластер отдельно), nginx перед двумя frontend-инстансами. Тестовое переключение - вручную systemctl stop zabbix-server на active узле - failover произошёл за 65 секунд. Для managed-мониторинга это нормально.

Что ещё заметно в 7.0

Помимо HA, в 7.0 существенно переработан раздел по anomaly detection - baseline работает прямо в ядре без внешних зависимостей. Мы разбирали это отдельно, здесь только отметим: включение anomaly detection через ANOMALY_DETECTION preprocessing - одна из причин, по которым 7.0 стоит переходить, а не сидеть на 6.4 до следующего LTS.

Ещё одно заметное изменение - переработанный Business Service Monitoring. В 7.0 он стал значительно гибче: SLA-расчёт, иерархия сервисов, separate dashboard для BSM. Для клиентов, которым нужен отчёт «что сломано и как это влияет на бизнес-сервис» - это теперь работает из коробки нормально.

Где сейчас

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

Нативный HA в продуктиве у одного клиента - пока без реальных инцидентов, что хорошо. Плановое тестирование failover раз в квартал заложили в регламент.

Работу по поддержке и мониторингу инфраструктуры клиентов мы ведём на постоянной основе, и для нас переход на новый LTS - это не разовая акция, а планомерная работа с каждой инсталляцией. Схема БД у всех немного своя, и каждый раз находится что-нибудь интересное.