Netdata на сервере: частые ошибки и решения

MAATRIX

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

Панель не открывается

Netdata установлен, но браузер не показывает панель на порту 19999. Сначала убедитесь, что демон вообще запущен и слушает порт:

systemctl status netdata
ss -tlnp | grep 19999

Если служба не запущена — смотрите лог: journalctl -u netdata -n 50. Частая причина падения на слабом VPS — нехватка памяти при старте. Если служба активна и слушает порт, но снаружи панель не открывается, причин две.

Первая — Netdata привязан к localhost (bind to = 127.0.0.1 в конфиге), и это правильно с точки зрения безопасности. Ходите на панель через SSH-туннель: ssh -L 19999:localhost:19999 root@IP. Вторая — порт закрыт firewall. Если вы сознательно открываете 19999 (не рекомендуется без пароля), разрешите его в ufw. Но лучший путь — оставить localhost и настроить reverse-proxy, а не открывать порт всем.

Высокое потребление памяти и CPU

Netdata обычно лёгкий, но на слабом VPS или при множестве собираемых метрик он может заметно есть память. Причина — объём метрик, которые он держит в оперативке для секундного разрешения. Чем больше сервисов и глубже история в памяти, тем выше расход.

Управляйте этим в /etc/netdata/netdata.conf. Уменьшите объём хранимой в памяти истории и, при необходимости, интервал сбора:

[db]
    mode = ram
    retention = 3600
[global]
    update every = 2

Параметр retention в режиме ram задаёт, сколько секунд истории держать (3600 = час). update every = 2 снижает частоту опроса с секунды до двух, что ощутимо разгружает слабый сервер. Также можно отключить ненужные плагины-сборщики в секции [plugins]: если вы не используете, например, мониторинг определённых подсистем, выключите их, и расход упадёт. После правки — systemctl restart netdata.

Открытый порт 19999 — дыра в безопасности

Самая опасная и частая ошибка — оставить панель Netdata открытой в интернет без пароля. Любой, кто знает ваш IP, увидит процессы, сервисы, версии ПО, нагрузку — готовую карту для атаки. Проверьте, доступен ли порт снаружи, с другой машины:

curl http://IP_СЕРВЕРА:19999

Если пришёл HTML панели — порт открыт, закрывайте немедленно. Стоит осознать масштаб утечки: открытая панель Netdata — это не просто графики, а подробная инвентаризация сервера, по которой злоумышленник узнаёт версии ПО с их известными уязвимостями, имена запущенных сервисов и моменты пиковой нагрузки, удобные для атаки. Правильный подход: привязать Netdata к localhost и поставить перед ним reverse-proxy с авторизацией. В netdata.conf:

[web]
    bind to = 127.0.0.1

Затем Nginx с базовой авторизацией проксирует на localhost:19999, а наружу открыты только 80/443. Так панель защищена паролем и HTTPS, а сам Netdata недоступен напрямую. Это не опция, а обязательный шаг для любого сервера в интернете.

Алерты не приходят

Netdata из коробки имеет сотни готовых проверок, но по умолчанию ему некуда слать уведомления. Если алерты «молчат», почти всегда не настроен канал доставки. Откройте /etc/netdata/health_alarm_notify.conf и убедитесь, что нужный способ включён и заполнен.

Для Telegram проверьте три вещи: SEND_TELEGRAM="YES", верный TELEGRAM_BOT_TOKEN и правильный DEFAULT_RECIPIENT_TELEGRAM (chat_id). Частая ошибка — перепутать chat_id или не написать боту первым (тогда бот не может инициировать диалог). Протестируйте отправку встроенным скриптом:

/usr/libexec/netdata/plugins.d/alarm-notify.sh test

Он прогонит все настроенные каналы и покажет, какой сработал. Если тест проходит, а реальные алерты не идут — возможно, отключён health-мониторинг или пороги не срабатывают. Проверьте, что в конфиге не стоит enabled = no в секции [health].

Разделяйте два класса проблем с алертами: «канал не работает» и «правило не срабатывает». Первый диагностируется тестовым скриптом — если он не смог отправить сообщение, дело в токене, chat_id или блокировке исходящего трафика к Telegram. Второй означает, что уведомление некуда слать нечему: порог не достигнут или проверка отключена. Не путайте их — иначе будете чинить токен, когда на самом деле условие алерта просто не выполнилось. Полезно один раз сознательно спровоцировать нагрузку и убедиться, что цепочка «проблема → срабатывание → сообщение» проходит целиком, а не проверять её впервые в момент реальной аварии.

Проблемы после обновления и с плагинами

После обновления Netdata иногда пропадают метрики отдельных сервисов или плагин показывает ошибку. Причина — сменился формат конфига плагина или у Netdata не хватает прав на чтение данных сервиса (например, сокета MySQL или статуса Nginx).

Смотрите лог ошибок Netdata:

tail -n 50 /var/log/netdata/error.log

Типичный случай — мониторинг Nginx требует включённого модуля stub_status, а MySQL — отдельного пользователя с правами на чтение статистики. Если после обновления сломался конкретный сборщик, проверьте его конфиг в /etc/netdata/go.d/ и права доступа. Обновляйте Netdata тем же скриптом kickstart, что и ставили, — он корректно переносит настройки. Не редактируйте файлы в /usr/lib/netdata/ напрямую: правки делаются только в /etc/netdata/, иначе обновление их затрёт.

Стабильность и оплата сервера

Мониторинг должен работать без перебоев — иначе вы узнаете о проблеме не от Netdata, а от упавшего сайта. Кроме технических настроек, за стабильность отвечает и сам сервер: он не должен отключаться из-за проблем с оплатой.

MAATRIX принимает карты российских банков, СБП, криптовалюту и токен MAAT, поэтому VPS под мониторинг не отвалится из-за платёжки, а нужная локация поднимается за пару минут. Netdata на таком сервере будет исправно следить за инфраструктурой и вовремя присылать алерты, а вы — заниматься делом, а не воевать с провайдером.

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