Node Exporter: какие метрики реально важны

Node Exporter экспортирует сотни метрик о состоянии Linux-сервера. Большинство из них вы никогда не откроете в Grafana. Разберём, какие метрики реально говорят о проблемах — и на что смотреть в первую очередь при инциденте.

Простая утилизация CPU (node_cpu_seconds_total{mode="idle"}) говорит мало. Важны режимы:

iowait — процент времени, когда CPU простаивает в ожидании завершения дисковых операций. Высокий iowait (> 20%) указывает на узкое место в подсистеме хранения, а не на нехватку процессора.

# PromQL: iowait по инстансам
avg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) * 100

steal — время, украденное гипервизором у виртуальной машины. Если steal > 5% на облачной VM — сосед по гипервизору потребляет ресурсы, и надо обращаться к провайдеру.

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

softirq и irq — высокие значения могут указывать на перегрузку сетевой подсистемы или проблемы с прерываниями.

Типичная ошибка — смотреть на node_memory_MemFree_bytes. На Linux свободная память — это почти всегда 0, потому что ядро использует её для кэша.

Правильная метрика — node_memory_MemAvailable_bytes: это память, которую ядро реально может отдать приложениям без свопинга (free + reclaimable cache).

# Доступная память в %
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

Алерт при доступной памяти < 10%:

- alert: LowMemory
  expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
  for: 5m
  labels:
    severity: warning

Заполнение диска — очевидно. Но есть два менее очевидных показателя:

Inode: можно заполнить диск по inode при наличии свободного места. Особенно актуально для /var/log, /tmp, почтовых серверов.

# Использование inode в %
(node_filesystem_files{mountpoint="/"} - node_filesystem_files_free{mountpoint="/"}) / node_filesystem_files{mountpoint="/"} * 100

Latency дисковых операций — критична для баз данных:

# Средняя latency на запись (мс)
rate(node_disk_write_time_seconds_total[5m]) / rate(node_disk_writes_completed_total[5m]) * 1000

Латентность > 20 мс для HDD и > 2 мс для SSD — повод для расследования.

Пропускная способность — не единственное, что важно в сетевых метриках.

node_network_receive_errs_total и node_network_transmit_errs_total — ошибки на сетевом интерфейсе. Ненулевые значения указывают на аппаратные проблемы или плохой кабель.

node_network_receive_drop_total и node_network_transmit_drop_total — дропы пакетов. Причины: переполнение rx/tx буферов, настройки ядра (net.core.rmem_max), перегрузка интерфейса.

# Скорость дропов
rate(node_network_receive_drop_total{device="eth0"}[5m])

Textfile collector позволяет добавить любые метрики без написания экспортера. Node Exporter читает .prom-файлы из указанной директории:

# Запуск с textfile collector
node_exporter --collector.textfile.directory=/var/lib/node_exporter/textfile_collector

Пример: мониторинг результата резервного копирования:

#!/bin/bash
# /etc/cron.daily/backup-check
BACKUP_SUCCESS=1
# ... логика проверки бэкапа ...
echo "backup_last_success_timestamp $(date +%s)" > /var/lib/node_exporter/textfile_collector/backup.prom
echo "backup_success ${BACKUP_SUCCESS}" >> /var/lib/node_exporter/textfile_collector/backup.prom

Методология USE (Utilization, Saturation, Errors) от Брендана Грегга — структурированный способ диагностики:

• Utilization — насколько ресурс занят (CPU %, disk %)
• Saturation — есть ли очередь (load average, disk queue depth)
• Errors — есть ли ошибки (disk errors, network errors)

Применяйте USE ко всем ключевым ресурсам: CPU, RAM, диски, сеть. Если Utilization < 80%, Saturation ≈ 0, Errors = 0 — ресурс в порядке. Любое отклонение — сигнал для расследования.

Мониторинг полезен только тогда, когда вы знаете, что именно смотреть. Эти метрики закрывают 90% инцидентов с производительностью в типичной Linux-инфраструктуре.