Запрос «чем заменить Zabbix» почти никогда не означает, что Zabbix плохой. Обычно он означает одно из трёх: сервер мониторинга требует больше внимания, чем системы, которые он мониторит; настройка нового узла превратилась в проект на неделю; или человек, который всё это когда-то настроил, уволился, и теперь никто не понимает, почему приходят эти алерты.
Давайте разберём честно: где Zabbix действительно хорош, где болит, какие есть варианты и как выбрать, не наступив на грабли ещё раз.
Что Zabbix делает хорошо
Начну с плюсов, потому что о них в статьях «10 альтернатив Zabbix» обычно забывают.
Zabbix — это зрелая система с двадцатилетней историей, которая умеет практически всё. Мониторинг по агенту и без него, SNMP, IPMI, автообнаружение узлов, шаблоны на любое оборудование, гибкая система триггеров с зависимостями, эскалации, распределённый мониторинг через прокси. Если у вас триста серверов, коммутаторы, ИБП и промышленные контроллеры, Zabbix закроет всё это одним инструментом — и это редкое качество.
У него нет лицензионных ограничений: сам продукт бесплатен полностью, без урезанной community-версии и без потолка по числу узлов. Для крупной инфраструктуры это часто решающий аргумент.
И у него огромное сообщество. На любую проблему найдётся ветка на форуме, готовый шаблон и статья с разбором.
Где начинает болеть
Проблемы Zabbix — обратная сторона его универсальности.
Первое: стоимость обслуживания самого мониторинга. Zabbix — это отдельный сервер, отдельная база данных, которая при активном сборе метрик растёт быстро и требует настройки хаускипинга и партиционирования, отдельный веб-интерфейс и, как правило, отдельный человек, который в этом разбирается. Для инфраструктуры из десяти-пятнадцати серверов вы получаете ситуацию, когда система мониторинга — самый сложный компонент во всём хозяйстве.
Второе: порог входа. Понятия «элемент данных», «триггер», «прототип элемента», «правило обнаружения», «макрос уровня узла» — это не сложно, но это нужно выучить. Настройка первого узла занимает полчаса, настройка первого нетипового мониторинга — полдня, а через полгода без практики всё это забывается. В командах, где мониторингом занимаются в фоновом режиме между другими задачами, конфигурация неизбежно устаревает.
Третье, и самое частое: Zabbix отвечает на вопрос «что случилось», но почти не отвечает на вопрос «что делать». Он покажет, что на диске кончается место и что нагрузка на процессор высокая. Он не покажет вам логи в момент аварии, не даст зайти на сервер, не позволит перезапустить контейнер — всё это вы делаете в других инструментах, переключаясь между вкладками и теряя контекст.
Четвёртое: Zabbix — это про инфраструктуру, а не про сервисы. Проверить, что сайт отдаёт двухсотый код и что сертификат не истекает, можно, но это будет ощущаться как использование грузовика для поездки в магазин. Отдельная страница статуса для клиентов, история инцидентов, отчёт по доступности за месяц — всё это придётся строить самому.
Куда обычно уходят
Разберу основные направления с их реальными плюсами и минусами.
Prometheus и Grafana
Стандарт де-факто в мире контейнеров и Kubernetes. Prometheus собирает метрики, Grafana рисует, Alertmanager рассылает уведомления.
Сильные стороны очевидны: мощнейший язык запросов PromQL, огромное количество экспортеров под любые системы, отличная работа с динамической инфраструктурой, где узлы появляются и исчезают. Если у вас Kubernetes — вопрос закрыт, идите сюда.
Слабые стороны тоже стоит назвать прямо. Вы получаете не одну систему, а связку минимум из трёх компонентов, каждый со своим конфигом. Prometheus — это pull-модель: он должен уметь достучаться до каждого узла, что в сетях с NAT и фильтрацией превращается в отдельную задачу. Долгосрочное хранение метрик из коробки не решено — рано или поздно вы придёте к Thanos или VictoriaMetrics и добавите ещё один компонент. И конфигурация здесь живёт в YAML-файлах: это прекрасно для инфраструктуры как кода и мучительно, если вы просто хотите добавить сервер через веб-интерфейс.
Итог: если Zabbix казался сложным в обслуживании, стек Prometheus сложнее. Он выигрывает не простотой, а мощностью и совместимостью с современной инфраструктурой.
Netdata
Противоположный полюс. Ставится одной командой, сразу после установки показывает сотни метрик с секундной детализацией, автоматически обнаруживает работающие сервисы и строит для них дашборды. Для быстрой диагностики «что происходит с сервером прямо сейчас» — вероятно, лучший инструмент из существующих.
Ограничения тоже понятные. Исторически Netdata — про один узел и короткую историю; централизованное хранение и долгие ретроспективы решаются через их облако или через собственную настройку стриминга. Система оповещений есть, но она проще, чем в Zabbix. И это по-прежнему инструмент про метрики: инциденты, дежурства, отчёты по SLA — не сюда.
Uptime Kuma
Лёгкий self-hosted мониторинг доступности: HTTP-проверки, TCP-порты, пинг, сертификаты, статус-страница из коробки. Ставится в докере за пять минут, интерфейс понятен без документации.
Отличный выбор, если задача — знать, что сайты и сервисы живы. Совершенно не подходит, если нужны метрики железа, логи, работа с базами и контейнерами. Это узкоспециализированный инструмент, и в этом его сила.
Облачные сервисы
Datadog, New Relic и подобные закрывают всё сразу: метрики, логи, трейсы, APM, алерты. Проблемы две, и обе прозаические. Цена растёт нелинейно с объёмом данных и числом узлов — счета в тысячи долларов в месяц для средней компании не редкость. И для российских компаний добавляется вопрос доступности сервиса, оплаты и, что важнее, места хранения данных: логи с продакшена уезжают за пределы контура, и это отдельный разговор с безопасностью и юристами.
Главный вопрос, который стоит задать до выбора
Прежде чем сравнивать инструменты, честно ответьте на один вопрос: сколько человеко-часов в месяц вы готовы тратить на обслуживание системы мониторинга?
Если ответ «сколько понадобится, у нас есть выделенный человек» — берите Zabbix или Prometheus и не читайте дальше, они дадут максимум возможностей.
Если ответ «в идеале нисколько, у нас два админа на всё» — то замена Zabbix на Prometheus вас не спасёт, вы просто поменяете один сложный инструмент на другой. Здесь нужно смотреть не на функциональность, а на то, сколько всего инструментов вам в итоге придётся держать.
Потому что реальная картина в небольшой компании обычно такая: Zabbix для метрик, Uptime Kuma для внешних проверок, что-то для логов, отдельный SSH-клиент, отдельная админка для баз, отдельный сервис для проверки SSL, таблица в Excel для учёта серверов и чат в мессенджере вместо системы инцидентов. Каждый инструмент по отдельности прост. Сумма — неуправляема, потому что контекст рассыпан по восьми местам, и в момент аварии человек тратит первые двадцать минут на то, чтобы просто собрать картину.
Аргумент в пользу объединения
Именно из этой боли выросла идея COSCIO: собрать в одной панели то, что обычно живёт в разных инструментах. Метрики серверов и контейнеров, логи, мониторинг доступности сайтов и сертификатов, инциденты с историей, бэкапы, SSH-терминал, админка баз данных, сканер уязвимостей, DNS и VPN. Одна авторизация, один интерфейс, один контекст.
Скажу честно про границы применимости, потому что нечестные сравнения в этом жанре надоели всем.
COSCIO не заменит Zabbix там, где нужен глубокий мониторинг сетевого оборудования по SNMP, промышленных систем, распределённых площадок с прокси и тысяч узлов. Zabbix в этой нише сильнее, и это нормально.
COSCIO не заменит Prometheus там, где инфраструктура живёт в Kubernetes и вся культура построена вокруг PromQL и метрик как кода.
Зато он закрывает довольно частый случай: от пяти до нескольких десятков серверов у разных провайдеров, немного контейнеров, пара сайтов, 1С и Битрикс24 где-то рядом, и команда из одного-двух человек, которым нужно видеть всё сразу, а не собирать картину из восьми вкладок. В этом сценарии выигрыш даёт не превосходство в метриках, а то, что от алерта до действия — один клик, а не переключение между системами.
Как мигрировать, не сломав то, что работает
Если вы решились на замену, не выключайте старый мониторинг сразу. Проверенный порядок такой.
Сначала поднимите новую систему параллельно и заведите в неё те же узлы. Пусть обе работают одновременно две-три недели. Это скучно, но именно так вы поймаете разницу в порогах и ложные срабатывания до того, как они станут единственным источником правды.
Затем перенесите алерты — но не все сразу, а начиная с тех, что реально стреляли за последний год. Загляните в историю: почти всегда выясняется, что из сорока настроенных триггеров срабатывали шесть, а остальные существуют только для того, чтобы их отключали.
Дальше переведите дежурства и уведомления на новую систему, оставив старую в режиме «смотрим, но не реагируем». Если через месяц она не сообщила ничего, чего вы не увидели в новой, — можно выключать.
И последнее: заведите документ, в котором написано, что мониторится, какие пороги и кому уходят уведомления. Одна страница текста. Именно её отсутствие превращает любую систему мониторинга через год в чёрный ящик, который «настраивал Серёжа, а Серёжа уволился».
Короткий вывод
Zabbix стоит менять не потому, что он устарел — он не устарел. Его стоит менять, когда сложность обслуживания перестала соответствовать размеру инфраструктуры или когда мониторинг оказался лишь одним из восьми инструментов, между которыми вы прыгаете во время аварии.
Если нужна максимальная глубина по железу и сети — оставайтесь. Если инфраструктура контейнерная — смотрите в сторону Prometheus. Если нужна быстрая диагностика одного узла — Netdata. Если нужны только внешние проверки — Uptime Kuma. Если проблема в том, что инструментов слишком много и контекст рассыпан, — тогда имеет смысл смотреть на объединённые платформы, включая нашу.
Главное — выбирать не по количеству галочек в сравнительной таблице, а по тому, сколько времени вы готовы тратить на сам мониторинг. Эта метрика в итоге определяет, будет система жить через год или превратится в ещё один сервер, который все боятся трогать.