Связку Zabbix + Grafana заменяют тремя способами: перейти на стек Prometheus/VictoriaMetrics + Alertmanager, если инфраструктура контейнерная и метрики нужны в pull-модели; взять открытую платформу наблюдаемости вроде Zabbix-альтернатив на базе OpenTelemetry, если помимо метрик требуются логи и трейсы; либо купить коммерческую платформу с единым интерфейсом и поддержкой вендора, если нет ресурсов держать двух-трёх инженеров на сопровождение. Выбор упирается не в функциональность агентов, а в то, кто будет чинить систему мониторинга в три часа ночи.
Что именно вы заменяете: сбор данных или визуализацию
Zabbix и Grafana решают разные задачи, и подменять их одним продуктом не всегда обязательно. Zabbix — это агент, сервер сбора, триггеры и эскалации. Grafana — только слой визуализации поверх чужих источников данных, своей базы метрик у неё нет (Grafana Mimir и Loki — отдельные продукты).
Отсюда практический вывод: если не устраивают дашборды, меняется одна Grafana — на Perses, Kibana или встроенный UI TSDB. Если тяжело даётся конфигурация шаблонов, LLD-правил и preprocessing в Zabbix, менять надо ядро сбора. А когда обе части раздражают одинаково, разумнее переходить на единую платформу наблюдаемости, где метрики, логи и трейсы лежат в одном хранилище и коррелируются по trace_id и меткам.
Практическое правило: пока число хостов меньше 300 и нет требований по логам и трейсам, миграция с Zabbix редко окупается. Проблемы начинаются на масштабе, когда истории в MySQL становится больше терабайта и housekeeping не успевает чистить партиции.
Какие альтернативы существуют и чем они различаются
Ниже — ориентировочное сравнение по ключевым для эксплуатации параметрам. Цифры по объёму данных приведены как порядок величины, они сильно зависят от интервала опроса и кардинальности метрик.
| Решение | Модель сбора | Метрики / логи / трейсы | Лицензирование | Кому подходит |
|---|---|---|---|---|
| Zabbix + Grafana | Push и pull, агент Zabbix, SNMP, IPMI | Метрики + базовая работа с логами, трейсов нет | Открытое ПО, поддержка отдельным контрактом | Классическая серверная и сетевая инфраструктура |
| Prometheus + Alertmanager + Grafana | Pull, exporters, service discovery | Только метрики, логи через Loki, трейсы через Tempo | Открытое ПО | Kubernetes, микросервисы, короткая история метрик |
| VictoriaMetrics (+ VictoriaLogs) | Pull и push, совместимость с PromQL (MetricsQL) | Метрики и логи, трейсов нет | Открытое ядро, кластерная версия — платно | Высокая кардинальность, длинное хранение |
| Стек на OpenTelemetry + ClickHouse | OTLP-коллекторы, автоинструментирование | Все три сигнала в одном хранилище | Открытое ПО, сборка своими силами | Команды с сильным SRE-отделом |
| Коммерческая платформа наблюдаемости | Агенты для Linux и Windows, OTLP | Метрики, логи, трейсы в едином центре мониторинга | По количеству контролируемых хостов, срочные и бессрочные лицензии | Требуется поддержка вендора и решение «под ключ» |
Разница между открытым стеком и коммерческим продуктом сводится к границе ответственности. В первом случае вы сами собираете конвейер: экспортёры, retention, шардирование, правила алертинга, дежурства. Во втором получаете готовую систему и SLA на исправление. Российские платформы для наблюдаемости — например, мониторинг ит систем — строятся на cloud-native архитектуре с горизонтальным масштабированием и отказоустойчивостью, собирают метрики, логи и трейсы распределённо и в реальном времени, поддерживают компоненты инфраструктуры и приложения на Linux и Windows; подробности по лицензированию есть на сайте.
Как спланировать миграцию, чтобы не потерять мониторинг
Переезд делают параллельным контуром, а не переключением рубильника. Обе системы работают одновременно две-четыре недели: старая остаётся источником истины для дежурной смены, новая набирает историю и калибрует пороги.
Порядок работ обычно такой:
- Инвентаризация: выгрузить список хостов, шаблонов и активных триггеров. Часть из них окажется мёртвой — обычно 20–40% триггеров не срабатывали ни разу за год, но проверять это надо по своим данным.
- Классификация алертов: что реально будит человека, а что идёт в почту и игнорируется. Переносить стоит только первую категорию, остальное — в дашборды.
- Раскатка агентов и коллекторов. Через Ansible или SCCM, с отдельным сегментом сети под коллекторы и явными правилами firewall.
- Перевод дашбордов. Автоконвертация PromQL-запросов в другой язык почти никогда не проходит чисто, панели удобнее пересобрать заново по списку SLI.
- Настройка ретенции и даунсемплинга. Сырые данные — 15–30 дней, агрегаты — год и больше; конкретные сроки зависят от требований аудита.
- Отключение старой системы только после того, как новая пережила хотя бы один реальный инцидент.
Типичные ошибки при замене системы мониторинга
- Переносят все триггеры «один в один». Вместе с ними мигрирует накопленный шум, и дежурные продолжают игнорировать алерты — эффект от смены платформы нулевой.
- Не считают кардинальность метрик. Метка с идентификатором запроса или контейнера порождает миллионы временных рядов, TSDB упирается в память и падает под нагрузкой, часто уже после запуска в продуктиве.
- Ставят мониторинг на те же серверы, за которыми он следит. При отказе стойки или гипервизора вместе с сервисом исчезает и система наблюдения, инцидент обнаруживают по звонку пользователей.
- Выбирают по числу готовых дашбордов, а не по модели данных. Красивые панели собираются за день, а невозможность связать лог с трейсом или отсутствие поддержки SNMP-опроса сетевого оборудования всплывает через месяц.
- Считают только стоимость лицензий. В открытом стеке платят временем инженеров: сопровождение, обновления, разбор падений хранилища. При расчёте бюджета сравнивают полную стоимость владения, а не строку в счёте.
- Гасят старую систему сразу после запуска новой. Первые недели вылезают пропуски в сборе и неверные пороги, а откатываться уже некуда.