Установка Netdata на сервер с Linux для мониторинга в реальном времени с готовыми алертами

Серверный мониторинг по традиции собирают вручную: экспортер, база метрик, витрина, правила алертов, служба доставки - и вот вечер ушёл на подготовку каркаса. Netdata идёт от обратного: один скрипт ставит агента, который через минуту после установки уже показывает живые графики с секундовым разрешением и держит наготове сотни встроенных проверок. Статья разбирает установку, обзор дашборда, настройку уведомлений в Telegram и на почту, аппетиты по ресурсам и честный ответ на вопрос, когда такого инструмента достаточно вместо связки Prometheus и Grafana.

Что такое Netdata и чем живой мониторинг отличается от классического набора

Netdata - это агент мониторинга, который ставится прямо на наблюдаемый сервер и читает всё, до чего может дотянуться: процессор, память, диски, сетевые интерфейсы, процессы, контейнеры, а при наличии доступов и прикладные сервисы вроде nginx, PostgreSQL или MySQL. Ключевое отличие от классической тройки "экспортер плюс база плюс витрина" в разрешении и готовности. Метрики собираются раз в секунду, а не раз в пятнадцать, дашборд работает сразу после установки, и типичный узел отдаёт порядка десяти тысяч метрик без единой строки конфигурации.

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

Третье - независимость. Дашборд живёт на самом сервере, история метрик хранится локально, ни один байт не обязан уходить в облако. Подключение к облачной консоли агрегации существует, но включается опционально, и для одного-трёх серверов оно попросту не нужно.

Установка одним скриптом и что она делает с системой

Установка сводится к одной команде.

curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel

Скрипт определяет дистрибутив, подключает пакетный репозиторий проекта, ставит агент актуальной стабильной ветки 2.12 и регистрирует системную службу netdata. После завершения агент стартует сам, а повторный запуск того же скрипта позже обновит установку, сохранив локальные настройки. Флаги канала дают выбор: stable для проверенных релизов или nightly для свежих сборок с новыми функциями, на продакшене разумнее первый.

Что окажется на диске. Файлы агента живут в /opt/netdata, конфигурация в /etc/netdata, журнал читается через journalctl по юниту netdata. Перед агентом не ставится отдельная база или витрина - всё нужное уже внутри. Проверить здоровье после установки позволяет обращение к локальному статусу.

systemctl status netdata --no-pager
curl -s localhost:19999/info | head -c 300

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

Дашборд из коробки и автодетект прикладных сервисов

Веб-интерфейс открывается по адресу сервера на порту 19999 и встречает живой картиной. Секции слева идут от общего к частному: обзор системы, процессор с разбивкой по ядрам и состояниям, память и подкачка, диски с временем ожидания и очередями, сетевые интерфейсы с трафиком по отдельности и суммарно, затем процессы, сгруппированные по приложениям. Графики обновляются каждую секунду, и это ощущается сразу: запущенный на сервере бэкап виден на дисковых графиках в момент запуска, а не через минуту.

Работа с процессами - отдельная сильная сторона. Секция приложений группирует потребление по программам, и по ней сразу видно, кто съел память: конкретный пул PHP, база или разложившийся скрипт. На панелях видны дочерние процессы, перезапуски и тренды по каждому приложению, что превращает разбор "сервер тормозит" из гадания в два клика: график медленной секунды плюс топ процессов на тот же момент времени.

Автодетект прикладных метрик - самый приятный сюрприз для тех, кто привык прописывать экспортеры руками. На сервере с nginx агент подхватывает метрики статусной страницы, если она включена, базам PostgreSQL и MySQL хватает локального доступа через служебные учётные записи, PHP FPM отдаёт статистику через свою страницу статуса. Никакого отдельного экспортера ставить не нужно, агент читает штатные интерфейсы сервисов и собирает их метрики в те же секундовые графики. Список включившихся коллекционеров виден в разделе мониторинга самого агента, там же отключаются лишние.

Тонкость, о которой молчат восторженные обзоры: автодетект работает настолько, насколько ему открыли доступы. Свежий nginx без stub_status покажет только внешние метрики процесса, база без служебного пользователя даст ровно ноль прикладных графиков. Поэтому после установки полезно потратить пять минут и завести агенту штатные доступы только для чтения к сервисам, которые действительно важны.
Ещё одна функция интерфейса, о которой редко вспоминают сразу, - наложение периодов времени: текущая неделя поверх предыдущей сразу показывает, что изменилось в поведении сервера, и для поиска "стало медленно" это часто быстрее любых порогов.

Встроенные проверки, аномалии и свои пороги без сложного синтаксиса

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

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

Своя проверка пишется коротким файлом в каталоге /etc/netdata/health.d и не требует изучения языка запросов.

 template: high_user_cpu
       on: system.cpu
   lookup: average -5m unaligned of user
     every: 1m
      warn: $this > 80
      crit: $this > 95
      info: пользовательская загрузка процессора выше 80 процентов пять минут подряд

Файл перечитывается без перезапуска службы, и через минуту новая проверка появляется в общем списке рядом со штатными. Такой формат позволяет быстро закрыть специфичную для проекта боль, например уведомление при падении конверсионного скрипта или затянувшейся сборке, не покидая привычный интерфейс.

Подключение уведомлений в Telegram и на почту без долгой настройки

Встроенные проверки срабатывают сразу, но молча: доставка уведомлений по умолчанию выключена. Включается она правкой одного файла /etc/netdata/health_alarm_notify.conf, и порядок действий выглядит так:

1. В мессенджере регистрируется бот и получается токен, затем создаётся отдельный чат для алертов;
2. В файле включается отправка в Telegram: флаг отправки ставится в YES, вписываются токен бота и идентификатор чата;
3. Для почты заполняются адрес сервера исходящих сообщений, ящик отправителя и учётные записи, получатели назначаются по ролям;
4. Конфигурация проверяется штатным тестовым скриптом агента, который отправляет пробное сообщение во все настроенные каналы.

Роли получателей - механизм, который стоит настроить сразу. Проверки делятся на роли вроде системного администратора, дежурного и наблюдателя, и разные каналы назначаются разным ролям: критичное уходит в чат дежурных, информационное - на общую почту. Тестовая отправка выполняется скриптом alarm-notify.sh из каталога плагинов с аргументом test, и если пробное сообщение пришло в оба канала, дальше можно не волноваться: вся остальная доставка работает через тот же механизм.

Строки для мессенджера в файле выглядят лаконично.

SENDTELEGRAM="YES"
TELEGRAM_BOTTOKEN="токен-бота"
TELEGRAM_CHATID="-1001234567890"

Минус в идентификаторе означает групповой чат, и его потеря - классическая причина молчащей доставки, ровно та же, что встречается в связке с Alertmanager.

Для почты действует та же оговорка, что и везде: исходящий порт 25 у большинства провайдеров закрыт, поэтому в настройках указывают 587 с авторизацией и шифрованием. На время плановых работ проверки глушатся встроенным механизмом пауз с указанием времени и причины, что честнее отключения агента целиком и не забывается, потому что пауза заканчивается сама.

Обновление агента и содержание конфигурации в порядке

Установка не требует ухода, но три операции стоит знать заранее. Обновление выполняется повторным запуском kickstart-скрипта: он подхватывает репозиторий, ставит новую версию и сохраняет конфигурацию. Автоматические обновления переключаются флагом при установке, на продакшене их обычно отключают и обновляют вручную в согласованное окно. Хранитель настроек - штатный скрипт edit-config из каталога агента: он открывает нужный файл из /etc/netdata в редакторе и оставляет рядом оригинал, поэтому даже неудачная правка откатывается за секунды.

Резервная копия установки сводится к двум каталогам: /etc/netdata с конфигурацией и проверками и /var/lib/netdata с выученными моделями аномалий. Их архивируют штатным tar по расписанию, и переезд на новый сервер превращается в пятиминутное дело: установка агента, распаковка каталогов, перезапуск службы.

Аппетиты по ресурсам, хранение истории и когда Netdata хватает вместо Prometheus

Честный вопрос к инструменту, живущему на каждом сервере: сколько он ест. Ответ зависит от нагрузки и набора коллекционеров, но типичный агент занимает единицы процентов процессора и несколько сотен мегабайт памяти. История хранится локальным движком с ограничением по объёму: по умолчанию отводятся десятки-сотни мегабайт, чего хватает на дни или недели секундного разрешения в зависимости от числа метрик. Глубину регулируют в netdata.conf секцией базы, там же указывают объём кеша страниц движка.
При желании история удлиняется в разы настройкой многоуровневого хранения: горячие секунды остаются в памяти, тёплые значения уходят на диск сжатыми, и месячный горизонт помещается в сотни мегабайт. Практика показывает, что для сервера с типовым набором сервисов этого хватает на большинство разборов инцидентов, а для действительно долгих рядов у баз метрик свои роли.

Для исторических запросов "как вела себя память в прошлом квартале" такой глубины нет, и это первое ограничение, о котором стоит знать. Второе - масштаб: дашборд показывает один сервер, обзор группы узлов требует либо облачной консоли проекта, либо внешней витрины. Агент при этом отдаёт метрики наружу в формате Prometheus, так что при росте парка серверов переход на классический стек происходит без потери уже собранного опыта и порогов. В этом и есть главный характер инструмента: он закрывает сегодняшний день целиком и легко уступает глубокие архивы профессиональным базам метрик.

Отсюда простая граница применимости. Небольшой хостинг из нескольких машин, вопрос "что происходит прямо сейчас" и готовые проверки - Netdata закрывает потребность целиком, и ставить рядом Prometheus незачем. Десятки узлов, потребность в долгой истории, единые панели по всей ферме - тогда агент спокойно соседствует с классическим стеком. Многие администраторы держат оба инструмента, и они не конфликтуют: один даёт глубину истории, второй - скорость реакции на живом сервере.