Node Exporter - это стандартный экспортер метрик для Linux-серверов в экосистеме Prometheus. Сразу после установки он предоставляет готовые к использованию данные о процессоре, памяти, дисках, файловых системах, сети и десятках других подсистем. Вам не нужно писать скрипты или настраивать агентов: метрики отдаются по HTTP в унифицированном формате, который Prometheus понимает без дополнительной обработки.
Этот материал - практическое руководство по работе с метриками Node Exporter. Вы узнаете, какие коллекторы активны по умолчанию, как читать выдачу endpoint'а /metrics и как писать PromQL-запросы для получения конкретных показателей: процента утилизации CPU, реально занятой памяти, свободного места на диске и количества inodes. Все примеры проверены на версиях Node Exporter 1.8.x и Prometheus 2.54.x, актуальных на июль 2026 года.
Если вам нужна пошаговая инструкция по развертыванию самого стека, обратитесь к руководству по мониторингу Linux-серверов с Node Exporter, где описан процесс установки за 5 минут, импорт готовых дашбордов Grafana и настройка алертов.
Какие метрики сервера собирает Node Exporter «из коробки»
После запуска Node Exporter открывает порт 9100 и отдает сотни метрик. Они сгруппированы по коллекторам - модулям, каждый из которых отвечает за свою подсистему. По умолчанию включены практически все коллекторы, кроме тех, что требуют повышенных привилегий или специфичного оборудования. Разберем ключевые группы.
Процессор: загрузка, режимы и утилизация
Коллектор cpu предоставляет метрику node_cpu_seconds_total - счетчик времени, которое каждое ядро процессора провело в определенном режиме. Режимы кодируются меткой mode:
- idle - процессор простаивал;
- user - выполнялся код пользовательских процессов;
- system - работало ядро (системные вызовы, драйверы);
- iowait - процессор ждал завершения операций ввода-вывода;
- steal - гипервизор передал ресурсы другой виртуальной машине;
- softirq и irq - обработка программных и аппаратных прерываний.
Значение метрики монотонно растет с момента загрузки системы. Для получения процента утилизации нужно вычислять производную по времени - этим занимается функция rate() в PromQL. Отдельные метрики node_intr_total и node_context_switches_total показывают количество прерываний и контекстных переключений, что полезно при диагностике проблем с драйверами или чрезмерной многозадачностью.
Память: доступная, использованная и кэши
Коллектор memory экспортирует данные из /proc/meminfo. Ключевые метрики:
node_memory_MemTotal_bytes- общий объем физической памяти;node_memory_MemFree_bytes- свободная память, не используемая ни для чего;node_memory_MemAvailable_bytes- память, доступная для новых процессов без свопинга (включает часть кэшей, которые ядро может освободить);node_memory_Buffers_bytes- буферы ввода-вывода;node_memory_Cached_bytes- страничный кэш;node_memory_SwapTotal_bytesиnode_memory_SwapFree_bytes- использование свопа.
Главная ловушка для новичков - ориентироваться на MemFree. Linux агрессивно кэширует файлы, поэтому свободной памяти может быть мало, но система не испытывает дефицита. Prometheus позволяет строить запросы на основе MemAvailable, что дает реалистичную картину. Метрика node_memory_MemAvailable_bytes появилась в ядре 3.14 и учитывает reclaimable-память - ту часть кэша, которую ядро готово отдать процессам при необходимости.
Диски и файловые системы: место и inodes
Node Exporter разделяет метрики блочных устройств (коллектор diskstats) и файловых систем (коллектор filesystem). Для мониторинга свободного места используются метрики файловых систем:
node_filesystem_size_bytes- общий размер раздела;node_filesystem_avail_bytes- доступно для непривилегированных процессов;node_filesystem_free_bytes- свободно полностью (включая зарезервированные блоки);node_filesystem_filesиnode_filesystem_files_free- количество inodes (общее и свободное).
Метки mountpoint и device позволяют фильтровать данные по точке монтирования и устройству. Мониторинг inodes критически важен: файловая система может иметь гигабайты свободного места, но исчерпать лимит индексных дескрипторов при хранении миллионов мелких файлов. В этом случае создание новых файлов станет невозможным, хотя df -h будет показывать свободное место. PromQL-запрос, отслеживающий процент использованных inodes, предотвращает такие аварии.
Сеть: трафик, ошибки и сокеты
Коллектор netdev экспортирует счетчики по каждому сетевому интерфейсу:
node_network_receive_bytes_totalиnode_network_transmit_bytes_total- принятые и переданные байты;node_network_receive_packets_totalиnode_network_transmit_packets_total- количество пакетов;node_network_receive_errs_totalиnode_network_transmit_errs_total- ошибки приема и передачи;node_network_receive_drop_totalиnode_network_transmit_drop_total- отброшенные пакеты.
Коллектор netstat добавляет информацию о состоянии сетевых соединений: node_netstat_Tcp_CurrEstab показывает количество установленных TCP-соединений, node_netstat_Tcp_RetransSegs - количество повторно переданных сегментов (индикатор проблем с сетью). Рост ошибок или дропов на интерфейсе - ранний признак неисправности кабеля, проблемы с драйвером или перегрузки буфера.
Кроме перечисленных, Node Exporter включает коллекторы loadavg (метрики node_load1, node_load5, node_load15), systemd (состояние сервисов), processes (количество процессов по состояниям) и десятки других. Полный список доступен в документации к вашей версии экспортера, но перечисленные выше покрывают 90% потребностей ежедневного мониторинга.
Формат метрик Node Exporter: как читать и интерпретировать
Node Exporter отдает метрики в Prometheus exposition format - текстовом формате, который Prometheus парсит при каждом scrape-запросе. Откройте http://your-server:9100/metrics в браузере или curl, и вы увидите структурированный вывод.
Каждая метрика предваряется строками HELP и TYPE:
# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 1.234567e+06
node_cpu_seconds_total{cpu="0",mode="user"} 45678.9HELP содержит текстовое описание метрики. TYPE указывает тип: counter (монотонно растущий счетчик), gauge (значение, которое может увеличиваться и уменьшаться), histogram, summary. Сама метрика состоит из имени, набора меток в фигурных скобках и числового значения.
Метки - ключевой механизм фильтрации и агрегации. Например, node_cpu_seconds_total имеет метки cpu (номер ядра) и mode (режим работы). node_filesystem_avail_bytes - метки device, fstype и mountpoint. В PromQL вы можете отфильтровать метрики по значениям меток: node_cpu_seconds_total{mode="idle"} вернет данные только для режима простоя. Метки instance и job добавляются самим Prometheus при сборе и идентифицируют хост и группу целей.
Понимание структуры метрик необходимо для написания запросов. Когда вы видите counter, вы знаете, что к нему нужно применять rate() или increase(). Когда видите gauge - можно использовать значение напрямую или вычислять производные. Детальный разбор типов метрик и их применения выходит за рамки этой статьи, но базового понимания достаточно для работы с приведенными ниже запросами.
Пишем базовые PromQL-запросы для Node Exporter
PromQL - язык запросов Prometheus. Для Node Exporter существует набор проверенных запросов, которые решают типовые задачи мониторинга. Каждый пример можно скопировать и выполнить в веб-интерфейсе Prometheus или использовать при создании дашбордов и алертов.
Утилизация CPU в процентах
Самый востребованный запрос - процент загрузки процессора. Поскольку node_cpu_seconds_total это counter, мы вычисляем скорость изменения времени простоя и вычитаем ее из 100%:
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)Разберем синтаксис. rate(node_cpu_seconds_total{mode="idle"}[5m]) вычисляет производную счетчика за 5-минутное скользящее окно - получаем долю времени, проведенного в простое, в секундах за секунду. avg by (instance) усредняет значения по всем ядрам, группируя результат по хосту. Умножение на 100 переводит долю в проценты, а вычитание из 100 дает процент утилизации. Если нужно посмотреть загрузку отдельного ядра, замените avg by (instance) на avg by (cpu).
Использование памяти: сколько действительно занято
Запрос, который показывает процент использованной памяти с учетом возможности освобождения кэшей:
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
Здесь node_memory_MemAvailable_bytes делится на node_memory_MemTotal_bytes - получаем долю доступной памяти. Вычитание из единицы и умножение на 100 дает процент занятой. Этот запрос корректнее, чем использование MemFree, потому что Linux хранит в памяти кэши, которые могут быть освобождены. Система с 200 МБ свободной памяти и 30 ГБ кэша не испытывает дефицита, и запрос через MemAvailable это отразит.
Для алертов можно использовать абсолютные значения: node_memory_MemAvailable_bytes < 1 * 1024^3 сработает, когда доступной памяти останется меньше гигабайта.
Свободное место на диске и запас inodes
Процент свободного места на корневом разделе:
(node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100Фильтр {mountpoint="/"} выбирает корневую файловую систему. Для других разделов укажите нужную точку монтирования. Если хотите отслеживать все разделы сразу, уберите фильтр и добавьте агрегацию: min by (mountpoint) (...) покажет наихудший показатель по каждому разделу.
Процент свободных inodes:
(node_filesystem_files_free{mountpoint="/"} / node_filesystem_files{mountpoint="/"}) * 100Пороговое значение для алерта - менее 10% свободных inodes. Исчерпание inodes происходит незаметно при обычном мониторинге дискового пространства, но последствия такие же серьезные, как и нехватка места. Если у вас есть приложения, создающие много мелких файлов (почтовые серверы, системы кэширования, сборки контейнеров), этот запрос обязателен.
Сетевой трафик и ошибки
Входящий трафик в битах в секунду по всем интерфейсам:
sum(rate(node_network_receive_bytes_total[5m])) * 8
rate() дает байты в секунду, умножение на 8 переводит в биты. sum без группировки суммирует трафик по всем интерфейсам сервера. Для отображения по конкретному интерфейсу добавьте фильтр: {device="eth0"}. Исходящий трафик - аналогично через node_network_transmit_bytes_total.
Отслеживание ошибок:
rate(node_network_receive_errs_total[5m]) > 0
Этот запрос возвращает интерфейсы, на которых есть ошибки приема. Даже единичные ошибки на проводном интерфейсе - повод проверить кабель или настройки дуплекса.
Load Average
Средняя нагрузка за 1, 5 и 15 минут доступна напрямую как gauge-метрики:
node_load1 node_load5 node_load15
Эти значения показывают среднее количество процессов в очереди на выполнение. Для интерпретации нужно знать количество ядер CPU: значение node_load1, равное количеству ядер, означает полную загрузку без очереди. Превышение в 2-3 раза указывает на перегрузку. Запрос для нормализации нагрузки на ядро:
node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"})Результат больше 1 означает, что процессы ждут освобождения процессора.
Интеграция Node Exporter с Prometheus: настройка и первые шаги
Node Exporter устанавливается как статический бинарник или через пакетный менеджер вашего дистрибутива. После запуска он слушает порт 9100. Для интеграции с Prometheus добавьте секцию в prometheus.yml:
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['your-server-ip:9100']После перезагрузки Prometheus (или отправки SIGHUP) новая цель появится в веб-интерфейсе на странице Status → Targets. Состояние «UP» означает, что метрики собираются успешно. Если состояние «DOWN», проверьте сетевую доступность порта 9100 и отсутствие файрвола.
Для массового развертывания используйте service discovery: консул, Kubernetes, файловое обнаружение. В продакшене настройте TLS и basic auth на стороне Node Exporter через флаги --web.config.file - метрики сервера не должны быть доступны публично. Подробная инструкция по установке с примерами для Docker и systemd есть в руководстве по установке Prometheus и Node Exporter, где разобраны оба способа запуска за 20 минут.
Практические сценарии мониторинга с Node Exporter
Сбор метрик - первый шаг. Реальная ценность раскрывается при настройке алертов и визуализации. Приведем минимальный набор правил, который закрывает критические риски.
Алерт на высокую утилизацию CPU (правило для Alertmanager):
alert: HighCPUUsage
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 10m
labels:
severity: warning
annotations:
summary: "CPU usage above 90% for 10 minutes"Алерт на нехватку дискового пространства:
alert: LowDiskSpace
expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
for: 5m
labels:
severity: critical
annotations:
summary: "Root partition has less than 10% free space"Алерт на исчерпание inodes:
alert: LowInodes expr: (node_filesystem_files_free / node_filesystem_files) * 100 < 10 for: 5m labels: severity: critical annotations: summary: "Filesystem has less than 10% free inodes"
Для визуализации используйте Grafana с готовым дашбордом Node Exporter Full (ID 1860 в каталоге Grafana). Он включает графики CPU, памяти, дискового ввода-вывода, сети и системных метрик. Импорт занимает минуту и дает полную картину состояния сервера. Если вы работаете с Kubernetes, обратитесь к руководству по настройке мониторинга Kubernetes с Prometheus и Grafana для интеграции метрик узлов в общую систему наблюдения за кластером.
Расширение возможностей: textfile collector и кастомные метрики
Встроенные коллекторы покрывают стандартные подсистемы Linux, но иногда требуются специфичные метрики: температура процессора, статус RAID-массива, количество очередей в приложении. Node Exporter решает эту задачу через textfile collector - модуль, который читает метрики из файлов в указанной директории.
При запуске Node Exporter укажите флаг --collector.textfile.directory=/var/lib/node_exporter/textfile_collector. Экспортер будет сканировать эту директорию на наличие файлов с расширением .prom и добавлять их содержимое к своей выдаче. Формат файлов - тот же Prometheus exposition format.
Пример: cron-скрипт, который каждую минуту записывает температуру CPU в файл /var/lib/node_exporter/textfile_collector/cpu_temp.prom:
# HELP cpu_temperature_celsius CPU temperature # TYPE cpu_temperature_celsius gauge cpu_temperature_celsius 52.0
После записи файла метрика cpu_temperature_celsius станет доступна в Prometheus без перезапуска экспортера. Этот механизм позволяет мониторить практически любые показатели: статус бэкапов, количество сообщений в очереди, версию установленных пакетов. Единственное ограничение - метрики должны быть типа gauge или counter, histogram и summary через textfile collector не поддерживаются.
Для мониторинга состояния жестких дисков через S.M.A.R.T. используйте специализированный экспортер. Пошаговая настройка описана в руководстве по установке SMART Exporter для Prometheus, где рассмотрена интеграция с textfile collector и создание дашбордов для визуализации атрибутов дисков.
Node Exporter - фундамент мониторинга Linux-серверов в стеке Prometheus. Освоив его метрики и PromQL-запросы, вы получаете полный контроль над состоянием инфраструктуры: от базовых показателей CPU и памяти до тонкой диагностики сетевых ошибок и исчерпания inodes. Начните с установки экспортера и приведенных в статье запросов - это займет не более получаса и даст немедленную отдачу в виде прозрачности ваших серверов.