Мониторинг производительности Linux: полное руководство по инструментам

Введение в мониторинг производительности Linux

Мониторинг производительности Linux — это не просто проверка загрузки CPU. Это комплексный анализ системы: процессор, память, диски, сеть, ввод-вывод. Понимание метрик позволяет предотвратить простои, оптимизировать затраты на ресурсы и быстро реагировать на аномалии.

В этом руководстве вы освоите как базовые утилиты, так и расширенные инструменты. Мы сосредоточимся на практических сценариях: как найти «горячий» процесс, почему диск медленный, почему сеть перегружена. Все команды работают на большинстве дистрибутивов (Ubuntu, CentOS, Debian, Fedora).

Базовые утилиты для ежедневного использования

top и htop: интерактивный мониторинг процессов

top — ваш первый инструмент при анализе. Запустите его и изучите экран:

top

Ключевые строки:

• %Cpu(s): разбивка на us (пользовательские процессы), sy (системные), id (простой).
• KiB Mem: использование RAM: used, free, buff/cache.
• KiB Swap: активность подкачки.

Сортировка: нажмите P (по CPU), M (по памяти). Чтобы увидеть все процессы, включая потоки, добавьте -H при запуске: top -H.

Совет: htop — улучшенная версия с цветами, деревом процессов и удобным управлением. Установите через sudo apt install htop или sudo yum install htop.

vmstat: виртуальная статистика

vmstat даёт сводку по системе каждые N секунд. Идеален для быстрой проверки «общего здоровья».

vmstat 2

Пример вывода:

procs -----------memory---------- ---swap-- -----io------ -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 123456  78900 456789    0    0   100   200  123  456 30 10 55  5  0

Расшифровка:

• r: процессы в очереди на выполнение. Значение > количества ядер — нехватка CPU.
• si/so: страницы, перемещаемые в/из подкачки. Ненулевые значения указывают на недостаток RAM.
• us/sy: высокие значения (>80%) говорят о нагрузке на CPU.
• wa: время, затраченное на ожидание ввода-вывода. Высокий wa (например, >20%) — проблема с дисками.

iostat: детали по дискам и CPU

Установите пакет sysstat, если ещё не сделали. Команда:

iostat -x 2

Ключевые метрики для дисков (Device):

• %util: процент времени, когда диск занят операциями. Близко к 100% — диск перегружен.
• await: среднее время (в мс) завершения операции. Высокие значения (например, >50 мс для SSD) — проблема.
• svctm: среднее время обслуживания операции. Сравнивайте с await. Если await >> svctm, очередь большая.

Для CPU: %user, %system, %idle.

df и du: место на дисках

Быстрая проверка свободного места:

df -h

human-readable (-h) вывод в гигабайтах. Обращайте внимание на %Use. Если >90% — очистите логи или увеличьте том.

Чтобы найти «пожирателей» места в конкретной папке:

du -sh /var/* | sort -rh | head -10

Это покажет 10 самых больших подпапок в /var.

ss и netstat: сетевая активность

ss — современная замена netstat. Быстрый просмотр соединений:

ss -tuln

Флаги:

• -t: TCP,
• -u: UDP,
• -l: listening,
• -n: numeric (без разрешения имён).

Для статистики по интерфейсам:

ip -s link

Или для деталей по сетевым пакетам:

nstat

Расширенные инструменты для глубокого анализа

sar: сбор исторических данных

sar (System Activity Reporter) записывает метрики каждые N минут. Данные хранятся в /var/log/sysstat/ (имя файла зависит от дистрибутива, например, sa14 для 14-го дня).

Просмотр данных за сегодня:

sar -u  # CPU
sar -r  # Memory
sar -b  # I/O
sar -n DEV  # Network interfaces

Пример: sar -u 2 5 — CPU каждые 2 секунды, 5 раз.

Преимущество: можно увидеть, что происходило в момент проблемы, даже если вы не сидели у терминала.

nmon: интерактивный мониторинг всех ресурсов

Установите nmon (sudo apt install nmon). Запустите:

nmon

Клавиши:

• c — CPU,
• m — memory,
• d — disks,
• n — network,
• t — top processes,
• q — выход.

nmon полезен для быстрого осмотра и записи сессии (файл .nmon), который потом можно анализировать в Excel или через nmon2csv.

glances: кросс-платформенный мониторинг

glances — Python-утилита, которая объединяет много метрик в одном интерактивном интерфейсе. Установка:

pip install glances
# или для системы:
sudo apt install glances

Запуск: glances. Поддерживает цвета, алерты (пороги), экспорт в JSON, InfluxDB, Elasticsearch.

Графические и веб-решения

Для долгосрочного мониторинга и визуализации используйте связки:

1. Prometheus + Grafana: сбор метрик через экспортеры (node_exporter) и красивый дашборд.
2. Netdata: «из коробки» мониторинг с веб-интерфейсом на порту 19999. Установка: bash <(curl -Ss https://my-netdata.io/kickstart.sh).
3. Zabbix/Nagios: для enterprise-мониторинга с алертами.

Практические сценарии

Сценарий 1: Высокая загрузка CPU

1. Запустите top или htop.
2. Сортируйте по %CPU. Найдите процесс с максимальным потреблением.
3. Если это java, python, node — проверьте логи приложения.
4. Если это kworker или migration — возможно, проблема в ядре или IRQ.
5. Используйте perf top для профилирования (установите linux-tools).

Сценарий 2: Диск полностью занят

1. iostat -x 2 — смотрите %util и await по дискам.
2. iotop (установите через sudo apt install iotop) — показывает, какой процесс пишет/читает.
3. Если await высокий, а %util низкий — возможно, проблема в сети (NFS, iSCSI).
4. Проверьте очередь диска: cat /proc/diskstats | grep <device>.

Сценарий 3: Нехватка памяти

1. free -h — смотрите available (доступно) и swap.
2. Если swap активно используется (si/so в vmstat >0) — недостаток RAM.
3. ps aux --sort=-%mem | head -10 — топ-10 по памяти.
4. Проверьте кэш: cat /proc/meminfo | grep -E "Cached|Buffers". Большой кэш — нормально, ОС использует свободную RAM.
5. Если процесс «съедает» память — ищите утечки (например, через valgrind для C/C++).

Сценарий 4: Сетевая перегрузка

1. ip -s link — ошибки (errs) и дропы (drop) по интерфейсу.
2. ss -s — сводка по сокетам (например, много TIME-WAIT).
3. nethogs (установите) — показывает трафик по процессам.
4. iftop — аналогично top, но для сети.

Автоматизация и алертинг

Для регулярного сбора данных настройте cron и sar:

# Включите сбор данных (если не запущен)
sudo systemctl enable sysstat
sudo systemctl start sysstat

Файл /etc/default/sysstat (Debian/Ubuntu) или /etc/sysconfig/sysstat (RHEL/CentOS) содержит параметры сбора (например, SA1_OPTIONS="-S XALL" для всех метрик).

Для алертов используйте:

• monit — простой демон, который следит за процессами, дисками, CPU.
• nagios/zabbix — сложные системы с веб-интерфейсом.
• Скрипты на Bash/Python, которые проверяют метрики и шлют уведомления (например, через mail или Telegram API).

Пример скрипта для проверки загрузки CPU:

#!/bin/bash
LOAD=$(awk '{print $1}' /proc/loadavg)
THRESHOLD=$(nproc)  # количество ядер
if (( $(echo "$LOAD > $THRESHOLD" | bc -l) )); then
  echo "Высокая нагрузка: $LOAD" | mail -s "Alert: CPU load" admin@example.com
fi

Интерпретация метрик и профилактика

Ключевые индикаторы

• CPU: %idle < 20% — перегрузка. Но для веб-серверов нормально 70-80% idle, если нет очереди.
• Memory: available < 10% от total — тревога. Следите за swap — если активен, это признак нехватки RAM.
• Disk: await > 20 мс для SSD, > 10 мс для HDD — проблема. %util > 80% — диск не справляется.
• Network: рост drop/errs — перегрузка или ошибка драйвера.

Профилактика

• Регулярно проверяйте логи (/var/log/syslog, dmesg).
• Настройте мониторинг с порогами (например, CPU > 90% 5 минут).
• Ограничивайте процессы через cgroups (systemd slice, docker limits).
• Обновляйте ядро и драйверы — иногда проблемы исправляются в новых версиях.
• Для I/O-интенсивных задач используйте ionice и nice.

Частые ошибки новичков

• Смотреть только top без учёта wa — пропустить I/O-проблему.
• Считать free в free -m как «свободная память» — не учитывать кэш. Лучше available.
• Игнорировать si/so в vmstat — подкачка убивает производительность.
• Не настраивать алерты — узнают о проблеме, когда сервер уже упал.

Заключение

Мониторинг — это непрерывный процесс. Начните с базовых утилитий (top, vmstat, iostat), затем добавьте sar для истории и glances/nmon для комплексного обзора. Для production-сред обязательно настройте графические дашборды (Grafana) и алерты.

Помните: метрики без контекста бесполезны. Знайте свою нагрузку: сколько запросов в секунду, объём данных, пиковые часы. Тогда аномалии будут видны сразу.