OceanBase для Zabbix: что важно при миграции мониторинга с PostgreSQL

Zabbix быстро превращается из удобного инструмента мониторинга в тяжёлую базу данных. Метрики, history, trends, события, discovery и новые хосты растут постоянно. Если storage выбран без запаса, через несколько лет мониторинг начинает сам становиться источником проблем: медленные запросы, большой объём таблиц, сложные backup, долгие maintenance window.

Один из вариантов оптимизации — миграция backend-базы на другую СУБД. Например, рассмотреть OceanBase для сценария, где Zabbix раньше работал на PostgreSQL или MySQL. Но такая миграция — не просто «перелить данные». Это инфраструктурный проект, в котором важны совместимость, поток изменений, проверка производительности и план отката.

Почему Zabbix раздувает базу

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

• таблицы history;
• trends;
• события и alerts;
• discovery-данные;
• audit и operational logs;
• служебные индексы.

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

Зачем рассматривать OceanBase

OceanBase интересен как распределённая СУБД, рассчитанная на большие объёмы и горизонтальное масштабирование. Для Zabbix потенциально важны две вещи: экономия места и способность выдерживать интенсивные операции записи.

Но выбор СУБД нельзя делать только по обещаниям. Нужно проверить:

• совместимость SQL и драйверов;
• поведение типовых запросов Zabbix;
• скорость вставок;
• работу индексов;
• backup и restore;
• мониторинг самой СУБД;
• эксплуатационную сложность.

Иногда экономия storage может быть съедена ростом operational complexity.

Онлайн-миграция и CDC

Если Zabbix нельзя останавливать надолго, нужен механизм переноса данных с минимальным простоем. Один из подходов — Change Data Capture: сначала переносится основной объём, затем догоняются изменения.

Flink CDC или похожий инструмент может читать изменения из PostgreSQL и применять их в целевую базу. Но это добавляет отдельный слой, который тоже нужно мониторить.

Критичные вопросы:

• есть ли lag репликации;
• все ли типы данных корректно мапятся;
• что происходит при ошибке записи;
• можно ли безопасно перезапустить pipeline;
• как проверить консистентность;
• где точка переключения.

CDC снижает downtime, но повышает требования к наблюдаемости.

Начинать с dev-контура

Мигрировать сразу production-мониторинг рискованно. Лучше сначала поднять dev или staging-контур Zabbix, перенести туда реальные объёмы данных и нагрузить типовыми сценариями.

Проверять нужно не только старт приложения, но и ежедневную эксплуатацию:

• открытие dashboards;
• тяжёлые screens;
• построение графиков за длинный период;
• housekeeping;
• discovery;
• alerts;
• backup;
• восстановление после сбоя.

Если тест ограничить только успешным запуском Zabbix, часть проблем всплывёт уже после переключения.

Экономия места — не единственная метрика

Снижение размера данных в 10–15 раз выглядит впечатляюще, но для production-решения важны и другие параметры:

• latency UI;
• скорость записи метрик;
• нагрузка на CPU и RAM;
• сложность обслуживания;
• стоимость администрирования;
• поведение при росте данных;
• время восстановления;
• доступность специалистов по СУБД.

Инфраструктурные решения часто проигрывают не из-за плохой технологии, а из-за нехватки команды, которая сможет её поддерживать.

Rollback-план

У любой миграции должен быть план отката. Особенно если речь о мониторинге, который нужен для диагностики остальных систем.

Минимум:

• backup исходной базы;
• сохранённый старый Zabbix-контур;
• понятная точка остановки записей;
• проверка целевой базы перед switch;
• documented rollback steps;
• окно наблюдения после переключения;
• список метрик, по которым принимается решение.

Если rollback не проверен, миграция становится однонаправленным прыжком.

Итог

Миграция Zabbix на OceanBase или любую другую СУБД может дать большой выигрыш по storage и производительности, но только при аккуратной подготовке. Нужно измерить текущие объёмы, протестировать совместимость, прогнать CDC, проверить UI-сценарии и заранее подготовить откат.

Главное правило: мониторинг — критичная система. Экспериментировать с ним можно, но только через staging, метрики и проверяемый план восстановления.