Self-hosted мониторинг - от Netdata через Grafana к Beszel

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

Поэтому рано или поздно встаёт вопрос: как же за всем этим зоопарком серверов и приложений приглядывать? Изначально мне было в кайф на каждый сервер заходить ручками, ставить обновления вручную, смотреть за жизненными параметрами сервера через популярные утилиты (top, htop, btop), проверять логи приложений и прочее, прочее.

TL;DR: После Netdata, потом Grafana + Prometheus, я остановился на Beszel и жалею, что не нашёл его раньше. Ниже подробно написано почему, для кого это, и чего у Beszel нет. Это не обзор Beszel, а про то, какие решения я пробовал и что выбрал для мониторинга своей небольшой инфраструктуры.

Но довольно быстро я наигрался в “крутого хакера” из фильмов, и всё это превратилось в нудную повинность, которую не всегда и хотелось выполнять. Тем не менее, поскольку многие сервера смотрят в открытый интернет, приглядывать за ними, регулярно обновлять приложения, проверять логи и прочее обязательно надо. Поэтому всем селф-хостерам на определенном этапе приходится решать задачу эффективного мониторинга своего продакшена серверов и приложений на них.

За последние пару лет я прошёл через три разных стека мониторинга: сначала Netdata, потом Grafana + Prometheus, и в итоге Beszel. Каждый из них чему-то меня научил, и в результате я оказался совсем не там, откуда начинал. Если бы я прочитал такой пост в самом начале, он бы мне очень помог.

👉 Если у тебя горстка VPS, пара мини-ПК, NAS и, может быть, несколько Docker-хостов, это для тебя.

👉 Если у тебя команда из 500 инженеров, это не для тебя, возвращайся к своим дашбордам в Datadog.

Что мне реально было нужно от мониторинга

Прежде чем разбирать инструменты, опишу задачу, потому что правильный ответ полностью зависит от того, что ты пытаешься сделать.

Сейчас у меня семь серверов в Hetzner (микс из CX22 и CPX21), все на Ubuntu, все развёрнуты через Terraform, управляются через Ansible, и большинство гоняют Docker-контейнеры. Мне было нужно:

1. CPU, память, диск и сеть по каждому хосту, с историей за несколько недель.
2. Использование ресурсов по каждому контейнеру (всё самое интересное живёт в Docker).
3. Алерты, когда что-то горит или вот-вот загорится. Самая важная часть всего мониторинга.
4. Чистый обзорный дашборд, на который можно глянуть за пять секунд, когда это понадобится.
5. Минимальная нагрузка от агента сбора показателей, чтобы не отнимать ресурсы сервера.
6. Что-то, что в перспективе можно показать клиентам. Я строю RunMyApp, управляемый self-hosted сервис для малого бизнеса в ЕС, и фраза “мы проактивно мониторим твой сервер” это часть моего value proposition.

Чего в этом списке пока нет: агрегации логов, distributed tracing, APM и observability уровня SRE (Site Reliability Engineering). Логи это пока единственное, что мне ещё надо решить. Так что если у тебя есть интересный вариант, дай мне знать.

Раунд 1: Netdata, отличная штука для начинающих

Netdata был моим первым серьёзным инструментом мониторинга, и, честно говоря, он реально очень крут. Агент ставится одной командой. Дашборд в Cloud плотный, красивый и функциональный, показывает всё: CPU, память, дисковый I/O, сеть, каждый запущенный процесс, каждый Docker-контейнер, даже температуры по устройствам.

Для первых трёх-четырёх серверов Netdata был идеален. Установка в одну строчку. Дашборды просто работают. Список интеграций огромный. PostgreSQL, Nginx, Redis, Traefik, что ни назови, под всё есть свой коллектор. Алерты через Discord webhook настраиваются за десять минут. Но в итоге я от него отказался по двум причинам.

Первое - это потребление ресурсов агентом. Агент Netdata собирает огромное количество данных с высокой детализацией, что прекрасно, когда тебе это нужно, и заметно, когда не очень. На моих скромных VPS агент мог запросто сжирать несколько процентов CPU и от 200 до 500 МБ оперативки в зависимости от того, что на хосте крутится и что ты хочешь мониторить. На машине с 4 ГБ оперативки, где работает пара сервисов, это ощутимый налог.

Второе - это цена. Netdata Cloud бесплатен до 5 нод, дальше тариф Business стоит $4.50 за ноду в месяц при годовой оплате, что выходит $54 за ноду в год. Для парка из семи нод это примерно $378 в год. Для бюджета homelab это много.

Правда сейчас у них появился тариф Homelab за $90 в год на неограниченное количество нод по политике fair-use. Когда я делал переход, его ещё не было, и это реально честное предложение, если ты используешь всё строго для себя. Но две вещи меня всё равно останавливают. Во-первых, тариф Homelab по политике явно запрещён для коммерческого использования: “мониторинг инфраструктуры компании”, “оказание услуг мониторинга клиентам”, “использование в бизнес-контексте”. RunMyApp под это попадает буквально, так что для меня остается только вариант Business. Во-вторых, дашборд живёт у них в облаке, а не на моей инфраструктуре, а я предпочитаю владеть стеком целиком.

Мне до сих пор очень нравится эта платформа, и я считаю, что Netdata это отличный продукт. Если у тебя меньше пяти нод или ты попадаешь под условия тарифа Homelab и тебе ок с тем, что дашборд хостится в облаке, просто ставь Netdata. Это реально закроет все твои потребности, поскольку тут есть всё. Ну а если хочется полного self-hosting и (почти) нулевой платы за ноды, читай дальше.

Раунд 2: Grafana + Prometheus, признанная классика

“Настоящий” ответ в self-hosting комьюнити это всегда Grafana + Prometheus. Это опенсорсный observability стек, промышленный стандарт, бесконечно гибкий, и каждый работодатель в мире хочет видеть его в твоём резюме. Как же не пытаться разобраться с этим космолётом?

Начальная установка, если честно, была не такой уж и страшной. Prometheus в Docker, node_exporter на каждом хосте, cAdvisor для метрик контейнеров, Grafana как фронтенд, и всё это склеено парой docker-compose файлов. С LLM под рукой я собрал рабочий стек за один вечер.

А потом я попытался этим реально пользоваться.

Вот тут и началось веселье. Дефолтные дашборды Grafana, которые ты импортируешь из community-галереи, выглядят впечатляюще на скриншотах, но в них тут же запутаешься, когда начинаешь ими пользоваться на практике. Особенно когда у тебя вообще нет опыта в этом деле (как у меня).

Половина панелей показывала “No data”, потому что названия метрик в дашборде не совпадали с тем, что выдавала моя версия node_exporter (классический пример: node_cpu из старых дашбордов против node_cpu_seconds_total из текущих версий). Вторая половина показывала данные, но в таком расположении или оформлении, которое мне совсем не подходило.

Тогда я начал собирать собственный дашборд. Боже, это же отдельный вид искусства, на которое надо потратить целую жизнь. Чтобы сделать в Grafana панель, которая показывает что-то полезное, нужно писать PromQL. PromQL это красивый и мощный язык запросов, и его не выучить за вечер. Я провёл часы, разбираясь, как выразить “среднее использование CPU по хосту за последние 5 минут, исключая idle и iowait” так, чтобы не получать в ответ либо ноль, либо бесконечность. В итоге у меня получилось что-то отдалённо напоминающее статус-страницу Proxmox, и дня три я был этим горд.

А потом я добавил новый сервер.

Добавление сервера означало re-labelling, перепроверку scrape configs, правку переменных дашборда и переделку template queries, чтобы новый хост появился в выпадающих списках. Удаление сервера было ещё хуже, потому что исторические данные оставались, и дашборды показывали разрывы и призраков. Каждое изменение инфраструктуры превращалось в работу над дашбордами. Возможно, я просто не умею делать это правильно. Но это точно не быстрое решение.

По ресурсам: один только Prometheus в простое жрал около 300 МБ оперативки на центральном хосте мониторинга, а связка node_exporter + cAdvisor добавляла ещё 50-100 МБ на каждый мониторящийся хост. С историей за пару недель и семью нодами центральный Prometheus уехал ближе к 600-800 МБ. Не катастрофа, но и не сказать, что лёгкое. Возможно, опять же, специалисты умеют делать так, чтобы они использовали меньше системных ресурсов. Но я не спец. И честно говоря, мне даже не очень хотелось мучать цифрового друга (AI) на этот счёт.

Я сдался примерно через три недели. Не потому что стек не работал, а потому что для меня стоимость поддержки была дико непропорциональна той ценности, которую я с него получал. Я тратил больше времени на тюнинг Grafana, чем на собственно наблюдение за инфраструктурой.

Вердикт: Grafana + Prometheus это правильный ответ, если (а) у тебя стабильный парк, который редко меняется, (б) тебе реально нужны кастомные дашборды и запросы, (в) ты хочешь выучить стек по профессиональным причинам, или (г) тебе также нужна агрегация логов (Loki) и хочется всё держать в одном месте. Для маленького и постоянно меняющегося homelab, где ты просто хочешь знать “жив ли сервер”, это адская переусложнённость.

Раунд 3: Beszel, тот самый, где ж ты раньше был

Я нашёл упоминание Beszel в каком-то треде на форуме self-hosting сообщества, и поначалу даже название мне не внушало доверия. Но потом я поставил его утром в одно прекрасное воскресенье, и уже до обеда мигрировал все семь серверов на эту платформу, и с тех пор живу на нём. На написание этого абзаца я потратил больше времени, чем на установку Beszel.

Beszel это лёгкий self-hosted инструмент мониторинга серверов, построенный на PocketBase. Опенсорс под лицензией MIT, один Go-бинарник плюс крошечный агент, и он делает ровно то, что в реальности нужно 80% пользователей для мониторинга: метрики по хостам, статистика Docker-контейнеров, исторические графики и настраиваемые алерты. Никакого PromQL, никаких YAML scrape configs, никакого ковыряния в JSON дашбордов. Дашборд уже готов и просто работает. Есть светлая и тёмная темы. И я уже говорил про алерты, да?

Цифры говорят сами за себя. Сам Hub использует примерно 30 МБ оперативки. Агент около 10 МБ на хост. Сравни это с 300 МБ у Prometheus или несколькими сотнями МБ на агента у Netdata. На маленьком VPS это разница между “мониторинг невидим” и “мониторинг это ещё один жилец”.

Архитектурно стоит понимать одну важную вещь: Hub сам подключается к агентам (это pull-модель через SSH), а не наоборот. Это значит, что на хосте с агентом порт 45876 должен быть доступен для Hub, и фаервол надо настраивать соответственно. Зато публичный ключ Hub лежит на агентах, и никаких токенов или паролей передавать в открытом виде не нужно.

Что я с этого получаю:

• Отличный дашборд, показывающий все серверы разом, с инфой по CPU, памяти, диску и сети.
• Кликаешь на любой сервер и видишь детальные временные графики по ресурсам плюс список Docker-контейнеров с их потреблением ресурсов.
• Настраиваемые глобальные или для каждого сервера алерты по CPU, памяти, диску, трафику, температуре и статусу хоста, отправляющиеся туда, куда поддерживает Shoutrrr: Discord, Telegram, email, ntfy, Slack, обычный набор.
• Поддержка нескольких пользователей, чтобы можно было давать клиентам read-only доступ.

Что мне нравится больше всего: когда я добавляю новый сервер, я запускаю на нём всего одну команду, вставляю ключ в UI Hub’а, и новый хост появляется в дашборде. Никакого пере-темплейтинга, никакого re-labeling, никакого PromQL. Когда я удаляю сервер, я удаляю его из Hub’а, и его нет. Дашборд адаптируется, потому что дашборд один и тот же для всех.

Чего у Beszel нет

Хочу быть честным насчёт этого, потому что это главная причина, по которой Beszel подойдёт не всем.

Beszel не работает с логами. Он мониторит ресурсы. Если тебе нужна централизованная агрегация, поиск и анализ логов (Loki, ELK-стек, SigNoz, OpenObserve), Beszel не твой инструмент. Либо ставишь что-то рядом, либо забиваешь на простоту и возвращаешься к стеку Grafana с прикрученным Loki.

В моём случае это нормально. Мне пока редко нужно запрашивать логи между хостами. Когда нужно, захожу по SSH и делаю всё ручками (точнее, бережно собранными за долгое время скриптами). Но если ты гоняешь продакшен-приложение и тебе нужно коррелировать ошибки между сервисами, одного Beszel точно не хватит.

Что Beszel ещё не делает: APM, distributed tracing, кастомные метрики из твоих приложений, synthetic checks внешних эндпойнтов, SLO tracking. Это без прикрас простой монитор ресурсов хоста и контейнеров. Именно этот фокус и делает его таким хорошим в том, что он делает.

Быстрое сравнение

Если коротко, вот как все три стека выглядят рядом для моего сценария (7 нод в Hetzner):

Цифры по RAM приблизительные, зависят от твоей конфигурации и retention. Но порядок величин показывает суть.

Практический разбор установки Beszel

Раз уж мы добрались до этого момента, то вот как бы я ставил Beszel сегодня. Предполагаем, что у тебя есть Docker и docker-compose на машине, где будет крутиться Hub, и SSH-доступ к машинам, которые ты хочешь мониторить.

Шаг 1: Запускаем Hub

На машине, которая станет твоим Hub’ом мониторинга, создай директорию для Beszel и в файле docker-compose.yml пропиши:

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

Запускаем:

docker compose up -d

Открываем http://your-host:8090 в браузере. Тебя попросят создать первого админа.

Если хочется HTTPS (а его стоит хотеть, особенно если ты выставляешь это в интернет), поставь перед ним Caddy или Traefik. Caddy проще всего. Двух строчек в Caddyfile хватит:

beszel.yourdomain.com {
    reverse_proxy beszel:8090
}

Чтобы Caddy в контейнере мог достучаться до Beszel по имени beszel, они должны быть в одной Docker-сети. Либо запусти их одним docker-compose файлом, либо добавь обоим внешнюю сеть и подключи. Если Caddy у тебя на хосте, а не в контейнере, замени beszel:8090 на localhost:8090. Caddy сам подтянет сертификат от Let’s Encrypt. Hub готов.

Шаг 2: Добавляем систему

В UI Hub’а жмём “Add System”. Даём имя (я использую мнемонические имена хостов, но это может быть любой текст, понятный тебе) и IP или hostname, по которому Hub сможет достучаться до агента. Beszel показывает диалог с двумя вкладками: Docker и Binary. На обеих уже заполнены публичный ключ Hub и токен для этой системы, тебе остаётся только скопировать готовую команду.

Шаг 3: Запускаем агента

И вот тут самое приятное: Beszel сделал установку агента настолько простой, что её хочется снять на видео. Я все равно планирую это сделать, так что можешь подписаться на мой YouTube канал, чтобы не пропустить этот момент.

Вариант 1 (рекомендую): один bash-скрипт. На вкладке Binary жмёшь “Copy Linux command” (или Homebrew/Windows/FreeBSD, что нужно) и вставляешь на хосте, который хочешь мониторить:

curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && \
chmod +x /tmp/install-agent.sh && \
/tmp/install-agent.sh \
  -p 45876 \
  -k "ssh-ed25519 AAAAC3Nz... (публичный ключ твоего Hub'а)" \
  -t "your-system-token" \
  -url "https://your-hub.example.com"

Скрипт ставит бинарник, создаёт systemd-сервис, прописывает токен и публичный ключ, поднимает агента. Через несколько секунд система появляется в Hub’е как “up” с живыми метриками. Никаких docker-compose файлов, никаких ручных env-переменных.

Вариант 2: Docker. Если ты живёшь в контейнерах и не хочешь systemd-сервис на хосте, на вкладке Docker есть готовые “Copy docker compose” и “Copy docker run”. Содержимое примерно такое:

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LISTEN: 45876
      KEY: "ssh-ed25519 AAAA..."
      TOKEN: "your-system-token"
      HUB_URL: "https://your-hub.example.com"

Поднимаем привычным docker compose up -d.

Массовый раскат через Ansible. Beszel поддерживает universal token: один токен, по которому можно регистрировать сразу много агентов, и Hub автоматически создаёт для них записи систем. Это убирает ручной шаг “Add System” в UI для каждого хоста и идеально подходит под Ansible. Я держу токен в Ansible Vault, в playbook просто прогоняю shell-таску с curl-командой по группе серверов, и весь парк регистрируется сам.

Шаг 4: Настраиваем алерты

В Hub’е заходим в настройки каждой системы и определяем пороги. CPU выше 80% в течение 5 минут, диск выше 90%, нагрузка на память, хост упал, что угодно важное для тебя. Добавляешь каналы уведомлений в настройках пользователя, указываешь Discord webhook или Telegram-бота, и алерты пошли.

Шаг 5: Бэкапим

Beszel хранит всё в ./beszel_data (том, который ты примонтировал). Под капотом там SQLite от PocketBase, поэтому есть нюанс: tar по живой базе под нагрузкой может дать битый снэпшот. Два варианта:

• Простой: останавливаешь контейнер на минуту, tar-им, поднимаешь обратно. Для homelab нормально.
• Правильный: используешь sqlite3 .backup для атомарного снэпшота без остановки сервиса.

Дальше всё стандартно: ночной cron заливает архив в S3, B2 или куда ты там складываешь бэкапы. У меня это сделано вместе с остальными данными PocketBase.

Это вся установка. Серьёзно. От нуля до мониторинга парка из семи серверов меньше чем за час, если не торопиться.

Другие варианты, о которых стоит знать

Я лично не проверял многие из них, но они всплывают в каждом обсуждении мониторинга, и я решил собрать этот список тут для твоего удобства.

Uptime Kuma это красивый и простой инструмент в стиле status-page для HTTP/TCP/ping проверок аптайма. Он дополняет Beszel, а не конкурирует с ним. Beszel говорит, что твой сервер жив и здоров; Uptime Kuma говорит, что твои сервисы отвечают на публичные запросы. Поставь оба, если хочешь.

SigNoz это современная observability-платформа на базе OpenTelemetry с поддержкой OTLP. Метрики, логи и трейсы в одном self-hosted стеке, с более современным ощущением, чем Grafana + Loki + Tempo. Если нужны логи и трейсы и хочется один инструмент, я бы в первую очередь смотрел на него.

Zabbix это enterprise-уровень опенсорса, существующий уже целую вечность. Очень мощный и очень тяжёлый, с UI, который ощущается так, будто его проектировали в 2010 году. Знать стоит, для homelab скорее всего перебор.

Checkmk Raw это бесплатная версия коммерческого продукта с генами Nagios. Крепкий вариант для sysadmin-стиля мониторинга смешанных окружений, но UX устаревший.

Glances отличный инструмент для одного хоста, CLI и веб. Умеет экспортировать в InfluxDB и Prometheus, так что строго одним хостом не ограничен, но всё равно проигрывает Beszel по UX для парка серверов. Если нужно мониторить ровно одну машину и ты любишь терминалы, Glances прекрасен.

OpenObserve это новая лёгкая альтернатива Elasticsearch/Loki для логов и метрик. Я его всерьёз не щупал, но он у меня в списке “если когда-нибудь понадобятся логи”.

Cockpit это веб-инструмент админки серверов от Red Hat, с лёгким встроенным мониторингом. Хорош для админки по одному хосту, не сказать что дашборд для нескольких серверов.

Смысл этого списка не в исчерпывающем перечислении, а в том, чтобы дать тебе стартовую информацию по запасным вариантам. Если Beszel не зайдёт, что-то из этого скорее всего зайдёт. Подробные обзоры по каждому из них ты легко найдёшь на просторах интернета.

Как выбирать своё решение

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

1. Сколько хостов?
   • Меньше 5: Netdata free или Beszel.
   • От 5 до 50: Beszel или Netdata Homelab, если проекты некоммерческие.
   • 50+: ты уже скорее всего на территории Prometheus или SigNoz.
2. Нужны ли логи? Если да, смотри Grafana + Loki, SigNoz или OpenObserve. Beszel не поможет. Если нет, Beszel сложно переплюнуть.
3. Сколько времени у тебя на установку и поддержку? Beszel: минуты. Netdata: минуты. Стек Grafana: выходные, во множественном числе.
4. Это для себя или для клиентов? Self-hosted даёт историю про доверие. Cloud-hosted даёт меньше того, что нужно поддерживать.

Для моих потребностей сегодня Beszel правильный ответ. Для твоих может и нет, и это нормально. Реальный смысл вот в чём: не выбирай по умолчанию самый тяжёлый инструмент только потому, что его обсуждают больше всех. Подбирай инструмент под свою задачу.

FAQ

Подходит ли Beszel для продакшена? Для мониторинга ресурсов хостов и контейнеров, да. Для полноценного observability с логами, трейсами и APM, нет. Нужно понимать, что выбираешь.

Поддерживает ли Beszel Windows? Агент собирается под Linux, macOS и FreeBSD. Windows нативно нет, нужен WSL2 или контейнер. Для типичного homelab на Linux-серверах это не проблема.

Можно ли мониторить Kubernetes? Beszel мониторит хосты и Docker-контейнеры, не Pods как сущности Kubernetes. Если у тебя k8s, тебе нужен kube-state-metrics плюс Prometheus или что-то аналогичное. Beszel не для этого.

Чем Beszel отличается от Uptime Kuma? Beszel мониторит здоровье сервера изнутри (CPU, RAM, диск, контейнеры). Uptime Kuma мониторит сервисы снаружи (отвечает ли HTTP-эндпойнт, открыт ли порт). Они решают разные задачи и хорошо живут вместе.

Что с обновлениями? Не сломается ли что-нибудь? Beszel молодой проект и активно развивается. Релизы выходят регулярно. Я обновляюсь раз в пару недель через docker compose pull && docker compose up -d, ничего пока не ломалось. Но это не повод не бэкапить базу перед обновлением.

Финальные мысли

Я прошёл через Netdata, повоевал с Grafana + Prometheus и остановился на Beszel. Урок не в том, что какой-то из этих инструментов плохой. Урок в том, что “мониторинг” это широкий спектр ежедневных задач, а любой популярный ответ скорее всего рассчитан на проблемы, которых у большинства из нас на самом деле нет.

Если у тебя маленький парк серверов и ты хочешь знать, что на них происходит, без того чтобы тратить выходные на PromQL или платить за каждую ноду каждый месяц, ставь Beszel сегодня после обеда. В худшем случае потеряешь двадцать минут. В лучшем у тебя будет мониторинг, которым ты реально будешь пользоваться годами.

И если ты в итоге будешь им пользоваться, проект Beszel это опенсорсная работа одного человека, выросшая во что-то блестящее. Поставь звезду репозиторию, заводи хорошие баг-репорты, и если есть возможность, поддержи мейнтейнера. Экосистема self-hosted держится на таких людях.

А если самому возиться с разворачиванием, обновлениями и мониторингом не хочется вообще, я как раз для этого случая строю RunMyApp: твои приложения на твоём сервере, а мы приглядываем, чтобы оно хорошо работало. Если интересно, напиши.

Надеюсь, что информация в этом посте тебе помогла сориентироваться. Если хочешь узнавать о новых постах, подпишись на уведомления. Я не рассылаю спам, потому что сам его не люблю.

Удачи.