Встановлення 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/Apache	RPS, статус-коди, підключення
MySQL/PostgreSQL	Queries/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 проти Prometheus + Grafana

Критерій	Netdata	Prometheus + Grafana
Час налаштування	Хвилини, з коробки	Години — потрібен експортер, конфіг збору, дашборди
Деталізація метрик	Раз на секунду	Зазвичай раз на 15–60 секунд
Зберігання історії	Години-дні на диску без налаштування	Місяці-роки, якщо налаштовано сховище
Мультисерверний огляд	Потрібен Netdata Cloud (зовнішній сервіс)	Спочатку багатосерверний за архітектурою

Коли Netdata не підходить

Потрібна історія метрик за місяці для планування потужностей — 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 секунд — різниця у відгуку мінімальна, а навантаження падає помітно.

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

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

Якщо потрібен довгостроковий моніторинг з історією за місяці та дашбордами на кілька серверів — дивіться статтю про Grafana і Prometheus. Для перевірки доступності сайту ззовні, а не лише метрик сервера, знадобиться стаття про моніторинг аптайму сайту.