Uptime Kuma против Zabbix: что выгоднее и когда

MAATRIX

Оба бесплатны, оба называются «мониторинг» — и на этом сходство заканчивается. Один поднимается за полторы минуты и говорит «сайт лежит», второй требует базы, агентов и вечера настройки, зато отвечает «почему». Разберём, где какой выгоднее — с цифрами по памяти, росту базы и списком того, чего каждый физически не умеет.

Цена запуска: один контейнер против пяти компонентов

Uptime Kuma — один процесс Node.js и один файл SQLite. Образ louislam/uptime-kuma:1 весит около 400–500 МБ, docker compose up -d, и через 60–90 секунд на порту 3001 вас ждёт форма создания администратора. Конфигурационных файлов ноль, всё настраивается в вебе; подробности — в пошаговой установке.

Zabbix — пять компонентов: zabbix-server, база (MySQL 8.0 или PostgreSQL 16), zabbix-frontend-php поверх php8.3-fpm, Nginx и zabbix-agent2 на каждом наблюдаемом хосте. Схема заливается вручную из поставляемого дампа:

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | \
  mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

Импорт занимает минуту-две, свежая база весит около 100 МБ — это шаблоны и словари, данных там ещё нет. Дальше пароль прописывается в DBPassword внутри /etc/zabbix/zabbix_server.conf, иначе первый экран встретит строкой Connection to database 'zabbix' failed: [1045] Access denied for user 'zabbix'@'localhost'. А самая массовая жалоба новичка — жёлтая полоса вверху интерфейса:

Zabbix server is not running: the information displayed may not be current.

Это не поломка фронта: веб-интерфейс не достучался до демона по адресу из $ZBX_SERVER и $ZBX_SERVER_PORT в /etc/zabbix/web/zabbix.conf.php (обычно 127.0.0.1:10051). Диагностика — две команды: ss -lntp | grep 10051 и tail -50 /var/log/zabbix/zabbix_server.log.

Разница видна и по памяти в покое, до первого хоста:

# ps -eo rss,comm --sort=-rss | head -5
 412300 mysqld
  71540 php-fpm8.3
  46120 zabbix_server
  18300 nginx

Больше полугигабайта RSS на пустой инсталляции, и почти всё это MySQL. Kuma в том же состоянии занимает меньше четверти — одним процессом.

По времени: до рабочего мониторинга сайта в Kuma — пять минут, в Zabbix — вечер: репозиторий, база, схема, часовой пояс PHP, вход под Admin / zabbix, шаблоны, агенты. Плюс на каждом хосте порт агента открывается только для адреса мониторинга: ufw allow from 203.0.113.10 to any port 10050 proto tcp.

Что каждый видит: таблица и честные границы

Сравнивать полезнее не «мощность», а конкретные вопросы, с которыми вы придёте.

Две границы, о которых редко пишут прямо. Первая: Uptime Kuma в ветке 1.23 знает ровно одного пользователя — никаких ролей и отдельных аккаунтов, команда из четырёх человек ходит под общим паролем. Для домашнего проекта мелочь, для компании с аудитом — стоп-фактор.

Вторая: Zabbix смотрит изнутри. Его веб-сценарии выполняет сам сервер мониторинга, стоящий в том же периметре, что и продакшен. Сломается маршрут, DNS или правило на пограничном фаерволе — Zabbix будет рисовать зелёное, пока пользователи видят таймаут. Это следствие архитектуры и главный аргумент за гибрид.

База и рост: во что превращается год истории

Разница здесь на порядок и определяет цену сервера.

Uptime Kuma. Одна проверка — одна строка в таблице heartbeat файла /app/data/kuma.db. Сто мониторов с интервалом 60 секунд дают 144 000 строк в сутки; при строке около 100 байт это 14–15 МБ в день и порядка 0,45 ГБ в месяц. Хранение настраивается в Settings → Monitor History, по умолчанию 180 дней: в пределе файл выходит на 2,5–3 ГБ и там останавливается. Посмотреть у себя:

docker exec uptime-kuma sqlite3 /app/data/kuma.db "select count(*) from heartbeat;"
docker exec uptime-kuma du -h /app/data/kuma.db

В ветке 2 появились агрегаты stat_hourly и stat_daily — там старая история ужимается.

Zabbix. Считают в NVPS — новых значениях в секунду. Шаблон «Linux by Zabbix agent» даёт 60–100 элементов данных на хост, при типичных интервалах это около 1,5 значения в секунду с сервера. Двадцать хостов — примерно 30 NVPS. Строка в history_uint с индексами обходится в ~90 байт, значит:

30 × 86 400 × 90 ≈ 230 МБ в сутки

При штатном хранении истории в 31 день база выйдет на 6–7 ГБ и стабилизируется, плюс trends (часовые агрегаты, 365 дней) добавят несколько сотен мегабайт. Свои цифры — в Reports → System information, строка «Required server performance, new values per second», и на диске: du -sh /var/lib/mysql/zabbix.

Отдельная плата за объём — housekeeper: он подчищает историю построчно, и на семигигабайтной базе это заметная нагрузка. В /var/log/zabbix/zabbix_server.log появляются строки вида housekeeping ... deleted 1214320 rows in 214.918431 sec. Лечится либо укорачиванием истории в Administration → Housekeeping (семь дней истории при 365 днях трендов закрывают большинство задач), либо переходом на PostgreSQL с TimescaleDB, где старые куски удаляются чанками и сжимаются. Kuma в этом смысле беспроблемна: 20–40 ГБ хватит ей навсегда.

Алерты: разбудят по делу или зальют шумом

Uptime Kuma привязывает канал к монитору галочкой, умеет Retries, Heartbeat Retry Interval и повторную отправку, пока проблема жива. Чего в ней нет — зависимостей и эскалаций. Упал аплинк, и сорок мониторов честно пришлют сорок сообщений подряд, а через минуту — ещё сорок о восстановлении. Нет дежурств и нет «через 15 минут без подтверждения звони старшему». Разбор отказов канала — в отдельной статье.

Zabbix построен вокруг событий, логика тут богаче:

• Зависимости триггеров. «Сервис не отвечает» подавляется, если сработал родительский «хост недоступен» — вместо сорока сообщений придёт одно. Родитель обычно выглядит так: nodata(/srv-01/agent.ping,5m)=1.
• Эскалации. В действии задаются шаги: шаг 1 — Telegram дежурному, шаг 3 через 15 минут — письмо руководителю; всё останавливается по подтверждению проблемы.
• Окна обслуживания с флагом «Pause operations for suppressed problems»: плановая перезагрузка не поднимает шум.

Цена — свои грабли. Классика: действие настроено, а уведомления не уходят, потому что у пользователя не заведён media type; смотрите Reports → Action log, там статус Failed и No media defined for user. Вторая причина — права: нет доступа к хостгруппе, и операция молча не выполняется. После правки zabbix_server.conf изменения подхватываются не сразу — zabbix_server -R config_cache_reload.

Гибрид: Kuma снаружи, Zabbix внутри

Зрелые команды обычно не выбирают, а разводят роли. Zabbix внутри периметра отвечает за метрики, диски, базы и SNMP-железо. Uptime Kuma живёт на отдельном дешёвом VPS в другой стране и отвечает на один вопрос: «видно ли сервис снаружи прямо сейчас». Три связки, которые стоит настроить сразу:

• Kuma следит за самим Zabbix. TCP-монитор на порт 10051 плюс HTTP-монитор с ключевым словом на страницу фронта. Иначе падение сервера мониторинга окажется тихим — вы узнаете о нём ровно тогда, когда понадобятся алерты.
• Zabbix забирает метрики Kuma. Uptime Kuma отдаёт эндпоинт /metrics в формате Prometheus; авторизация — Basic Auth, где логин пустой, а пароль равен API-ключу из Settings → API Keys. Элемент типа HTTP agent затягивает это в общую картину.
• Push-монитор как dead man's switch. Kuma даёт URL вида https://kuma.example.com/api/push/<token>; его дёргает крон после успешного бэкапа, и тишина дольше заданного интервала считается падением. Pull-мониторинг такого не ловит: он проверяет, что сервис жив, а не что задача выполнилась.

Расхождение между системами само по себе диагноз: Zabbix показывает, что nginx жив и нагрузка нормальная, а Kuma из Лондона видит таймаут — дело в маршруте, DNS или пограничном правиле, а не в приложении.

Кому гибрид не нужен: сервисов меньше пяти и админ один — хватит Kuma плюс Netdata на самом сервере. Смежное сравнение — Zabbix или Prometheus.

Что заказать в MAATRIX под каждый сценарий

Требования разные — значит, и конфигурации разные.

Честно про нижние границы. Zabbix формально стартует на 2 ГБ, но MySQL с дефолтным innodb_buffer_pool_size = 128M читает индексы с диска, и график за месяц открывается секундами. Практический минимум — 4 ГБ и innodb_buffer_pool_size = 2G в /etc/mysql/mysql.conf.d/zabbix.cnf. У Kuma граница другая: гигабайта хватает, пока вы не включили мониторы Real Browser — каждый поднимает Chromium на 400–700 МБ, и OOM-killer гасит не браузер, а сам мониторинг.

Локация — Великобритания, Лондон, и это не вкусовщина: Kuma обязана стоять вне вашей сети и вашей автономной системы, иначе сторож на том же аплинке замолчит вместе с продакшеном. Лондон — нейтральная площадка с короткими маршрутами и в Европу, и в Россию. Франция даёт похожую картину; US берут под зарубежные API и ИИ-сервисы; RU — когда важно видеть сайт глазами клиента из Москвы. Удачная пара для российского бизнеса: Zabbix рядом с продом в RU, Kuma в Лондоне.

Uptime Kuma есть в каталоге apps.maatrix.io — при заказе сервера она разворачивается автоматически, команды из этой статьи вставлять руками не нужно. Автоустановка работает на Ubuntu и Debian, берите Ubuntu 24.04 LTS; адрес панели и учётные данные появятся в личном кабинете, в разделе «Доступ». После входа сразу смените пароль администратора, включите 2FA и привяжите домен с TLS. Под Zabbix берите чистую Ubuntu 24.04 LTS и ставьте по пошаговой инструкции.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, хотя сервер в Лондоне. Для мониторинга это тоже надёжность — сторож не должен выключаться из-за не прошедшего платежа. Начать можно с минимального тарифа: память и диск добавляются позже без переезда.

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