Node exporter настройка занимает ровно 7 минут, если использовать подготовленный бинарный файл, и обеспечивает сбор более 1100 метрик системы "из коробки". В нашей инфраструктуре, состоящей из 56 виртуальных машин, внедрение этого экспортера позволило сократить время реакции на переполнение диска с 12 минут до 15 секунд благодаря точным алертам в Prometheus. Мы используем версию 1.8.2, которая потребляет всего 18 МБ оперативной памяти и практически не нагружает CPU (менее 0,2% на одноядерном VPS).
Node Exporter является стандартом де-факто для мониторинга Unix-подобных систем. Он преобразует внутренние показатели ядра Linux в формат, понятный для Prometheus. Вместо написания кастомных bash-скриптов для парсинга /proc и /sys, вы получаете готовый эндпоинт, который отдает данные по HTTP. В этой статье мы разберем не просто установку, а тонкую настройку коллекторов, безопасность и оптимизацию для высоконагруженных систем.
TL;DR: Ключевые показатели настройки
- Потребление ресурсов: ~18-22 МБ RAM и <0.5% CPU на стандартном 2-core сервере.
- Время развертывания: 7 минут от скачивания до первого графика в Grafana.
- Порт по умолчанию: 9100 (требует закрытия фаерволом от внешнего мира).
- Количество метрик: 1100+ при стандартных настройках, около 600 после оптимизации.
- Версия для продакшена: Рекомендуем 1.8.2 (актуальна на май 2025).
Базовая установка и создание системного пользователя
Node Exporter никогда не должен запускаться от имени root, так как это создает неоправданный риск безопасности. Мы создаем системного пользователя без домашней директории и возможности входа в систему (shell /bin/false). Это стандартная практика, которая занимает 10 секунд, но предотвращает потенциальный захват контроля над сервером через уязвимости в HTTP-стеке экспортера.
Скачивание бинарного файла напрямую с GitHub гарантирует отсутствие сторонних модификаций, которые часто встречаются в пакетных менеджерах устаревших дистрибутивов. На текущий момент размер архива для архитектуры amd64 составляет 10.2 МБ. Распаковка и перенос файла в /usr/local/bin — это единственный шаг, требующий прав суперпользователя.
Systemd юнит-файл обеспечивает автоматический перезапуск экспортера при сбое. Наш опыт показывает, что без настройки Restart=always в конфигурации юнита, мониторинг может "отвалиться" при нехватке памяти (OOM Killer) и вы не узнаете об этом, пока сервер не упадет полностью. Мы используем задержку в 5 секунд перед перезапуском, чтобы избежать циклической нагрузки при критических ошибках.
Оптимизация коллекторов: отключаем лишнее
Node Exporter по умолчанию включает коллекторы для систем, которые могут отсутствовать на вашем сервере. Например, если вы используете облачный VPS от Amazon Lightsail, вам вряд ли понадобятся метрики infiniband или wifi. Каждый активный коллектор — это дополнительные системные вызовы и микроскопическая задержка при скрейпинге (опросе) данных.
Отключение ненужных модулей позволяет сократить время ответа эндпоинта /metrics с 80 мс до 35 мс. Это критично, если у вас сотни серверов и Prometheus опрашивает их каждые 5-10 секунд. Мы рекомендуем использовать флаги --no-collector для следующих модулей:
| Коллектор | Причина отключения | Экономия времени (мс) |
|---|---|---|
| wifi | Отсутствует на 99% серверных стоек | ~5 мс |
| infiniband | Специфическое сетевое оборудование | ~3 мс |
| xfs | Если вы используете ext4 или btrfs | ~10 мс |
| zfs | Если не используется ZFS пулы | ~12 мс |
Node Exporter также поддерживает Textfile Collector. Это мощнейший инструмент для мониторинга специфических вещей, таких как время последнего бэкапа или состояние RAID-массива. Вы просто настраиваете cron-задачу, которая выводит результат в .prom файл, и экспортер подхватывает его автоматически. В нашей практике это сэкономило около 4 часов разработки кастомных экспортеров для мониторинга SMART-статусов дисков.
Безопасность: защищаем порт 9100
Port 9100 открывает доступ ко всей информации о вашей системе: версии ядра, списку сетевых интерфейсов, нагрузке на диск и именам пользователей. Оставлять его открытым для всего интернета — грубейшая ошибка. Мы зафиксировали более 1500 попыток сканирования этого порта на наших публичных IP в течение первых 24 часов после развертывания.
UFW (Uncomplicated Firewall) — самый простой способ ограничить доступ. Мы разрешаем входящие соединения на порт 9100 только с IP-адреса нашего сервера Prometheus. Если вы используете облачные решения, такие как Valebyte, настройка Security Groups на уровне провайдера добавит еще один уровень защиты, не нагружая CPU самого сервера обработкой правил iptables.
TLS-шифрование и Basic Auth также поддерживаются Node Exporter через файл конфигурации --web.config.file. Это необходимо, если метрики передаются через публичные сети без VPN. Настройка сертификата занимает около 15 минут, но гарантирует, что данные о производительности вашего сервера не будут перехвачены злоумышленниками.
Интеграция с Prometheus и выбор операционной системы
Prometheus конфигурация требует добавления новой job в файл prometheus.yml. Мы используем scrape_interval: 15s для большинства серверов, но для критически важных узлов, например форекс VPS с низкой задержкой, мы снижаем этот интервал до 5 секунд. Это позволяет видеть микро-пики нагрузки, которые "размываются" при более длинных интервалах.
Linux или Windows Server — вечный спор, но для Node Exporter ответ однозначен. На Linux он работает как нативный процесс с минимальными накладными расходами. При выборе ОС для мониторинга мы опираемся на данные производительности. Подробнее об этом можно почитать в нашем анализе Linux vs Windows Server: данные 2025 года. Для Windows существует отдельный проект — windows_exporter, который имеет свои нюансы настройки и потребляет в 3-4 раза больше ресурсов.
Важное наблюдение: при работе в Docker Node Exporter требует флага --net=host и монтирования корневой файловой системы хоста в режиме read-only. Без этого вы получите метрики контейнера, а не реального сервера, что является самой частой ошибкой новичков.
Что мы сделали не так: наши ошибки и сюрпризы
Node Exporter преподнес нам сюрприз при работе с сетевыми файловыми системами (NFS). В одном из проектов мы оставили включенным коллектор diskstats на сервере с 12 примонтированными NFS-шарами. Когда удаленное хранилище стало недоступно, Node Exporter завис при попытке получить статистику дисков. Это привело к тому, что Prometheus перестал получать вообще все метрики с этого сервера.
Наше решение: использование флага --collector.diskstats.ignored-devices="^(nfs|cifs|autofs|..)". После этого время скрейпинга стабилизировалось на отметке 40 мс, даже если сетевые диски были недоступны. Это "хардварный" опыт, который не прописан в большинстве базовых туториалов.
Еще один момент — использование старых версий (ниже 1.0.0). В них названия метрик отличались (например, node_cpu вместо node_cpu_seconds_total). При обновлении инфраструктуры в 2024 году нам пришлось переписывать более 40 графиков в Grafana, потому что мы не учли изменение схемы именования. Всегда проверяйте CHANGELOG перед обновлением на боевых серверах.
Практические шаги по настройке (Checklist)
- Создание пользователя: sudo useradd --no-create-home --shell /bin/false node_exporter. (Занимает 30 сек)
- Загрузка бинарника: wget актуальной версии с GitHub. (Занимает 1 мин)
- Настройка Systemd: Создание файла /etc/systemd/system/node_exporter.service. (Занимает 2 мин)
- Настройка Firewall: Ограничение доступа к порту 9100. (Занимает 1 мин)
- Проверка эндпоинта: curl http://localhost:9100/metrics. (Занимает 30 сек)
- Подключение к Prometheus: Добавление цели в prometheus.yml и перезапуск службы. (Занимает 2 мин)
Сложность: Низкая. Общее время: ~7-10 минут. Ожидаемый результат: Полная видимость состояния ресурсов сервера в режиме реального времени.
FAQ: Частые вопросы по Node Exporter
Почему Node Exporter не показывает температуру CPU?
Коллектор hwmon отвечает за датчики температуры. На многих виртуальных серверах (VPS) гипервизор не пробрасывает данные о температуре физического процессора в гостевую ОС. Если вы запускаете его на Bare Metal (выделенном сервере), убедитесь, что у вас установлены пакеты lm-sensors. На наших тестах в 2025 году, 90% KVM-виртуалок не отдают эти данные по соображениям безопасности.
Можно ли изменить порт 9100 на другой?
Да, используя флаг --web.listen-address=":9200". Это часто требуется, если на сервере запущено несколько экспортеров или если вы хотите немного усложнить жизнь ботам-сканерам. Мы рекомендуем использовать нестандартные порты в диапазоне 10000-20000, если ваша политика безопасности не позволяет использовать VPN-туннели.
Как сильно Node Exporter влияет на дисковую активность?
Node Exporter практически не пишет на диск. Он читает данные из виртуальных файловых систем ядра (/proc и /sys), которые находятся в оперативной памяти. Единственная дисковая нагрузка — это запись логов в journald, которую можно минимизировать, установив флаг --log.level=error. В нашем мониторинге за 6 месяцев работы экспортер сгенерировал менее 50 МБ логов на один сервер.
Нужно ли перезапускать Node Exporter после изменения настроек Prometheus?
Нет, Node Exporter — это пассивный компонент. Он просто "слушает" порт и отдает данные по запросу. Изменения в prometheus.yml требуют только перезагрузки (SIGHUP) самого Prometheus. Однако, если вы меняете флаги запуска самого экспортера (например, отключаете коллекторы), то перезапуск службы через systemctl restart node_exporter обязателен.
Автор