Netdata: мониторинг сервера в реальном времени без сложной настройки

Когда клиент звонит и говорит «1С тормозит, сервер еле дышит», у меня нет времени разворачивать Zabbix-сервер с базой и настраивать шаблоны узлов. Мне нужна картина загрузки CPU, RAM, диска и сети прямо сейчас, за минуты, а не часы. Для этого сценария я держу в арсенале Netdata — и в этой статье объясняю, почему именно так, с какими параметрами конфигурации мы его разворачиваем и где он проигрывает Zabbix и Prometheus на длинной дистанции.

Зачем ещё один инструмент, если есть Zabbix и Prometheus

У нас в компании Zabbix — основной инструмент мониторинга инфраструктуры клиентов на долгосрочной основе: он хранит историю за месяцы, строит SLA-отчёты, шлёт эскалации дежурным. Но у Zabbix есть входной порог: сервер с MySQL или PostgreSQL, zabbix-server, zabbix-agent на узлах, настройка шаблонов узлов сети (host templates), триггеров и элементов данных (items). Разворачивать это ради разовой диагностики «почему тормозит терминалка» — избыточно и долго.

Prometheus решает другую задачу: он pull-based, сам ходит по экспортёрам (node_exporter, mysqld_exporter, windows_exporter) с заданным scrape_interval (обычно 15–60 секунд), хранит метрики во внутренней TSDB и требует Grafana для визуализации и Alertmanager для маршрутизации алертов. Это отличная связка для инженерной команды, которая уже эксплуатирует Kubernetes-кластер или десятки микросервисов. Но для разовой задачи «посмотреть, что происходит на одном сервере прямо сейчас» — это тоже три системы вместо одной.

Netdata закрывает третий сценарий: agent-only мониторинг, который разворачивается одной командой, сам находит источники метрик на хосте, хранит историю локально в собственном движке (dbengine) без внешней СУБД и отдаёт веб-дашборд на порту 19999 сразу после установки. Для меня это инструмент первого контакта с проблемным сервером — я подключаюсь, ставлю Netdata, за 3–5 минут вижу, где именно затык: CPU steal, iowait, своп, конкретный процесс rphost.exe, который съедает память. Дальше решаю, оставлять ли Netdata постоянно или снимать после диагностики.

Здесь важно подчеркнуть: речь не про «Netdata лучше вообще» — это разные инструменты под разные горизонты задачи. Zabbix и Prometheus проектировались как системы мониторинга парка серверов на годы вперёд, с накоплением истории, отчётностью для заказчика и процессом эскалации инцидента дежурному инженеру. Netdata проектировался как наблюдаемость одного хоста в реальном времени с нулевым порогом входа. Мы в ITfresh используем оба подхода параллельно, и ниже объясняю, по какому критерию выбираем.

Архитектура: почему это агент, а не система мониторинга

Ключевое отличие Netdata от Zabbix и Prometheus в философии: это не связка «сервер сбора + агенты + СУБД + фронтенд», а один бинарник netdata, который выполняет все четыре роли на самом хосте. Внутри агента работает несколько подсистем:

• Core collectors — встроенные сборщики на C, читающие /proc, /sys, cgroups с интервалом по умолчанию 1 секунда (параметр update every в секции [global] файла netdata.conf).
• go.d.plugin — набор коллекторов на Go для прикладных сервисов: PostgreSQL, MySQL, nginx, Redis, Docker и ещё порядка сотни модулей, каждый со своим YAML-конфигом в /etc/netdata/go.d/.
• apps.plugin — группировка метрик CPU/RAM/IO не по процессам поштучно, а по группам процессов согласно /etc/netdata/apps_groups.conf, что критично для серверов 1С и терминальных серверов, где процессов сотни.
• dbengine — локальное многоуровневое хранилище метрик на диске, о нём подробнее ниже.
• health engine — модуль тревог, читающий шаблоны из /etc/netdata/health.d/*.conf и вычисляющий пороги без внешнего сервера.

Всё это работает без обязательной регистрации где-либо. Подключение к Netdata Cloud (app.netdata.cloud) — опция для объединения дашбордов нескольких хостов в одном UI и получения облачных уведомлений, но локальный дашборд на 19999 порту работает и без неё, полностью автономно.

Установка и первый график: 5 минут от curl до данных

Стандартный путь установки — kickstart-скрипт, который сам определяет дистрибутив и ставит нативный пакет из репозитория Netdata (для Ubuntu/Debian/CentOS) либо статическую сборку, если пакета для дистрибутива нет:

На Windows-сервере (актуально для терминалок на RDS) ставится отдельный MSI-инсталлятор агента Netdata, который поднимает сбор метрик через Windows perflib — CPU, память, диски, сетевые интерфейсы и, что важно для терминального сервера, счётчики процессов через модуль process. После установки на Linux-хосте служба поднимается через systemd (systemctl status netdata), и дашборд сразу доступен по адресу http://IP-сервера:19999 — авторизация по умолчанию не требуется, потому что подразумевается доступ только из доверенной сети или через SSH-туннель.

Если нужно объединить несколько хостов клиента в едином веб-интерфейсе без ручной настройки streaming, агент можно «привязать» (claim) к учётной записи Netdata Cloud прямо на этапе установки, добавив к kickstart-скрипту параметры --claim-token и --claim-rooms, либо отдельной командой netdata-claim.sh уже после установки. Мы делаем это выборочно — только когда у клиента 3 и более серверов, которые удобнее смотреть в одном браузерном окне, а не по отдельности через IP:19999 каждого хоста. Для диагностики одного сервера claim не нужен вообще: весь функционал, кроме кросс-хостового UI и части облачных уведомлений, доступен локально.

Первое, что я делаю на новом хосте — открываю раздел System Overview и смотрю четыре графика: system.cpu, system.ram, system.io и system.net. Уже здесь, без единой строчки конфигурации, видно 90% типовых проблем: постоянный iowait выше 15–20%, своп, который начал расти, или сетевой интерфейс, упёршийся в полосу. Для сервера 1С отдельно смотрю раздел Applications — там agent группирует процессы кластера 1С (ragent, rmngr, rphost) по правилу из apps_groups.conf, и я вижу суммарное потребление CPU/RAM именно кластером 1С, а не размазанное по десяткам rphost-процессов.

Хранилище dbengine: три уровня ретеншена без внешней БД

Это, на мой взгляд, самое сильное инженерное решение в Netdata. Вместо отправки метрик во внешнюю time-series БД (как это делает связка Prometheus + remote write в Thanos/Mimir) агент с версии 1.38 использует dbengine v2 — движок, который сам управляет многоуровневым (tiered) хранением прямо на диске сервера, в каталоге /var/cache/netdata/dbengine. Конфигурация — в секции [db] файла netdata.conf:

Смысл трёх уровней (tier) — снижение детализации по мере старения данных, аналогично downsampling в Prometheus, но встроенное «из коробки»:

*Горизонт хранения зависит от выделенного размера на диск (retention size) и реального объёма метрик хоста — это не фиксированная величина, а результат деления квоты на фактический поток данных, регулируется параметрами dbengine tier N retention size в конфиге.

Практический вывод для нас: на типовом сервере 1С с 40–60 активными счётчиками (CPU по ядрам, память, диски, сеть, процессы кластера) Netdata стабильно укладывается в потребление RAM в диапазоне низких сотен мегабайт при выключенном machine learning и в диапазоне 300–600 МБ при включённом — это цифры по нашей эксплуатационной практике, а не из официальной документации, и на конкретном хосте они зависят от числа собираемых метрик и глубины истории в tier 0.

Автообнаружение служб и встроенное машинное обучение

В Zabbix, чтобы увидеть метрики PostgreSQL, нужно поставить zabbix-agent, подключить шаблон PostgreSQL by Zabbix agent, прописать UserParameter или использовать плагин. В Prometheus — поднять postgres_exporter отдельным процессом, прописать job в prometheus.yml, дождаться scrape. В Netdata — если на хосте слушает порт PostgreSQL с локально доступными правами, модуль go.d/postgres обнаруживает его автоматически при старте агента и начинает собирать метрики без ручной настройки. То же самое для nginx (модуль ищет status-эндпоинт), MySQL/MariaDB, Redis, Docker, systemd-юнитов через cgroups.

Для нестандартных случаев автообнаружение донастраивается через файл-конфиг конкретного модуля, например /etc/netdata/go.d/postgres.conf, где задаётся строка подключения, если её нельзя вывести автоматически. Общий список включённых модулей — в /etc/netdata/go.d.conf, где каждый модуль можно точечно отключить строкой вида mysql: no, если он не нужен и создаёт лишнюю нагрузку.

Для группировки процессов 1С мы правим /etc/netdata/apps_groups.conf, добавляя явную группу, чтобы в разделе Applications кластер 1С считался одной строкой, а не десятком отдельных PID:

После правки конфига apps.plugin достаточно перезапустить агент (systemctl restart netdata) — правило подхватится, и в дашборде появится агрегированная линия по всему кластеру сервера 1С, что удобно сравнивать с общей загрузкой CPU хоста напрямую на одном графике.

Отдельно стоит сказать про модуль машинного обучения, встроенный прямо в агент, — это то, чего нет ни в Zabbix, ни в базовой связке Prometheus без дополнительных инструментов. Модуль включается секцией [ml] в netdata.conf и по умолчанию активен в актуальных сборках агента ветки 2.x:

Суть механизма: для каждой отдельной метрики (dimension) агент обучает лёгкую модель (по документации — на основе кластеризации, k-means по скользящим окнам значений) прямо на хосте, без выгрузки данных наружу. По результатам каждая точка получает так называемый anomaly-bit — отметку, укладывается измерение в обученный профиль нормы или выбивается из него. Совокупность этих отметок агрегируется в отдельную метрику anomaly_detection.anomaly_rate и визуализируется в разделе Anomaly Advisor дашборда.

Практическая польза для нас: вместо того чтобы вручную подбирать статический порог warn/crit на, например, время отклика диска СУБД сервера 1С (которое у разных клиентов и разных дисковых подсистем совершенно разное), можно один раз включить ML и смотреть на процент аномальности метрики — рост anomaly_rate выше фонового уровня сигнализирует об отклонении от привычного для этого конкретного сервера поведения, даже если абсолютное значение метрики ещё не пробило бы никакой фиксированный порог. Это особенно удобно на серверах 1С, где «нормальная» загрузка диска в момент обмена с сайтом или закрытия месяца объективно выше, чем в обычный рабочий день — статический порог там либо шумит, либо пропускает реальную деградацию в тихие часы. Оговорюсь: ML — не замена явным health.d-правилам с понятными бизнес-порогами (типа «RAM выше 90% — критично»), а дополнение для метрик, где заранее неизвестно, какое значение является нормой для конкретного сервера. Мы включаем его выборочно, на серверах, где уже есть история минимум за несколько дней, потому что модели дообучаются постепенно и в первые часы после установки агента могут давать неинформативный anomaly-профиль.

Кейс: сервер 1С и терминальный сервер за 5 минут

Опишу типовой сценарий выезда/удалённого подключения к клиенту с жалобой «1С стала тормозить у всех». Порядок действий, который у нас отработан:

1. Ставим Netdata kickstart-скриптом (1–2 минуты, включая скачивание пакета).
2. Открываем System Overview → system.cpu: смотрим, не упирается ли суммарная загрузка в 100% и какая доля приходится на iowait — если iowait стабильно выше 15–20%, проблема почти всегда в дисковой подсистеме, а не в самой 1С.
3. Раздел Disks: график disk.util (утилизация устройства в процентах) и disk.avgsz / время отклика операций — если утилизация системного или файлового диска СУБД держится у 100%, это и есть бутылочное горлышко.
4. Раздел Applications с настроенной группой 1c_cluster: сравниваем CPU/RAM кластера 1С с общесистемным потреблением — если кластер съедает 90% CPU хоста, ищем тяжёлые сеансы уже средствами самой 1С (консоль кластера), а не на уровне ОС.
5. Раздел Memory: смотрим system.ram и отдельно mem.swap — активный своп на сервере 1С почти всегда означает, что выделенной памяти под rphost-процессы не хватает и нужно пересматривать настройки рабочих процессов кластера или добавлять RAM.

На терминальном сервере (Windows RDS) логика похожая, но акцент смещается на число активных сессий и потребление на пользователя. Через MSI-агент Netdata на Windows собираются метрики CPU/RAM/диска через perflib, и в разделе Applications видно потребление по группам процессов на хосте — по нашей практике эксплуатации терминальных серверов клиентов, типичная причина деградации перед обращением клиента — это не сам RDS-хост, а один-два «зависших» процесса браузера или Excel-сессии с открытым тяжёлым отчётом, которые за минуты съедают гигабайты RAM. Без агрегации по группам процессов на графике System Overview этого не видно — придётся идти в диспетчер задач на самом сервере, что медленнее, чем один взгляд на дашборд.

Итог по времени: от команды установки до понимания «диск» / «CPU» / «память» / «конкретный процесс» у нас уходит 3–5 минут против часа и более на разворачивание Zabbix-сервера с нуля ради разовой диагностики одного хоста.

Алерты без выделенного сервера: health.d и шаблоны

Health engine Netdata работает локально на агенте и не требует ни базы данных, ни отдельного процесса — правила лежат в текстовых конфигах /etc/netdata/health.d/*.conf и применяются к каждому подходящему графику через директиву on (контекст метрики). Пример правила, аналогичного стоковому шаблону ram_usage, — предупреждение при использовании RAM выше 80% и критический уровень выше 90%:

Ключевые поля: lookup задаёт, как агрегировать данные графика за окно (здесь — среднее за последнюю минуту в процентах от измерения «used»), every — как часто пересчитывать правило, warn/crit — булевы выражения с переменной $this (результат lookup). Для дисковой утилизации сервера 1С мы обычно поднимаем аналогичный шаблон на контекст disk.util с порогом warn на 85% и crit на 95%, а для iowait — отдельное правило на system.cpu с измерением iowait.

Маршрутизация уведомлений настраивается в /etc/netdata/health_alarm_notify.conf — классический агентский способ без Netdata Cloud, поддерживающий десятки каналов (email, Slack, Telegram, PagerDuty, вебхуки). Для Telegram включение выглядит так:

После правки конфига перезапуск агента не обязателен для самого health engine — правила читаются командой netdatacli reload-health, что удобно при итеративной настройке порогов без разрыва сбора метрик. Мы обычно донастраиваем пороги в течение первого дня наблюдения за конкретным сервером клиента, чтобы избежать ложных срабатываний на кратковременных пиках, которые для этого сервера являются нормой (например, ночное резервное копирование СУБД 1С).

Несколько серверов: потоковая репликация parent/child

Если у клиента не один сервер, а несколько (сервер 1С + терминальный сервер + файловый сервер), Netdata умеет стримить метрики с дочерних хостов (child) на один родительский (parent) через модуль streaming, настраиваемый в /etc/netdata/stream.conf. Это не замена Zabbix-серверу, но позволяет получить единую точку просмотра нескольких хостов без Netdata Cloud.

На дочернем сервере (например, сервере 1С) в stream.conf включается отправка на родителя:

На родительском сервере в том же файле описывается секция, разрешающая приём по этому API-ключу и диапазону адресов:

После перезапуска обоих агентов дочерний хост появляется в дашборде родителя как отдельный узел со своей полной историей метрик, а health engine и dbengine родителя могут хранить и оценивать данные child-хоста централизованно. Для инфраструктуры клиента на 3–5 серверов это закрывает задачу «видеть всё в одном окне» без затрат на развёртывание Zabbix-сервера с базой — но важно понимать: это именно потоковая репликация метрик реального времени, а не система инвентаризации, отчётности и эскалаций, которую даёт Zabbix.

Честно: когда Netdata не заменяет Zabbix и Prometheus

Мы используем Netdata как инструмент первого часа диагностики и как лёгкий постоянный мониторинг для небольших инфраструктур клиентов (до 5–10 серверов), где нет смысла держать выделенный Zabbix-сервер. Но для крупной инфраструктуры и долгосрочной эксплуатации мы сознательно остаёмся на Zabbix. Причины — в таблице.

Вывод простой: Netdata выигрывает там, где нужна скорость получения картины по одному-двум серверам прямо сейчас — сервер 1С, терминалка, проблемная виртуалка. Zabbix выигрывает там, где нужна многолетняя история, эскалации дежурным по регламенту и отчётность для клиента. Мы держим оба инструмента в арсенале и выбираем по задаче, а не по привычке.

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

Нужно ли открывать порт 19999 в интернет для работы Netdata?

Нет, и мы этого не делаем. Дашборд по умолчанию слушает на всех интерфейсах, поэтому мы либо ограничиваем доступ на уровне файрвола сервера правилом только для внутренней сети/VPN, либо закрываем порт снаружи и ходим через SSH-туннель. Публикация 19999 в интернет без дополнительной аутентификации — плохая практика.

Съедает ли Netdata заметные ресурсы на нагруженном сервере 1С?

При базовой конфигурации без machine learning и с ограниченными tier-квотами dbengine потребление CPU агентом минимально, а RAM по нашей практике держится в пределах низких сотен мегабайт на типовом сервере 1С. Если ресурсы сервера уже на пределе, мы отключаем модуль ML (секция [ml] в netdata.conf, enabled = no) и снижаем storage tiers до 1–2, чтобы сократить нагрузку на диск и память.

Можно ли использовать Netdata вместо Zabbix совсем без облака?

Да, локальный дашборд и health engine полностью работоспособны без регистрации в Netdata Cloud. Облако нужно только для объединения нескольких хостов в одном веб-интерфейсе без ручной настройки streaming и для части каналов уведомлений — базовые email/Telegram/Slack алерты настраиваются локально через health_alarm_notify.conf.

Как Netdata видит именно кластер 1С, а не десятки процессов rphost?

Через файл apps_groups.conf, где мы явно объединяем процессы ragent, rmngr и rphost в одну группу. После этого в разделе Applications дашборда кластер 1С отображается одной агрегированной линией CPU/RAM/IO, которую удобно сопоставлять с общей загрузкой сервера.

Что делать, если алерты в Telegram сыплются слишком часто?

Обычно причина — порог, выставленный без учёта штатных пиков конкретного сервера (например, ночной архивации СУБД). Мы донастраиваем lookup-окно и warn/crit пороги в правиле health.d индивидуально под паттерн нагрузки клиента в первые сутки наблюдения, применяя изменения командой netdatacli reload-health без перезапуска агента и потери истории.