Мониторинг Linux-сервера с Prometheus Node Exporter: установка, ключевые метрики, дашборды и алерты (2026) | AdminWiki
Logo

Мониторинг Linux-сервера с Prometheus Node Exporter: установка, ключевые метрики, дашборды и алерты (2026)

24 июля 2026 9 мин. чтения
Содержание статьи

Node Exporter - это официальный агент Prometheus для сбора системных метрик с Linux-серверов. Он работает по pull-модели: Prometheus периодически забирает данные с HTTP-эндпоинта :9100/metrics, который отдаёт сотни показателей - от загрузки процессора до состояния ZFS-пулов. Без этого экспортера мониторинг физических и виртуальных машин в стеке Prometheus невозможен. В этом руководстве вы получите проверенную пошаговую инструкцию: установка Node Exporter, интеграция с Prometheus, разбор ключевых метрик, импорт готовых дашбордов Grafana и настройка алертов. Все шаги проверены на актуальных версиях ПО в 2026 году.

Архитектура проста. На каждом Linux-хосте запускается один экземпляр Node Exporter. Prometheus опрашивает его с заданным интервалом и сохраняет временные ряды в своей базе. Grafana визуализирует эти данные, а Alertmanager рассылает уведомления при нарушениях. Если вы разворачиваете стек с нуля, начните с полного руководства по настройке Prometheus, Grafana и оповещений - там описана базовая установка всех компонентов.

Введение: зачем нужен Node Exporter и как он вписывается в стек Prometheus

Prometheus собирает метрики только через HTTP-эндпоинты, которые отдают данные в его формате. Ядро Linux не предоставляет такого интерфейса. Node Exporter решает эту задачу: он читает /proc, /sys и другие системные источники, преобразует информацию в метрики Prometheus и отдаёт их на порту 9100. Один экземпляр обслуживает один хост - физический сервер, виртуальную машину или контейнер с полноценным ядром.

Экспортер написан на Go, потребляет минимум ресурсов и не требует зависимостей. Он поддерживает более 50 коллекторов - модулей, каждый из которых отвечает за свою подсистему: CPU, память, диски, сеть, ZFS, systemd и другие. Часть коллекторов включена по умолчанию, часть активируется флагами. Такой подход позволяет тонко настроить сбор метрик под конкретную рабочую нагрузку.

Установка и запуск Node Exporter на Linux

Установка из пакетного менеджера возможна, но версия может отставать. Рекомендуемый способ - загрузка бинарника с GitHub. Это гарантирует актуальность и одинаковое поведение на любом дистрибутиве Linux.

Загрузка и распаковка бинарного файла

Определите актуальную версию на странице релизов проекта. На момент написания статьи это 1.9.0. Скачайте архив под архитектуру вашего сервера. Для amd64 команды выглядят так:

wget https://github.com/prometheus/node_exporter/releases/download/v1.9.0/node_exporter-1.9.0.linux-amd64.tar.gz
sha256sum node_exporter-1.9.0.linux-amd64.tar.gz

Сверьте контрольную сумму с указанной в релизе. Распакуйте архив и переместите бинарник в системный путь:

tar xzf node_exporter-1.9.0.linux-amd64.tar.gz
sudo mv node_exporter-1.9.0.linux-amd64/node_exporter /usr/local/bin/
sudo chown root:root /usr/local/bin/node_exporter

Проверьте версию:

node_exporter --version

Создание systemd-сервиса для автозапуска

Для автоматического запуска и перезапуска при сбоях создайте unit-файл:

sudo tee /etc/systemd/system/node_exporter.service <<EOF
[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
Type=simple
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter \
  --collector.systemd \
  --collector.processes
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

Создайте системного пользователя без домашней директории и прав на вход:

sudo useradd -r -s /bin/false node_exporter

Активируйте и запустите сервис:

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

Проверка работоспособности: первый взгляд на метрики

Убедитесь, что экспортер отвечает:

curl -s http://localhost:9100/metrics | head -20

Вы увидите строки вида:

node_cpu_seconds_total{cpu="0",mode="idle"} 1.234567e+06
node_memory_MemTotal_bytes 1.6e+10

Каждая строка - это метрика с лейблами и значением. Такой вывод Prometheus забирает при каждом скрейпе.

Интеграция Node Exporter с Prometheus

Node Exporter отдаёт метрики, но Prometheus должен знать, откуда их забирать. Настройка сводится к добавлению нового таргета в секцию scrape_configs файла prometheus.yml.

Настройка scrape_config в Prometheus

Минимальная конфигурация для одного сервера:

scrape_configs:
  - job_name: 'linux-servers'
    static_configs:
      - targets:
        - '10.0.1.10:9100'
        - '10.0.1.11:9100'
        labels:
          environment: 'production'
          team: 'backend'

Для динамического окружения используйте file_sd - Prometheus будет читать список таргетов из JSON-файла, который можно обновлять без перезагрузки:

  - job_name: 'linux-servers'
    file_sd_configs:
      - files:
        - '/etc/prometheus/targets/linux-servers.json'

Файл linux-servers.json выглядит так:

[
  {
    "targets": ["10.0.1.10:9100"],
    "labels": {
      "hostname": "web-01"
    }
  }
]

После изменения конфигурации перезагрузите Prometheus:

sudo systemctl reload prometheus

Проверка появления таргета и метрик в Prometheus

Откройте веб-интерфейс Prometheus (по умолчанию http://prometheus-host:9090). Перейдите в Status → Targets. Найдите job linux-servers. Статус должен быть UP, а время последнего скрейпа - несколько секунд назад. Если статус DOWN, проверьте сетевую доступность порта 9100 и отсутствие файрвола.

Перейдите на вкладку Graph, введите запрос node_cpu_seconds_total и нажмите Execute. Вы увидите график или таблицу с данными - значит, метрики поступают.

Ключевые метрики Node Exporter: что мониторить и как интерпретировать

Node Exporter отдаёт сотни метрик. Для контроля состояния сервера достаточно отслеживать несколько десятков. Разберём их по подсистемам.

Процессор (CPU): загрузка, режимы и троттлинг

Основная метрика - node_cpu_seconds_total. Это счётчик времени, которое CPU провёл в каждом режиме: idle, user, system, iowait, steal. Для вычисления процента загрузки используйте PromQL:

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Высокий iowait указывает на узкое место в дисковой подсистеме. steal больше 1-2% - гипервизор перегружен, ваша виртуальная машина не получает обещанных ресурсов. Троттлинг отслеживается через node_cpu_core_throttles_total - рост этого счётчика сигнализирует о перегреве или проблемах с питанием.

Среднюю нагрузку дают метрики node_load1, node_load5, node_load15. Значение load average выше количества ядер CPU - повод для расследования.

Память: использование, кэши и swap

Не смотрите на node_memory_MemFree_bytes в изоляции. Linux активно использует свободную память под кэш, и низкий показатель Free - норма. Ключевая метрика - node_memory_MemAvailable_bytes: сколько памяти доступно для новых процессов без обращения к swap. Именно её падение ниже 10-15% от общего объёма - тревожный сигнал.

Swap отслеживайте через node_memory_SwapFree_bytes. Рост использования swap при нормальной работе приложений говорит о том, что реальной памяти не хватает. Периодический выброс страниц в swap допустим, но постоянное использование - проблема.

Дисковое пространство и операции ввода-вывода

Свободное место по точкам монтирования даёт node_filesystem_avail_bytes. Фильтруйте по mountpoint и fstype, исключая временные и псевдо-файловые системы:

node_filesystem_avail_bytes{mountpoint="/", fstype!="tmpfs"}

Утилизацию диска показывает node_disk_io_time_seconds_total - счётчик времени, которое диск был занят операциями. Значение 1.0 за интервал означает 100% utilisation. Пропускную способность дают node_disk_read_bytes_total и node_disk_written_bytes_total.

Отдельно проверяйте использование inode: node_filesystem_files_free. Даже при наличии свободного места закончившиеся inode делают запись невозможной.

Сеть: трафик, ошибки и соединения

Объём трафика по интерфейсам:

rate(node_network_receive_bytes_total{device="eth0"}[5m])

Ошибки и дропы - критический индикатор проблем на физическом уровне или перегрузки:

  • node_network_receive_errs_total
  • node_network_transmit_errs_total
  • node_network_receive_drop_total
  • node_network_transmit_drop_total

Любое ненулевое значение ошибок за короткий интервал требует проверки кабелей, трансиверов и настроек duplex. Количество установленных TCP-соединений даёт node_netstat_Tcp_CurrEstab. Резкий скачок может указывать на проблемы с пулом соединений приложения или SYN-флуд.

Специфика ZFS: мониторинг пулов и производительности

Стандартные метрики файловых систем не показывают состояние ZFS-пулов. Node Exporter включает коллектор ZFS, но он отключен по умолчанию. Активируйте его флагом --collector.zfs в строке ExecStart systemd-юнита.

Ключевые метрики ZFS:

  • node_zfs_zpool_state - состояние пула: 0=online, 1=degraded, 2=faulted, 3=offline. Значение больше 0 - алерт немедленно.
  • node_zfs_zpool_read_bytes и node_zfs_zpool_written_bytes - пропускная способность пула.
  • node_zfs_arc_stats - статистика Adaptive Replacement Cache: хиты, миссы, размер. Поле arc_hits_perc ниже 90% означает, что ARC не справляется, и чтение идёт с дисков.

Мониторинг ZFS критичен для NAS-решений. Без него деградация пула может остаться незамеченной до потери данных.

Готовые дашборды Grafana для Node Exporter

Grafana.com содержит десятки готовых дашбордов для Node Exporter. Импорт занимает минуту и даёт информативную визуализацию без ручной настройки панелей.

Импорт дашборда из Grafana.com

В Grafana перейдите в Dashboards → New → Import. Введите ID дашборда или вставьте JSON. Укажите источник данных Prometheus. Нажмите Import. Дашборд готов к использованию.

Обзор дашборда «Node Exporter Full»

ID 1860 - самый популярный дашборд для Node Exporter. Он содержит секции:

  • CPU - загрузка по ядрам, режимы, load average.
  • Memory - использование, кэш, swap, распределение.
  • Disk - занятое место по точкам монтирования, IOPS, throughput, utilisation.
  • Network - трафик по интерфейсам, ошибки, пакеты в секунду.
  • System - uptime, количество процессов, открытые файловые дескрипторы.

Дашборд универсален и подходит для первого знакомства с метриками любого Linux-хоста.

Альтернативные дашборды и их особенности

ID 11074 «Node Exporter Server Metrics» - более компактный вариант. Он фокусируется на ключевых показателях и удобен для быстрого обзора десятков серверов на одном экране. Для ZFS-инфраструктуры ищите специализированные дашборды с панелями состояния пулов и ARC-статистики - они используют метрики, которые отдаёт коллектор --collector.zfs.

Настройка алертов: как вовремя узнать о проблемах

Правила алертинга определяют, какие условия считать проблемными. Они пишутся на PromQL и размещаются в файле, на который ссылается Prometheus в секции rule_files.

Базовые алерты: CPU, память, диск

Высокая загрузка CPU в течение 5 минут:

- alert: HighCPUUsage
  expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "CPU usage above 90% on {{ $labels.instance }}"

Мало доступной памяти:

- alert: LowMemory
  expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Available memory below 10% on {{ $labels.instance }}"

Заканчивается место на диске - прогноз на 4 часа вперёд:

- alert: DiskSpaceRunningOut
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 4*3600) < 0
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "Disk / will be full in 4 hours on {{ $labels.instance }}"

Алерты для ZFS и сети

Пул ZFS не в состоянии online:

- alert: ZFSPoolNotOnline
  expr: node_zfs_zpool_state > 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "ZFS pool {{ $labels.zpool }} state is not online on {{ $labels.instance }}"

Сетевые ошибки на интерфейсе:

- alert: NetworkErrors
  expr: rate(node_network_receive_errs_total[5m]) > 0
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Network receive errors on {{ $labels.device }} at {{ $labels.instance }}"

Интеграция с Alertmanager и маршрутизация уведомлений

Prometheus отправляет сработавшие алерты в Alertmanager. Тот группирует, дедуплицирует и маршрутизирует их получателям: Slack, Telegram, Email, PagerDuty. Базовая настройка Alertmanager описана в руководстве по стеку мониторинга. Пример маршрута для отправки критических алертов в Telegram:

route:
  receiver: 'telegram-critical'
  routes:
    - match:
        severity: critical
      receiver: 'telegram-critical'
receivers:
  - name: 'telegram-critical'
    telegram_configs:
      - bot_token: 'YOUR_BOT_TOKEN'
        chat_id: -123456789

Безопасность и тюнинг Node Exporter

По умолчанию Node Exporter отдаёт метрики по HTTP без аутентификации. В production-среде доступ к эндпоинту /metrics должен быть ограничен.

Ограничение доступа к метрикам

Самый простой способ - nginx reverse proxy с basic auth перед Node Exporter. Конфигурация nginx:

server {
    listen 9100;
    server_name _;

    auth_basic "Node Exporter";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:19100;
    }
}

Node Exporter при этом запускается на 127.0.0.1:19100, недоступный извне. В Prometheus в scrape_configs добавляется basic_auth с логином и паролем.

Встроенная поддержка TLS и basic auth появилась в версии 1.0.0 через флаг --web.config.file. Создайте YAML-конфигурацию с секциями tls_server_config и basic_auth_users - это исключает необходимость в обратном прокси.

Выборочный сбор метрик для снижения нагрузки

Node Exporter включает несколько десятков коллекторов по умолчанию. Каждый лишний коллектор - это затраты CPU на сбор и память на хранение метрик. Отключите ненужные и включите только необходимые:

ExecStart=/usr/local/bin/node_exporter \
  --collector.disable-defaults \
  --collector.cpu \
  --collector.meminfo \
  --collector.diskstats \
  --collector.filesystem \
  --collector.netdev \
  --collector.zfs

Такой подход сокращает количество метрик на 60-70% и снижает нагрузку на Prometheus. Полный список коллекторов смотрите в выводе node_exporter --help.

Заключение: дальнейшие шаги и поддержка

Вы настроили полный мониторинг Linux-серверов: Node Exporter собирает метрики, Prometheus хранит их, Grafana визуализирует, а Alertmanager оповещает о проблемах. Этот стек закрывает потребности инфраструктуры любого масштаба - от одного VPS до сотен физических хостов.

Для углубления в тему изучите руководство по системам мониторинга производительности - там разобраны CLI-утилиты для срочной диагностики и расширенные сценарии Prometheus. Если вы работаете с высоконагруженными системами, обратите внимание на практики наблюдаемости для high-load с готовыми шаблонами алертов и дашбордов для SRE. Для мониторинга веб-серверов используйте гайд по мониторингу Nginx с конфигурациями Prometheus и скриптами анализа логов.

Все инструкции в базе знаний проверяются на практике. Если вы заметили несоответствие версий или ошибку - возвращайтесь к актуальной редакции статьи. Дата последней проверки: июль 2026.

Поделиться:
Сохранить гайд? В закладки браузера