Домашний сервер работает круглосуточно, а вы видите его только тогда, когда что-то уже сломалось: диск почти полон, память исчерпана, резервная копия не делается третью неделю. Netdata закрывает этот пробел. Он собирает метрики с интервалом в одну секунду, хранит историю локально и умеет сам сигнализировать о проблемах. В этом материале разберём не столько сам факт установки, сколько две вещи, из-за которых мониторинг становится по-настоящему полезным: продуманные пороги алертов и ограниченное потребление памяти на слабом железе вроде старого мини-ПК.

Установка и первая проверка

На Debian и Ubuntu пакет лежит в официальных репозиториях, отдельный сторонний репозиторий не нужен:

sudo apt update
sudo apt install netdata
sudo systemctl enable --now netdata
curl -s http://127.0.0.1:19999/api/v1/info | head -5

Последняя команда должна вернуть JSON с версией демона — значит, служба запущена и отвечает. Веб-интерфейс открывается по адресу вида http://192.168.1.10:19999. По умолчанию Netdata слушает все сетевые интерфейсы, поэтому доступ к панели стоит сразу ограничить: либо правилом брандмауэра, либо привязкой к нужному адресу в секции [web] файла /etc/netdata/netdata.conf.

[web]
    bind to = 192.168.1.10
sudo ufw allow from 192.168.1.0/24 to any port 19999 proto tcp

Метрики, на которые стоит смотреть

Из коробки демон собирает сотни графиков, но для домашнего сервера нужны пять:

  • system.ram — как распределена память между кэшем и реально используемой;
  • cpu и load — просадки по ядрам и растущая очередь процессов;
  • disk_space — места на разделах, включая /boot, который на Debian и Ubuntu заполняется старыми ядрами;
  • eth0 — входящий и исходящий трафик, количество ошибок и потерянных пакетов;
  • temperatures — данные lm-sensors, если они настроены.

У каждого графика в панели есть кнопка получения имени метрики — оно понадобится ниже, в правилах алертов. Полезно заранее пройтись по разделам интерфейса и отметить для себя типичные значения нормы: именно они станут основой порогов. Слепо копировать пороги из чужих инструкций нельзя: на сервере с одним ядром и четырьмя гигабайтами памяти «критично» выглядит совсем иначе, чем на рабочей станции.

Алерты: как задать полезные пороги

Правила лежат в каталоге /etc/netdata/health.d/ — один файл описывает одно семейство проверок. Формат простой: ключ и значение через двоеточие. Пример правила, срабатывающего при исчерпании памяти:

alarm: ram_used_percent
   on: system.ram
   os: linux
   hosts: *
   every: 10s
   lookup: average -1m unaligned
   units: %
   warn: $this > 85
   crit: $this > 95
   delay: up 2m down 5m
   info: доля использованной оперативной памяти за минуту
   to: sysadmin

Разберём части правила. Блок lookup берёт среднее за минуту, чтобы одиночный всплеск не вызывал ложное срабатывание. Задержка up 2m означает: после старта демон ждёт две минуты, прежде чем слать тревогу, — иначе каждая перезагрузка породила бы письмо. Строка to: sysadmin указывает группу получателей, настроенную в файле уведомлений. После правки правило перечитывается без перезапуска демона:

sudo netdatacli reload-health
curl -s http://127.0.0.1:19999/api/v1/alerts | python3 -m json.tool

Вторая команда выводит текущее состояние всех алертов: сразу видно, активно правило, сработало оно или уже восстановилось. Запомните её — это первый инструмент диагностики, когда уведомления не приходят.

Куда отправлять уведомления

Отвечает файл /etc/netdata/health_alarm_notify.conf. Базовые параметры:

  • default_recipient — почтовый адрес получателя по умолчанию;
  • sysadmin — отдельный адрес для групп, указанных в правилах как to: sysadmin;
  • sendmail и sendmailipath — программа отправки почты; для начала подойдёт локальный msmtp или postfix.

Если поднимать почтовый сервер не хочется, есть второй путь: в том же файле можно объявить собственный обработчик и указать его имя в строке to. Обработчик получит на вход имя алерта, его состояние и метрику, а дальше всё делает обычный скрипт, отправляющий событие во внутренний чат или на устройство в локальной сети. Такой вариант проще диагностировать: скрипт пишет события в свой лог, и по нему видно, дошёл ли сигнал вообще.

Экономия памяти и диска

По умолчанию Netdata использует движок dbengine: метрики лежат в кэше страниц и на диске, что удобно, но на машине с двумя гигабайтами памяти может отнимать десятки мегабайт. Все настройки — в /etc/netdata/netdata.conf:

[global]
    update every = 2
    page cache size = 8
    dbengine disk space = 512
[plugins]
    python.d = no
[cloud]
    enabled = no

Параметр update every = 2 удваивает интервал опроса и почти вдвое снижает нагрузку. page cache size задаёт процент оперативной памяти, отдаваемый под кэш истории: на слабой машине разумно от пяти до десяти процентов. dbengine disk space ограничивает объём в мегабайтах — при превышении старые данные удаляются автоматически, диск не зачернётся. Отключение плагина python.d убирает сбор метрик из скриптов, которые вам не нужны, а облачные функции домашнему серверу не требуются.

Если история не нужна вовсе, например на одноплатнике с SD-картой, задайте memory mode = ram, тогда метрики хранятся только в памяти, либо memory mode = none, когда демон отдаёт только текущие значения. Проверить результат:

grep VmRSS /proc/$(pidof netdata)/status
systemctl status netdata --no-pager

Типичные проблемы и диагностика

  • Панель не открывается — смотрите вывод journalctl -u netdata -b | tail -50 и проверяйте, не занят ли порт, командой ss -ltnp | grep 19999.
  • Уведомления не приходят — сначала откройте вывод /api/v1/alerts: если статуса ALARM нет, правило вообще не сработало, и дело не в почте.
  • После обновления пакета файлы в /etc/netdata/health.d могут быть заменены новыми версиями из пакета — сверяйте через dpkg -L netdata | grep health.d и держите свои правила в отдельных файлах.
  • История растёт быстрее ожидаемого — уменьшите page cache size и dbengine disk space, одновременно увеличив интервал update every.

Итог

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

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте