К основному содержимому

Netdata: мониторинг сервера в реальном времени

VDS / VPS · 15.02.2025 · 4 мин чтения
Иллюстрация к статье «Netdata: мониторинг сервера в реальном времени»

Установка Netdata

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
sh /tmp/netdata-kickstart.sh

# Netdata запустится на порту 19999
systemctl status netdata

Доступ к дашборду

Откройте в браузере: http://YOUR_SERVER_IP:19999

⚠️ Закройте порт 19999 от внешнего доступа через firewall, или настройте Nginx-прокси с Basic Auth.

Nginx прокси для Netdata с авторизацией

server {
    listen 80;
    server_name monitor.example.com;

    auth_basic "Monitoring";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:19999;
        proxy_set_header Host $host;
    }
}
htpasswd -c /etc/nginx/.htpasswd admin

Алерты в Telegram

# /etc/netdata/health_alarm_notify.conf
SEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN="YOUR_BOT_TOKEN"
DEFAULT_RECIPIENT_TELEGRAM="YOUR_CHAT_ID"

Что мониторит Netdata из коробки

КатегорияМетрики
CPUНагрузка, температура, частота
RAMИспользование, swap
ДискI/O, utilization, latency
СетьТрафик, пакеты, ошибки
Nginx/ApacheRPS, статус-коды, подключения
MySQL/PostgreSQLQueries/s, connections, slow queries
💡 Netdata собирает метрики каждую секунду — это в 60 раз детальнее чем Prometheus по умолчанию (каждые 60 сек).

Разбор типичных проблем

Дашборд не открывается, а systemctl status netdata показывает active (running) — почти всегда это firewall. Netdata слушает порт 19999, но UFW по умолчанию блокирует всё, что не разрешено явно.

curl: (7) Failed to connect to 203.0.113.10 port 19999: Connection refused

Проверьте ufw status — если порт не в списке, либо откройте его для вашего IP (ufw allow from ВАШ_IP to any port 19999), либо, что правильнее, закройте порт наружу совсем и оставьте доступ только через Nginx-прокси с Basic Auth, как описано выше.

Алерты в Telegram не приходят, хотя конфиг заполнен правильно. Частая причина — сервис не перезапущен после правки health_alarm_notify.conf: этот файл читается только при старте, hot reload для него не работает.

systemctl restart netdata
# Проверить, что Netdata видит токен и chat_id:
sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test

Netdata vs Prometheus + Grafana

КритерийNetdataPrometheus + Grafana
Время настройкиМинуты, из коробкиЧасы — нужен экспортёр, конфиг сбора, дашборды
Детализация метрикРаз в секундуОбычно раз в 15–60 секунд
Хранение историиЧасы-дни на диске без настройкиМесяцы-годы, если настроено хранилище
Мультисерверный обзорНужен Netdata Cloud (внешний сервис)Изначально многосерверный по архитектуре

Когда Netdata не подходит

  • Нужна история метрик за месяцы для планирования capacity — Netdata по умолчанию хранит данные в памяти и на диске лишь на несколько часов-дней, для долгого хранения нужен внешний backend вроде Prometheus.
  • Мониторится парк из десятков серверов централизованно — бесплатная версия Netdata показывает каждый сервер отдельно, для единого дашборда нужен Netdata Cloud или отдельный стек с Grafana.
  • Нужны сложные агрегации и алерты на основе произвольных PromQL-подобных запросов — встроенный язык алертов Netdata проще, чем PromQL, и не годится для сложной аналитики.
  • Компания требует хранить метрики на собственной инфраструктуре без внешних облачных сервисов для сводного обзора — бесплатный Netdata без Cloud показывает только один сервер за раз, и это ограничение архитектурное, а не настраиваемое.

Ограничения нагрузки на сам сервер

Сбор метрик каждую секунду не бесплатен: на слабых VPS с 1 ядром CPU и 512 МБ RAM сам процесс netdata может занимать заметную долю ресурсов, особенно если включены все плагины сборки данных сразу. На таких тарифах стоит отключить неиспользуемые плагины в /etc/netdata/netdata.conf и снизить частоту обновления графиков с 1 до 2–5 секунд — разница в отзывчивости минимальна, а нагрузка падает заметно.

Проверка результата

  1. Откройте http://ВАШ_IP:19999 (или адрес через Nginx-прокси) — должен загрузиться дашборд с живыми графиками CPU, RAM, диска и сети.
  2. Убедитесь, что прямой доступ к порту 19999 закрыт снаружи: curl -m 3 http://ВАШ_IP:19999 с другой машины должен зависнуть или вернуть отказ.
  3. Проверьте доставку алертов: временно поставьте искусственно низкий порог для тестового алерта и убедитесь, что сообщение пришло в Telegram.
  4. Проверьте автозапуск после перезагрузки сервера: systemctl is-enabled netdata должен вернуть enabled.

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

Статья помогла?
← Назад в базу знаний Задать вопрос поддержке