Легковесный мониторинг серверов и Docker в Beszel: развертывание панели и агентов с потреблением 15 МБ RAM

Для системных администраторов, разработчиков и владельцев нескольких виртуальных серверов (VDS) мониторинг инфраструктуры всегда был компромиссом между глубиной метрик и потреблением системных ресурсов. Классический промышленный стек Prometheus + Grafana + Node Exporter + cAdvisor прекрасен в корпоративных кластерах, но на недорогих серверах с 1–2 ГБ оперативной памяти он мгновенно «съедает» от 600 до 1200 МБ RAM, перегружает дисковую подсистему постоянной записью временных рядов (TSDB) и регулярно провоцирует падение критических сервисов из-за срабатывания ядра Linux OOM-Killer.

Легковесные альтернативы вроде Netdata обеспечивают красивую детализацию в реальном времени, однако при установке на каждый сервер они потребляют 100–200 МБ памяти и требуют сложного централизованного хранилища. Настоящим прорывом в сообществе self-hosted и DevOps стал проект Beszel (набравший огромную популярность на GitHub и форумах r/selfhosted). Это современный легковесный мониторинг серверов и Docker-контейнеров, агент которого написан на Go и потребляет всего 10–15 МБ RAM, а центральная панель управления (Hub) с встроенной базой данных PocketBase укладывается в 25–40 МБ RAM.

В этом руководстве разберем архитектуру Beszel, развернем центральный узел (Hub) в Docker Compose за обратным прокси Nginx с поддержкой WebSockets и SSL, подключим агенты на целевых серверах с доступом к метрикам Docker-контейнеров и настроим мгновенные алерты в Telegram при исчерпании ресурсов.

1. Почему Beszel взрывает тренды: сравнение с Prometheus, Grafana и Netdata по потреблению RAM

Чтобы понять причину популярности Beszel, достаточно взглянуть на замеры потребления оперативной памяти и утилизации диска при мониторинге небольшого парка из 3–5 серверов:

Beszel изначально спроектирован для разработчиков и системных администраторов, которым не нужны сотни сложных метрик ядра Linux. Ему достаточно фиксировать фундаментальные показатели стабильности узла: загрузку процессора, использование оперативной памяти и Swap, свободное место на всех подключенных дисках, входящую и исходящую сетевую скорость, температуру процессора, а главное — потребление ресурсов каждым запущенным Docker-контейнером в реальном времени.

2. Архитектура Beszel: как устроены Hub, Agent и защищенная связь по WebSocket

Инфраструктура Beszel разделена на два независимых компонента:

• Beszel Hub (Центральный сервер): компактный веб-интерфейс со встроенной легковесной базой данных SQLite (на движке PocketBase). Он собирает и агрегирует метрики, строит интерактивные графики, управляет учетными записями пользователей и отправляет оповещения. Hub можно развернуть на любом домашнем сервере или недорогом VDS.
• Beszel Agent (Клиентский агент): минималистичный бинарный демон или микроконтейнер, запускаемый на каждом отслеживаемом сервере. Он собирает системные метрики хоста через cgroups и /proc, а также считывает статистику контейнеров через сокет /var/run/docker.sock.

Для подтверждения подлинности используется асимметричная криптография: при добавлении сервера в веб-интерфейсе Hub генерирует публичный ключ (KEY) и токен авторизации (TOKEN). Агент принимает запросы только от владельца соответствующего закрытого ключа, что исключает возможность перехвата или фальсификации данных.

3. Развертывание панели управления Beszel Hub в Docker Compose с лимитами ресурсов

Развернем центральный узел Beszel Hub. Создайте рабочую директорию на вашем основном сервере (например, /opt/beszel-hub):

sudo mkdir -p /opt/beszel-hub/beszel_data
cd /opt/beszel-hub

Создайте конфигурационный файл docker-compose.yml:

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel-hub
    restart: unless-stopped
    # Привязываем порт строго к локальному интерфейсу 127.0.0.1 для защиты периметра
    ports:
      - "127.0.0.1:8090:8090"
    volumes:
      - ./beszel_data:/beszel_data
    environment:
      # Укажите внешний публичный URL вашего хаба с HTTPS
      APP_URL: "https://monitor.yourdomain.ru"
    # Лимиты ресурсов: Beszel крайне экономичен, 150 МБ RAM хватит с 3-кратным запасом
    mem_limit: 256m
    cpus: 0.50

Запустите контейнер Beszel Hub:

sudo docker compose up -d

Проверьте статус работы контейнера и фактическое потребление ресурсов утилитой docker stats:

sudo docker stats --no-stream beszel-hub

Вы увидите, что свежезапущенный хаб со встроенной базой данных потребляет всего 20–30 МБ памяти — в 25 раз меньше, чем пустая связка Prometheus и Grafana.

4. Настройка Nginx Reverse Proxy с поддержкой WebSocket и SSL-сертификатом

Для безопасного доступа к панели управления через браузер и стабильного подключения удаленных агентов настроим веб-сервер Nginx в качестве обратного прокси с бесплатным SSL-сертификатом Let's Encrypt.

Создайте файл виртуального хоста /etc/nginx/sites-available/beszel.conf:

server {
    listen 80;
    listen [::]:80;
    server_name monitor.yourdomain.ru;

    # Запрет доступа к скрытым системным файлам
    location ~ /. {
        deny all;
    }

    # Проксирование запросов к Beszel Hub
    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_http_version 1.1;

        # Критически важные заголовки для работы постоянных WebSocket-соединений агентов
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Стандартные прокси-заголовки
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Увеличенные таймауты для предотвращения разрыва потоковых соединений
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
        proxy_connect_timeout 60s;
    }
}

Активируйте виртуальный хост символической ссылкой и протестируйте конфигурацию перед выпуском сертификата:

sudo ln -s /etc/nginx/sites-available/beszel.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Выпустите бесплатный криптографический SSL-сертификат с помощью утилиты Certbot, обязательно указав флаг --redirect для автоматического перенаправления с HTTP на защищенный HTTPS:

sudo certbot --nginx -d monitor.yourdomain.ru --redirect --non-interactive --agree-tos -m admin@yourdomain.ru

Для быстрой проверки правильности выпуска сертификата, длины цепочки и даты автопродления воспользуйтесь онлайн-инструментом SysKit:

Откройте адрес https://monitor.yourdomain.ru в браузере. При первом входе система предложит создать учетную запись администратора (Email и пароль). Процесс занимает 10 секунд и не требует подтверждения почты.

5. Подключение агентов к Hub: мониторинг хоста и контейнеров Docker

После входа в веб-панель нажмите кнопку «Add System» (Добавить систему). Откроется окно настройки нового сервера:

1. Name: понятное имя сервера (например, Production-VDS-SPB или Database-Node-01).
2. Host / IP: имя хоста или публичный IP-адрес сервера (для отображения в панели).
3. В окне сразу сгенерируются параметры авторизации: уникальный публичный ключ KEY и токен TOKEN.

Теперь перейдите на сервер, за которым вы хотите установить наблюдение, и создайте манифест docker-compose.yml для агента в директории /opt/beszel-agent:

sudo mkdir -p /opt/beszel-agent/beszel_agent_data
cd /opt/beszel-agent

Создайте конфигурацию агента:

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    # Режим host необходим для точного сбора метрик сетевых интерфейсов и фаервола
    network_mode: host
    volumes:
      - ./beszel_agent_data:/var/lib/beszel-agent
      # Доступ к сокету Docker в режиме read-only для сбора метрик контейнеров
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      PORT: 45876
      # Публичный ключ, скопированный из окна "Add System" в Hub
      KEY: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI..."
      # URL вашего центрального хаба
      HUB_URL: "https://monitor.yourdomain.ru"
      # Токен авторизации агента
      TOKEN: "your_agent_token_here"
    # Лимиты ресурсов: агенту достаточно 64 МБ RAM и 10% одного ядра CPU
    mem_limit: 64m
    cpus: 0.10

Запустите агент на отслеживаемом сервере:

sudo docker compose up -d

В течение 5–10 секунд в веб-панели Beszel статус сервера сменится на зеленый маркер «Active». Нажмите на имя системы — перед вами откроется интерактивный дашборд с детализацией по ядрам процессора, памяти, дискам и списком запущенных контейнеров Docker.

6. Настройка мгновенных алертов в Telegram при перегрузке CPU, памяти и сбое контейнеров

Главная практическая ценность системы мониторинга — вовремя разбудить инженера до того, как сбой заметили клиенты. В Beszel встроен универсальный движок уведомлений, поддерживающий Telegram, Discord, Pushover, Gotify, ntfy, Webhook и Email.

Для настройки оповещений в Telegram:

1. Откройте Telegram, найдите бота @BotFather и отправьте команду /newbot, чтобы создать бота и получить его API Token.
2. Узнайте свой персональный Chat ID через бота @userinfobot или добавьте созданного бота в рабочий чат дежурных инженеров.
3. В веб-интерфейсе Beszel перейдите в раздел Settings → Alerts.
4. В блоке Telegram активируйте переключатель и введите полученные параметры:
   • Bot Token: токен формата 123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ
   • Chat ID: числовой идентификатор чата (для групп указывается со знаком минус, например -1001234567890)
5. Нажмите кнопку «Send Test Alert» и убедитесь, что тестовое сообщение успешно доставлено в Telegram.

Настройте пороговые значения срабатывания тревог для каждого сервера индивидуально:

• CPU Usage: отправлять алерт при превышении 90% в течение 5 минут (исключает ложные срабатывания при кратковременных пиках компиляции или бэкапов).
• Memory Usage: порог 85% (оставляет запас для предотвращения срабатывания OOM-Killer).
• Disk Usage: тревога при заполнении любого раздела более чем на 85%.
• Status Down: отправка мгновенного P1-алерта, если связь с агентом прервалась более чем на 1 минуту.
• Docker Container Crashed: автоматическое уведомление, если любой отслеживаемый контейнер неожиданно завершился с кодом ошибки (non-zero exit code).

7. Выбор VDS для инфраструктуры мониторинга нескольких серверов

Хотя сам Beszel феноменально нетребователен к ресурсам (Hub потребляет менее 50 МБ RAM), для центрального сервера мониторинга критически важны параметры надежности сетевого подключения, низкого пинга до целевых узлов и стабильности KVM-виртуализации. Если сервер мониторинга упадет или окажется недоступен из-за сетевых сбоев, вы останетесь «слепыми» во время реального инцидента на продуктивных нодах.

Для размещения центрального хаба Beszel и мониторинга распределенной серверной инфраструктуры рекомендуем проверенных провайдеров с чистыми сетями и гарантированным SLA:

8. Инженерные рекомендации по безопасной эксплуатации Beszel в продакшене

Чтобы система мониторинга работала стабильно годами и не создавала угроз безопасности периметра, придерживайтесь следующих правил эксплуатации:

• Резервное копирование SQLite базы PocketBase: все исторические метрики и настройки пользователей хранятся в каталоге ./beszel_data. Настройте регулярный бэкап этой папки на удаленное S3-хранилище через утилиты Rclone или BorgBackup. Для корректного бэкапа SQLite перед копированием файла data.db выполняйте кратковременную команду создания снимка sqlite3 data.db ".backup backup.db".
• Ограничение доступа по IP (IP Whitelist): если мониторингом пользуются только сотрудники вашей компании с фиксированных IP-адресов, закройте публичный доступ к поддомену monitor.yourdomain.ru в Nginx директивами allow 203.0.113.10; deny all; либо поместите веб-панель за шлюз двухфакторной аутентификации Authelia.
• Автоматическое прореживание истории (Downsampling): Beszel автоматически агрегирует старые поминутные замеры в часовые и суточные интервалы, поэтому размер базы данных SQLite даже при непрерывном мониторинге 10 серверов в течение года не превышает 300–500 МБ.
• Безопасность группы Docker: не добавляйте непривилегированных пользователей ОС в системную группу docker на отслеживаемых хостах. Запуск контейнера агента под управлением systemd или супервизора исключает несанкционированный доступ к хостовой системе.