Beszel на десяти серверах: Zabbix здесь — из пушки по воробьям

MAATRIX

У вас три, пять, десять серверов, и раз в пару недель вы вручную заходите на каждый проверить df -h и free -m. Ставить ради этого Zabbix с сервером, базой MySQL/PostgreSQL, веб-фронтом на PHP и агентами с полусотней параметров — как звать бригаду ремонтников, чтобы вкрутить лампочку. Beszel — тот случай, когда «лёгкий» не значит «игрушечный»: функций хватает для реального контроля маленького парка, а настройка занимает минуты, а не вечер с документацией.

Что такое Beszel и как он устроен

Beszel — open-source мониторинг на Go с архитектурой «хаб + агенты», внешне похожей на Zabbix, но радикально проще внутри. Хаб — один бинарник (или Docker-контейнер): поднимает веб-интерфейс и хранит данные в SQLite прямо на диске, без отдельной СУБД. Агент — тоже один бинарник, ставится на каждый наблюдаемый сервер и отдаёт хабу метрики.

Связь хаба с агентами построена на SSH-протоколе с парой ключей ed25519: при первом подключении хаб генерирует ключ, агент его принимает, и дальше обмен идёт по защищённому каналу без пароля и без TLS-сертификата, который нужно выписывать самому. У Zabbix агент и сервер общаются по собственному протоколу на 10050/10051, а безопасность канала (PSK, TLS) — отдельная задача администратора.

Ключевая идея Beszel — «поставил и сразу видно», без слоя конфигурации между установкой и первым графиком: никаких шаблонов хостов и элементов данных, которые нужно вручную привязывать к триггерам. Агент сам сообщает, что видит на сервере, хаб сам это рисует.

Установка: хаб и агент за две команды

Хаб поднимается через docker-compose:

services:
  beszel:
    image: henrygd/beszel
    container_name: beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel_data:/beszel_data

После docker compose up -d хаб доступен на порту 8090, там создаётся первый администратор — обычная форма логина, без лишнего. Дальше в интерфейсе создаётся система (сервер для мониторинга), и хаб сам генерирует команду установки агента с уже вшитым публичным ключом.

Агент на целевом сервере ставится либо тем же docker-compose, либо установочным скриптом, который кладёт systemd-юнит и бинарник напрямую — удобно, если сам сервер принципиально без Docker. Агентский docker-compose.yml:

services:
  beszel-agent:
    image: henrygd/beszel-agent
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    environment:
      HUB_URL: https://monitor.example.com
      TOKEN: полученный-в-интерфейсе-токен
      KEY: публичный-ключ-хаба
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /:/host:ro

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

Что видно из коробки

Без единого шаблона или триггера, настроенного руками, Beszel сразу показывает по каждому серверу:

• загрузку CPU (общую и по ядрам), среднюю нагрузку (load average);
• использование RAM и swap;
• занятость и I/O дисков по каждой примонтированной точке;
• сетевой трафик по интерфейсам (вход/выход);
• температуру, если сенсоры отдают её через стандартные Linux-механизмы;
• при подключённом Docker-сокете — CPU и память по каждому контейнеру отдельно.

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

Алерты настраиваются по порогам (CPU выше X% дольше Y минут, диск заполнен больше Z%) прямо в интерфейсе, без языка выражений и отдельного демона. Уведомления уходят через SMTP или webhook — а это открывает путь в Telegram, Discord, Slack, ntfy и вообще куда угодно, что принимает HTTP POST. Практическую потребность «пришли сообщение, если сервер горит» Beszel закрывает полностью — без танцев с медиатипами и эскалациями, на которые в Zabbix уходит отдельная настройка действий.

Требования к ресурсам

Хаб и агент — статически собранные Go-бинарники без рантайма вроде JVM или PHP-FPM, поэтому стартуют мгновенно и держат по памяти существенно меньше, чем связка Zabbix server + Zabbix web + MySQL. Точных цифр в мегабайтах намеренно не привожу — они зависят от числа серверов, частоты опроса и версии, и раздутые маркетинговые «занимает всего N МБ» на разных машинах не подтверждаются. Но порядок понятен: там, где Zabbix со своей базой комфортно чувствует себя от 2 ГБ RAM под сам сервер мониторинга, хаб Beszel спокойно уживается на том же VPS, что и рабочие нагрузки, и не требует отдельной машины ради факта мониторинга.

Агент ещё легче — единственный процесс, читающий /proc, /sys и статистику Docker и раз в интервал опроса отдающий снимок хабу. На VPS на 1 vCPU / 1 ГБ RAM он не создаёт заметной нагрузки, которую вы бы увидели в собственных же графиках CPU.

Практический вывод: под парк из 5-10 серверов хаб Beszel можно держать прямо на одном из этих же серверов (например, на панели управления), не выделяя под мониторинг отдельную машину — то, что для Zabbix обычно уже неудобно из-за нагрузки на базу.

Для какого масштаба Beszel — правильный выбор

Beszel закрывает нишу «есть парк серверов, хочу видеть его состояние на одном экране» без порога входа. Комфортно работает, когда:

• серверов от одного до полутора десятков — все помещаются на один дашборд без прокрутки и группировки по вкладкам;
• за инфраструктурой следит один человек или маленькая команда без чёткого разделения ролей;
• задача — «увидеть проблему и получить алерт», а не «построить отчёт для руководства за квартал»;
• парк однородный: обычные Linux-серверы и VPS, без сетевого оборудования и SNMP-устройств, которые нужно опрашивать отдельным протоколом.

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

Где Beszel сознательно не дотягивает до Zabbix

Честности ради — вот что Beszel физически не умеет, и это не баги, а следствие выбранной простоты:

Ничего из этого не чинится плагином за вечер — это архитектурные решения, ради которых Beszel и остаётся маленьким и быстрым. Если хотя бы один пункт из правого столбца нужен вам регулярно, а не «на всякий случай», — это уже сигнал смотреть в сторону полноценной системы.

Когда парк вырастает: сигналы, что пора менять инструмент

Переход не обязан быть резким — Beszel можно держать до последнего момента, пока он справляется. Конкретные признаки, что порог пройден:

• Серверов стало больше полутора-двух десятков, и дашборд превратился в бесконечную прокрутку без группировки и фильтров, которых в Beszel почти нет.
• Появилось сетевое оборудование — управляемые свитчи, роутеры, балансировщики, — которое нужно опрашивать по SNMP.
• Мониторингом занимается больше одного человека, и нужно разграничить, кто что видит и кем управляет.
• От вас требуют отчётность: SLA за месяц, статистика инцидентов, история простоев в презентабельном виде для клиента или руководства.
• Нужны сложные условия срабатывания: «алерт, только если CPU высокий одновременно с ростом очереди и это длится дольше 10 минут» — в Zabbix это связка триггеров, в Beszel это просто негде описать.

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

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