Замена Zabbix на Checkmk ломает одну привычку и чинит три

MAATRIX

Если вы годами настраивали Zabbix — знаете это чувство: очередной новый хост, и снова руками создавать item'ы, вешать шаблон, править триггер, чтобы алерт не срабатывал на каждый чих. Checkmk предлагает другую модель: сервер сам находит, что мониторить, приносит готовые проверки почти на всё, и наглядно показывает состояние без ручной сборки дашборда. Но при переходе придётся отвыкать от привычного способа настройки — и это стоит понимать заранее, а не на третий день после миграции.

Что такое Checkmk и чем он отличается от Zabbix

Checkmk — система мониторинга с открытым ядром (Raw Edition, бесплатная и open source) и коммерческими редакциями поверх неё. Архитектурно он ближе к Nagios: под капотом лежит движок проверок в стиле Nagios/Icinga, а поверх — собственный слой автообнаружения, конфигурации через правила и веб-интерфейс (Multisite/WATO). Работает Checkmk как «сайт» внутри OMD (Open Monitoring Distribution) — изолированное окружение со своим пользователем, портами и процессами, что удобно, когда на одном сервере нужно несколько независимых инсталляций мониторинга.

Zabbix — централизованный сервер с базой данных, который хранит историю метрик, считает триггеры по выражениям и рассылает уведомления. Checkmk тоже хранит историю (в RRD и опционально в дополнительной БД для метрик), но модель сбора данных другая: агент на хосте не просто отдаёт значения по запросу, а сообщает о том, *что вообще есть* на машине — какие диски примонтированы, какие интерфейсы подняты, какие systemd-юниты активны, какие процессы запущены. Checkmk превращает это в список «сервисов» (services) — не путать с systemd-сервисами, это внутренний термин Checkmk для единицы мониторинга, будь то диск, интерфейс или конкретная проверка.

Ключевое отличие для практика: в Zabbix вы явно описываете, что мониторить (шаблон → item), а в Checkmk система сама предлагает список, а вы его утверждаете или подчищаете. Это разворачивает рабочий процесс на 180 градусов, и именно тут ломается многолетняя привычка.

Что ломается: привычная модель триггеров и шаблонов Zabbix

В Zabbix мысленная модель такая: хост → шаблон → items (что собираем) → triggers (когда алертить). Триггеры — это выражения на собственном языке Zabbix, что-то вроде:

last(/Linux server/vfs.fs.size[/,pfree])<10

Вы пишете это выражение руками (или редактируете унаследованное из шаблона), привязываете severity, настраиваете actions и escalations. Это гибко до предела — можно скомбинировать любые item'ы в одном триггере, посчитать производные метрики, задать сложные условия по времени. Но за гибкость платите тем, что вся логика мониторинга — это набор текстовых выражений, разбросанных по сотням триггеров, и когда нужно поменять порог «предупреждать при заполнении диска на 90%» сразу для полусотни хостов с разными шаблонами, вы идёте перебирать шаблоны и переопределения на хостах.

В Checkmk такой модели нет вовсе. Пороги и параметры проверок задаются через правила (rules) в WATO — иерархической системе, где правило можно применить глобально, на папку хостов, на хост-группу или на конкретный хост, и более специфичное правило переопределяет общее. Чтобы поднять порог свободного места на дисках со всех Ubuntu-серверов до 15%, вы редактируете одно правило на нужном уровне иерархии — оно применится ко всем подпадающим хостам сразу, без копирования по шаблонам.

Разница ощущается физически в первую неделю. Привычка «зайти в конкретный триггер и подправить выражение» просто не работает — в Checkmk нет текстовых выражений для порогов CPU, диска или памяти, есть формы с числовыми полями и правилами наследования. Первое время это раздражает: кажется, что теряешь контроль над точной формулировкой условия. На деле контроль остаётся, просто он реализован через таблицу правил с приоритетом, а не через язык выражений. К концу второй недели администраторы обычно перестают скучать по ручным триггерам — потому что типовые пороги (диск, память, load average, температура) в Checkmk и так покрыты правилами из коробки, и трогать их приходится реже, чем в Zabbix.

Второе, что ломается — привязка мониторинга к CMDB-мышлению Zabbix, где хост существует, только если вы его явно завели и подождали, пока агент начнёт отдавать данные по шаблону. В Checkmk хост заводится похожим образом (вручную или через API/динамическую инвентаризацию), но дальше все его сервисы обнаруживаются автоматически — и это не баг, а следующий пункт.

Чинит первое: автообнаружение сервисов вместо ручного добавления item'ов

Добавляете хост в Zabbix — выбираете шаблон вручную (Linux, Windows, MySQL, Nginx...), и получаете ровно те item'ы, которые в шаблон заложены. Если на сервере крутится специфичный сервис или нестандартный набор дисков, придётся либо искать готовый шаблон в Zabbix Share, либо писать свой.

В Checkmk процесс другой. Ставите агент, добавляете хост в веб-интерфейсе и запускаете обнаружение сервисов:

cmk -I myserver01
# или через интерфейс: Setup → Hosts → выбрать хост → Services → Discover services

Checkmk опрашивает агент и предлагает список найденного: все примонтированные файловые системы, все сетевые интерфейсы с их состоянием, все systemd-юниты, температурные датчики, RAID-контроллеры (если есть нужные утилиты), запущенные процессы, которые подходят под известные плагины (Postgres, MySQL, Docker, nginx, Apache, Redis и десятки других — если соответствующее ПО стоит на хосте, агент сам его находит). Вы просматриваете список, принимаете нужное одной кнопкой «Accept» или командой:

cmk -II myserver01   # полное переобнаружение
cmk -O myserver01     # применить найденное

Практическая выгода: когда на сервере появляется новый диск, новый сетевой интерфейс после реконфигурации сети или разворачивается новая база данных, Checkmk на следующем обнаружении сам это подхватит и предложит добавить в мониторинг — без похода в шаблон, без создания item'а руками. При регулярном автообнаружении по расписанию (можно включить периодическую проверку изменений) новые сервисы попадают в очередь на подтверждение сами, и администратор просто разбирает накопившееся раз в день-два.

Оборотная сторона — на первом обнаружении внушительного хоста Checkmk может выкатить полсотни предложенных сервисов, и часть из них будет не нужна (временные точки монтирования, loopback-интерфейсы, служебные systemd-таймеры). Это фильтруется правилами исключения один раз на группу хостов — так же, как настраиваются пороги — и дальше не мешает.

Чинит второе: сотни готовых проверок без написания шаблонов

В Zabbix из коробки есть неплохой набор шаблонов для типовых сценариев (Linux by Zabbix agent, MySQL, Nginx, Docker и другие), но стоит уйти чуть в сторону от типового стека — и вы либо ищете шаблон на Zabbix Share (там разное качество и актуальность), либо пишете свой на UserParameters, что требует времени и тестирования на каждом новом типе сервиса.

Checkmk поставляется с большой библиотекой встроенных плагинов проверок (check plugins) — это касается файловых систем, сетевых интерфейсов и их счётчиков ошибок, температуры и вентиляторов через IPMI, RAID-контроллеров (megaraid, hpsa, ClusterMD), баз данных (MySQL/MariaDB, PostgreSQL, MongoDB, Oracle через отдельные плагины), веб-серверов, очередей сообщений, Docker и Kubernetes, десятков сетевых устройств по SNMP (свитчи, роутеры, принтеры, ИБП) — большинство определяется автоматически по SNMP sysObjectID без ручной привязки MIB-файлов. Всё это активируется через то же автообнаружение: если на хосте нашёлся Postgres, Checkmk предложит сервисы для его мониторинга без дополнительной установки шаблона.

Разница на практике: там, где в Zabbix вы тратите час на поиск и адаптацию шаблона под конкретную версию софта, в Checkmk чаще всего проверка уже есть и просто появляется в списке обнаруженных сервисов. Это не значит, что кастомных проверок не бывает — для нестандартных случаев остаётся возможность писать собственные local checks (скрипт на хосте, который выводит результат в формате Checkmk и агент сам его подхватывает) или полноценные плагины на Python через официальный API. Но частота, с которой приходится это делать, заметно ниже, чем в Zabbix с UserParameters — потому что базовый набор из коробки просто шире.

Есть нюанс: у большого набора встроенных проверок есть цена — версии Raw и Enterprise отличаются количеством доступных плагинов и интеграций (часть специализированных чеков, например для некоторых сетевых вендоров или облачных провайдеров, доступна только в коммерческой редакции). Для типового Linux/Windows-парка с базой данных и веб-сервером бесплатной Raw Edition хватает с запасом; для гетерогенной enterprise-инфраструктуры стоит заранее свериться со списком плагинов на сайте проекта, прежде чем закладывать миграцию только на бесплатную версию.

Чинит третье: визуализация и работа с событиями из коробки

В Zabbix базовые графики и дашборды по элементам данных доступны сразу, но чтобы получить действительно удобный обзорный дашборд — сводку по хост-группам, тепловую карту проблем, красивые виджеты — приходится собирать его вручную из виджетов, а для серьёзной визуализации метрик многие в итоге выводят данные Zabbix в Grafana через отдельный плагин источника данных.

В Checkmk обзорные представления есть сразу после установки: дашборд хост-групп со статусами, представление «Проблемы» со всеми текущими некритичными и критичными сервисами, карта хостов (Host Overview), детальные графики по каждому сервису — Checkmk сам решает, какой график построить для конкретного типа проверки (загрузка CPU, использование диска, сетевой трафик in/out на одном графике с автоматическим масштабом). Не нужно предварительно решать, какие панели собирать — они генерируются на основе того, что обнаружено.

Второй практический плюс — обработка событий. В Zabbix триггер переходит в состояние Problem, и дальше вы настраиваете actions с условиями по severity, времени, тегам. В Checkmk есть похожая, но более наглядная модель Event Console (для обработки логов и SNMP-трапов как событий) и встроенная система уведомлений с правилами по получателям, каналам (email, Slack, Telegram через скрипты, PagerDuty, Opsgenie в Enterprise-редакции) и условиями эскалации — настраивается тоже через правила, а не через отдельный модуль actions с собственной логикой, как в Zabbix. Для администратора, который уже привык мыслить категориями «правило применяется по иерархии», это ложится ровно на ту же ментальную модель, что и пороги обнаружения — учить вторую систему не приходится.

Минус в том, что кастомизация внешнего вида дашбордов в Checkmk менее гибкая, чем в Grafana: для сложных комбинированных графиков из разных источников Grafana всё ещё выигрывает. Checkmk умеет отдавать метрики через встроенный Graphite/InfluxDB-коннектор или Livestatus, так что связка Checkmk + Grafana тоже возможна — но штатный интерфейс уже закрывает большинство повседневных задач визуализации без неё.

Перенос парка: как мигрировать и когда Checkmk не подходит

Миграция с Zabbix на Checkmk — это не перенос конфигурации, а настройка заново, и это стоит закладывать в план как отдельную работу, а не как «просто сменить агента». Разумный порядок: разверните Checkmk на отдельном сервере (не там, где живёт продакшн-Zabbix, чтобы оба работали параллельно во время перехода); установите агент на несколько тестовых хостов через встроенный Agent Bakery (Enterprise) или вручную из пакета deb/rpm/tar (в Raw Edition — только вручную или через свой Ansible); запустите автообнаружение и настройте базовые правила порогов на уровне папки хостов, а не на каждом хосте отдельно; перенесите уведомления и контакты и проверьте, что алерты реально доходят по нужным каналам. Только когда тестовая группа отработала стабильно одну-две недели без ложных срабатываний и без пропущенных инцидентов, переносите остальной парк волнами, а не разом, и держите Zabbix живым как страховку, пока команда не привыкла реагировать на алерты из новой системы.

Триггеры с сложной логикой (комбинация нескольких item'ов, производные метрики, окна обслуживания с нетривиальными условиями) придётся переосмыслить под модель Checkmk — прямого автоматического конвертера триггеров Zabbix в правила Checkmk в общем случае нет, и это самая трудозатратная часть переноса для зрелой инсталляции с сотнями кастомных триггеров.

Checkmk оправдан, когда у вас средний или крупный парк (условно от полутора-двух десятков серверов и выше), разнородный набор сервисов, и вы хотите тратить меньше времени на ручную настройку каждого нового хоста. Если у вас один-три сервера и задача — просто знать, жив ли сервис и не кончилось ли место на диске, полноценный Checkmk, как и Zabbix, будет избыточен по трудозатратам на настройку самого мониторинга: для такого масштаба разумнее лёгкие инструменты вроде Beszel или Uptime Kuma, которые поднимаются за несколько минут и не требуют освоения ни языка триггеров, ни модели правил. Checkmk и Zabbix — оба инструменты для «мониторинга парка», а не для домашнего VPS с одним сайтом.

Для парка из смешанного оборудования (сетевые устройства по SNMP, старые Windows-серверы, специфичный софт без готового шаблона ни там, ни там) стоит заранее прикинуть на тестовом стенде, чей набор готовых проверок покрывает вашу инфраструктуру лучше — иногда выгоднее остаться на Zabbix с его широкой поддержкой SNMP-шаблонов через community, чем переносить парк ради выигрыша в удобстве настройки.

Частые вопросы