Omnia Metria in SAR Collecta — Мониторинг Linux с SAR: обширное описание метрик и как их читать

Состояние сервера можно условно сравнить со здоровьем человека: оно у всех разное и умирают все от разных причин. Пульс, давление, температура — это показатели, которые помогают в диагностике нас. В мире Linux эти показатели: CPU, использование памяти, работа дисков и прочее. Как и в медицине, мониторинг можно проводить в реальном времени или анализировать уже собранные данные.

Если у человека проблема с сердцем 🩺, врач может сделать ЭКГ прямо сейчас, но если нужны показатели за длительный период, нужен суточный мониторинг ЭКГ по Холтеру, который может показать, например, проблемы ночью. В Linux этим занимается набор инструментов sysstat, в состав которого входит, в том числе, утилита sar, которая помогает визуализировать данные в логах /var/log/sysstat/.

Разделы:

• перейти к Часть I. Установка и настройка sysstat.

  • Настройка автоматического сбора данных через cron.

  • Связь sysstat, sar, sadc, /var/log/sysstat, etc/default/sysstat, цикл работы.

  • Связь sa1 и debian-sa1.

  • Таблица: варианты использования sar с параметрами в реальном времени и с файлом.

• перейти к Часть II. Пример использования sar для чтения из логов двух нод Kubernetes — умозрительный пример.

  • Что показывают top pods и sar: для чего нужно.

• перейти к Часть III. Команда sar и диагностика проблем: описание метрик и что они означают, наглядные таблицы. Описание проблем.

  • Общая инфо по CPU (sar -u, sar -P ALL, sar -q, sar -f, sar -A -f).

  • Использование памяти (sar -r, sar -S).

  • Диски и ввод-вывод (sar -b, sar -d, sar -p).

  • Сетевые метрики (sar -n DEV, sar -n TCP, sar UPD, sar -n EDEV).

  • Контекстные переключения и задержки (sar -w, sar -W).

  • Использование ресурсов по процессам (pidstat -x).

  • Энергопотребление CPU (sar -m CPU).

  • Полный анализ метрик (sar -A): что в него входит.

  • Другие полезные команды sar (sar -g, sar -v, sar -F, sar -B, sar -H).

I. Установка и настройка sysstat и sar

На следующей картинке среди многообразия инструментов для анализа производительности sar располагается в разделе Various, потому что работает с метриками сразу из нескольких областей.

В этой статье рассматривается утилита sar из набора инструментов sysstat.

❓ Посмотрим, как она помогает ответить на вопросы:

• Нагрузка на CPU

  • Какова средняя загрузка процессора за последние часы/дни?

  • Какие процессы потребляют больше всего ресурсов?

  • Были ли моменты высокой нагрузки на CPU?

  • Как распределена нагрузка между user, system, iowait, steal и idle?

• Использование памяти

  • Как изменялось использование RAM за день?

  • Был ли недостаток свободной памяти в определённое время?

  • Какова нагрузка на swap?

• Сетевой трафик

  • Какой объем данных проходит через сетевые интерфейсы?

  • Были ли пики сетевой активности?

  • Какой интерфейс нагружен больше всего?

• Общая производительность системы

  • Как изменилась производительность системы за прошедший период?

  • Какие ресурсы работали на пределе возможностей?

  • Были ли моменты, когда система испытывала нехватку CPU, памяти или сетевых ресурсов?

Все команды приведены для Ubuntu/Debian.

Шаг 1. Обычно набор инструментов sysstat с sar установлен, но проверим версию утилиты:

sudo apt update
apt-cache policy sysstat

Вывод:

sysstat:
  Installed: 12.5.2-2ubuntu0.2
  Candidate: 12.5.2-2ubuntu0.2
  Version table:
 *** 12.5.2-2ubuntu0.2 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        100 /var/lib/dpkg/status
     12.5.2-2build2 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

Если версия Installed отличается от версии Candidate, то версию нужно обновить:

sudo apt upgrade sysstat -y

Либо установить с нуля, если не установлено:

sudo apt-get install sysstat

Шаг 2. Проверка наличия утилиты:

sar -V

Шаг 3. Ожидаемый ответ:

sysstat version 12.5.2

Шаг 4. После установки важно включить автоматический сбор данных для доступа к истории.

Для этого измените параметр ENABLED="false" на ENABLED="true" в конфигурационном файле /etc/default/sysstat используется для включения или отключения автоматического сбора статистики утилитой sysstat.

$ sudo vim /etc/default/sysstat  # Или sudo nano /etc/default/sysstat

Шаг 5. Перезапустите службу sysstat:

$ sudo systemctl restart sysstat

Начало лирического отступления.

Почему это важно?

• Сбор исторических данных. Если ENABLED отключен (false), утилита sysstat не будет автоматически собирать данные о производительности системы. При включении активируются фоновые процессы, такие какsadc, которые собирают статистику.

• Интеграция с другими инструментами. Включенный сбор данных позволяет использовать команды, например, sar, для просмотра исторической статистики.

• Если оставить ENABLED=false?Исторические данные будут недоступны.

  Положение дел отображено на схеме, утилит больше, но остановимся на этом.

Весь цикл работы:

1. Пользователь настраивает сбор данных. Файл:/etc/default/sysstat. Что настраивается: включение/выключение автоматического сбора: ENABLED="true" или ENABLED="false".

2. Пользователь настраивает расписание сбора данных. Файл:/etc/cron.d/sysstat. Пример строки крон‑задачи: 5-55/10 * * * * root /usr/lib/sysstat/sa/sa1 1 1.

3. Служба sysstat.serviceперезапускает крон‑задачу при изменении конфигурации.

4. Утилита sadc (System Activity Data Collector):

   1. Запускается через крон‑задачу.

   2. Собирает метрики: CPU, память, диски, сеть, процессы.

   3. Сохраняет данные в бинарные файлы: /var/log/sysstat/saXX (для текущего месяца, где XX — день).

5. Пользователь запрашивает данные утилитой sar(System Activity Reporter). Пользователь запрашивает отчёты с помощью sar: sar /var/log/sysstat/sa10. Она читает данные из файлов /var/log/sysstat/saXX и формирует отчёт.

6. Вывод для пользователя. Утилитаsarвозвращает пользователю готовый отчёт по производительности системы.

Конец лирического отступления.

Шаг 6. У нас автоматический сбор данных активируется через cron‑задачу (/etc/cron.d/sysstat). Но может быть запущено и через systemd, но мы не будем переключаться.

sudo vim /etc/cron.d/sysstat 

Изменим /etc/cron.d/sysstat:

# Сбор данных каждые десять минут (среднее значение) по рабочим дням.
*/10 * * * 1-5 root command -v debian-sa1 > /dev/null && debian-sa1 600 1

Шаг 7. Так как редактировался файл с заданиями cron напрямую, а не через crontab -e, службу cron необходимо перезапустить.

sudo systemctl restart cron

Особенности:

*/10 * * * 1-5 root command -v debian-sa1 > /dev/null && debian-sa1 600 1 — обратим внимание на запись 600 1. Она означает, что собираются средние данные за каждые 10 минут (600 секунд) и записывает одну итерацию, т. е., не срез 1 секунды раз в 10 минут, а рассчитывает среднее значение.

*/10 * * * 1-5 root command -v debian-sa1 > /dev/null && debian-sa1 1 1 – здесь запись 1 1 говорит о том, делается раз в десять минут один мгновенный срез.

Начало лирического отступления.

Для понимания работы:

• sa1 — стандартное название утилиты из пакета sysstat, которая запускает сбор данных через sadc и сохраняет их в файлы /var/log/sysstat/saXX.

• debian-sa1 — специальная версия команды sa1, которая используется в Debian‑based системах.

Сначала я думала, что debian-sa1 — это символическая ссылка на sa1, но это не так. Это самостоятельный исполняемый файл.

Связь между ними можно проверить командой:

ls -l /usr/lib/sysstat/sa1 /usr/lib/sysstat/debian-sa1

Вывод:

Символической ссылки нет.

Содержимое /usr/lib/sysstat/debian‑sa1 можно посмотреть командой:

sudo cat /usr/lib/sysstat/debian-sa1

Вывод:

#!/bin/sh
# vim:ts=2:et
# Debian sa1 helper which is run from cron.d job, not to needlessly
# fill logs (see Bug#499461).

set -e

# Skip in favour of systemd timer
[ ! -d /run/systemd/system ] || exit 0

# Our configuration file
DEFAULT=/etc/default/sysstat
# Default setting, overridden in the above file
ENABLED=false

# Read defaults file
[ ! -r "$DEFAULT" ] || . "$DEFAULT"

[ "$ENABLED" = "true" ] || exit 0

exec /usr/lib/sysstat/sa1 "$@"

Этот файл представляет собой скрипт, который управляет запуском sa1 .

Конец лирического отступления.

Шаг 8. Проверим работу службы sysstat:

 sudo systemctl status sysstat

✅ Вывод состояния active говорит о том, что она работает:

● sysstat.service - Resets System Activity Logs
     Loaded: loaded (/usr/lib/systemd/system/sysstat.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2025-01-22 20:00:21 UTC; 1h 5min ago
       Docs: man:sa1(8)
             man:sadc(8)
             man:sar(1)
    Process: 882 ExecStart=/usr/lib/sysstat/sa1 --boot (code=exited, status=0/SUCCESS)
   Main PID: 882 (code=exited, status=0/SUCCESS)

Если inactive, то запускаем:

sudo systemctl start sysstat

Шаг 9. Проверим работу работу службы cron:

sudo systemctl status cron

✅ Вывод состояния active говорит о том, что она работает:

● cron.service - Regular background program processing daemon
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; pres>
    Drop-In: /etc/systemd/system/cron.service.d
             └─crond.conf
     Active: active (running) since Fri 2025-01-31 10:33:09 UTC; 1h 22mi>
       Docs: man:cron(8)
   Main PID: 9879 (cron)
      Tasks: 1 (limit: 2274)
     Memory: 328.0K (peak: 1.8M)
        CPU: 66ms
     CGroup: /system.slice/cron.service
             └─9879 /usr/sbin/cron -f -P

Если не работает, то нужно запустить:

sudo systemctl start cron

🚫 Пример вывода с ошибкой:

● cron.service - Regular background program processing daemon
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/cron.service.d
             └─crond.conf
     Active: active (running) since Wed 2025-01-22 19:57:21 UTC; 1min 51s ago
       Docs: man:cron(8)
   Main PID: 13668 (cron)
      Tasks: 1 (limit: 2274)
     Memory: 332.0K (peak: 600.0K)
        CPU: 2ms
     CGroup: /system.slice/cron.service
             └─13668 /usr/sbin/cron -f -P

Jan 22 19:57:21 compute-vm systemd[1]: Started cron.service - Regular background program processing daemon.
Jan 22 19:57:21 compute-vm cron[13668]: (CRON) INFO (pidfile fd = 3)
Jan 22 19:57:21 compute-vm (cron)[13668]: cron.service: Referenced but unset environment variable evaluates to an empty string: EXTRA_>
Jan 22 19:57:21 compute-vm cron[13668]: Error: bad day-of-week; while reading /etc/cron.d/sysstat
Jan 22 19:57:21 compute-vm cron[13668]: (*system*sysstat) ERROR (Syntax error, this crontab file will be ignored)
Jan 22 19:57:21 compute-vm cron[13668]: (CRON) INFO (Skipping @reboot jobs -- not system startup)

Служба cron работает нормально (active), но из сообщения понятно, что в файле /etc/cron.d/sysstat есть ошибка, из‑за чего он игнорируется. Error: bad day-of-week; while reading /etc/cron.d/sysstat указывает на некорректный синтаксис cron в поле «день недели».

Текст(*system*sysstat) ERROR (Syntax error, this crontab file will be ignored) говорит о том, что весь файл игнорируется из-за ошибки.

Нужно открыть файл и проверить синтаксис cron-задачи:

sudo vim /etc/cron.d/sysstat

В нашем случае была ошибка, не было пробела между * и 1-5:

*/10 * * *1–5 root command ‑v debian‑sa1 > /dev/null && sa1 600 1

Правильный вариант:

*/10 * * * 1-5 root command -v debian-sa1 > /dev/null && sa1 600 1

После исправлений службу cron нужно перезапустить:

sudo systemctl restart cron

Шаг 10. Дальше можно убедиться, что задания из /etc/cron.d/sysstat выполняются:

grep -i "debian-sa1" /var/log/syslog

Вывод одной из строк:

2025-01-31T20:35:01.556865+00:00 compute-vm-2 CRON[9911]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 600 1)

Шаг 11. Ранее мы говорили, что утилита sadc сохраняет данные в бинарные файлы: /var/log/sysstat/saXX (для текущего месяца, где XX — день).

Убедимся, что файл на текущий день (31 января) создаётся.

ls -lh /var/log/sysstat/

Ожидаемый вывод:

-rw-r--r-- 1 root root 1016 Jan 31 03:06 sa31

Шаг 12. Непосредственно использование утилиты sar.

Команда обычно имеет следующий вид:

sar -[параметры для выбора метрик] [частота обновления данных в секундах] [количество повторений]

Разные случаи использования sar с параметрами

Команда sar без параметров ≈ sar -u (как в примере ниже), но может зависеть от настроек, а sar ‑u показывает только статистику по CPU:

sar 

Это общая информация за текущий день, если она есть, в противном случае выводятся данные из последнего файла. В «09:34:37 PM » система была перезагружена.

Вывод:

• Описание метрик можно найти ниже в соответствующем разделе про метрики CPU.

• В сумме все метрики (%user + %nice + %system + %iowait + %steal + %idle) в строке дают 100%, но допускается отклонение из-за округления.

• Если в системе несколько процессоров или ядер, sar показывает их суммарную или среднюю загрузку в строке с all. Например, у нас 2 ядра, и каждое из них загружено так: %user = 2.0, %user = 1.5, то строка all будет показывать среднее %user = (2.0 + 1.5) / 2 = 1.75.

Если нужна информация по каждому ядру, то нужно ввести команду:

sar -P ALL -f /var/log/sysstat/sa31

Пример вывода для 12 ядер:

20:10:00        CPU     %user     %nice   %system   %iowait    %steal     %idle
20:20:00        all      0.11      0.00      0.12      0.00      0.00     99.77
20:20:00          0      0.04      0.00      0.25      0.01      0.00     99.70
20:20:00          1      0.16      0.00      0.06      0.00      0.00     99.78
20:20:00          2      0.65      0.00      0.08      0.00      0.00     99.27
20:20:00          3      0.02      0.00      0.06      0.00      0.00     99.92
20:20:00          4      0.08      0.00      0.08      0.00      0.00     99.84
20:20:00          5      0.00      0.00      0.03      0.00      0.00     99.97
20:20:00          6      0.08      0.00      0.19      0.01      0.00     99.73
20:20:00          7      0.00      0.00      0.03      0.00      0.00     99.97
20:20:00          8      0.07      0.00      0.37      0.01      0.00     99.55
20:20:00          9      0.04      0.00      0.11      0.01      0.00     99.84
20:20:00         10      0.14      0.00      0.20      0.01      0.00     99.65
20:20:00         11      0.00      0.00      0.00      0.00      0.00    100.00

Если %user + %system < 70–80%, это считается нормальным для большинства задач.

Если %idle ≈ 0%, процессор полностью занят, и система может быть перегружена.

Если %iowait высокое при низком %user, это указывает на проблемы с дисковой подсистемой, а не с CPU.

Пример анализа метрик

Нормальная нагрузка:

CPU     %user     %nice   %system   %iowait    %steal     %idle
all      65.00      5.00     10.00      2.00      0.00     18.00

Метрики:

1. %user = 65.00

   • Описание: Основная нагрузка на процессор приходится на пользовательские приложения.

   • Анализ: Это нормальное значение для рабочей системы, где активно используются приложения или службы. Значение менее 50–70% считается приемлемым для большинства задач, но зависит от ситуации.

2. %nice = 5.00

   • Описание: Время, затраченное на выполнение процессов с пониженным приоритетом (nice).

   • Анализ: Небольшое значение (5%) указывает на наличие фоновых задач с пониженным приоритетом, но они не оказывают существенного влияния на общую производительность системы.

3. %system = 10.00

   • Описание: Процессор тратит 10% времени на выполнение системных задач (например, управление памятью, сетевые операции, драйверы устройств).

   • Анализ: Значение 10% находится в пределах нормы. Высокие значения (>20%) могли бы указывать на проблемы с ядром или драйверами.

4. %iowait = 2.00

   • Описание: Процессор простаивает 2% времени, ожидая завершения операций ввода-вывода.

   • Анализ: Это низкое значение (<5%), что говорит о том, что система эффективно обрабатывает операции ввода-вывода без значительных задержек.

5. %steal = 0.00

   • Описание: “Украденное” время гипервизором у виртуальной машины.

   • Анализ: Значение равно 0%, что означает, что система не ограничена ресурсами со стороны гипервизора. Это типично для физических машин или виртуальных машин, которые получают достаточное количество вычислительных ресурсов.

6. %idle = 18.00

   • Описание: Процессор простаивает 18% времени.

   • Анализ: Это значение достаточно велико (>10%), что указывает на наличие запаса производительности для обработки пиковых нагрузок. Система не перегружена.

Более подробно о проблемах можно узнать из описания ниже в соответствующем разделе про метрики CPU.

Полезно

1. Команда для записи в лог может быть полезна не зависимо от наличия автоматического сбора данных в файлы saXX.

sar -o sarlog 1 1200 > /dev/null 2>&1 &

2. Чем отличается запись в лог от автоматического сбора через sadc?

2. Команда для чтения данных из лога:

sar -u -f /home/ubuntu/sarlog > sarlog.txt

II. Пример использования команды sar для диагностики двух нод Kubernetes при работе автоскейлинга подов

1. Создаём управляемый кластер Kubernetes с двумя нодами.

2. Создаем Docker-образ с stress-ng – он будет нагружать CPU.

3. Переносим образ на ноды и загружаем в containerd.

4. Запускаем деплоймент в Kubernetes (kubectl apply -f stress-deployment.yaml).

5. Настраиваем HPA, чтобы он автоматически увеличивал количество подов при высокой нагрузке .

# Используем образ Ubuntu как базовый
FROM ubuntu:latest

# Обновляем пакеты и устанавливаем stress-ng
RUN apt-get update -y && apt-get install -y stress-ng

# По умолчанию запускаем стресс-тест CPU на 90% нагрузки
CMD stress-ng --cpu 2 --cpu-method matrixprod --cpu-load 90 -t 10m --metrics-brief

docker build -t stress-ng-test .

scp stress-ng-test.tar user@{EXTERNAL IP NODE1}:/tmp/.

ssh user@89.169.146.68 "ctr -n k8s.io images import /tmp/stress-ng-test.tar"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stress-test
  labels:
    app: stress-ng
spec:
  replicas: 3
  selector:
    matchLabels:
      app: stress-ng
  template:
    metadata:
      labels:
        app: stress-ng
    spec:
      containers:
      - name: stress-ng
        image: stress-ng-test
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: "500m"
          limits:
            cpu: "1000m"

kubectl apply -f stress-deployment.yaml 

kubectl get pods kubectl top pods

kubectl autoscale deployment stress-test --cpu-percent=80 --min=3 --max=10

kubectl get hpa 

Запуск sar на всех нодах, чтобы записывать метрики CPU (требует активного демона sadc):

for NODE in <EXTERNAL IP NODE1> <EXTERNAL IP NODE2>; do
    ssh user@$NODE "nohup sar -o /tmp/sardata 1 1200 >/dev/null 2>&1 &"
done

Схематично всё можно представить так:

После завершения теста можно скачать логи sar:

for NODE in <EXTERNAL IP NODE1> <EXTERNAL IP NODE2>; do
    scp user@$NODE:/tmp/sardata ./sardata_$NODE
done

Просмотр метрик на каждой ноде:

sar -u -f sardata_<EXTERNAL IP NODE1>
sar -u -f sardata_<EXTERNAL IP NODE2>

Удаляем деплоймент и автомасштабирование.

kubectl delete deployment stress-test
kubectl delete hpa stress-test

for NODE in <EXTERNAL IP NODE1> <EXTERNAL IP NODE2>; do
    ssh user@$NODE "pkill -f 'sar -o'"
done

Пример вывода команды sar:

12:07:07        CPU     %user     %nice   %system   %iowait    %steal     %idle
12:07:08        all     64.82      0.00      0.50      0.00      0.00     34.67
12:07:09        all     63.18      0.00      1.00      0.00      0.00     35.82
12:07:10        all     63.68      0.00      0.50      0.00      0.00     35.82

Если %user около 60-70% и idle есть, можно увеличить лимиты CPU в stress-deployment.yaml

Чтобы увидеть нагрузку на каждое ядро CPU отдельно:

sar -P ALL -f sardata_<EXTERNAL IP NODE1>

12:07:07        CPU     %user     %system   %iowait   %idle
12:07:08        0       70.82      1.50      0.00     27.68
12:07:08        1       50.32      2.00      0.00     47.68
12:07:08        all     64.82      0.50      0.00     34.67

Почему это важно:

• Если CPU all показывает высокую нагрузку (%user > 80%), то все ядра нагружены и кластер перегружен.

• Если CPU all низкий, но одно ядро загружено на 100%, значит, процесс работает в одном потоке (может, не умеет использовать многопоточность?).

• Если CPU all средний, но %idle всё равно низкий, можно проверить -P ALL, чтобы узнать, какие ядра загружены больше всего.

Использование sar помогает глубже понять, как Kubernetes масштабирует поды, насколько нагружены ноды, и есть ли узкие места в кластере.

Главная цель теста – проверить, как ноды справляются с нагрузкой, реагирует ли авто-масштабирование (HPA), и есть ли ресурсы для новых подов.

HPA масштабирует поды, основываясь на requests. Аsar дает другую важную информацию — она показывает, как Kubernetes реально использует ресурсы ноды.

Проблема 1

• kubectl top pods показывает нормальную загрузку, но поды работают медленно.

• HPA не увеличивает реплики, хотя кажется, что нагрузка высокая.

Что покажет sar -u?

12:07:08        CPU     %user   %system   %iowait   %idle
12:07:09        all     30.00    5.00      40.00     25.00   <-- Диск перегружен!

• %iowait = 40% → подам не хватает скорости доступа к диску!

• HPA не видит этой проблемы, потому что он смотрит только на CPU, а не на I/O.

Проверить диск:

iostat -x 1 10

Проблема 2

• kubectl top pods показывает, что HPA добавил новые поды, но CPU ноды все еще загружен.

Что покажет sar -u?

12:07:08        CPU     %user   %system   %steal   %idle
12:07:09        all     60.00    3.00      15.00     22.00   <-- Облачный гипервизор ворует 15% CPU!

Проблема 3:

• kubectl top pods показывает разные уровни нагрузки у разных подов.

• Некоторые поды загружены на 100%, а другие почти ничего не делают.

Что покажет sar -P ALL?

12:07:09        CPU     %user   %idle
12:07:10        0       100.00    0.00   <-- Первое ядро забито
12:07:10        1        0.00   100.00   <-- Второе ядро простаивает
12:07:10        all     50.00    50.00   <-- Среднее значение (не показывает реальную нагрузку!)

Один процесс забил 1 ядро, а другое ядро простаивает → значит, нагрузка распределяется неправильно.

Как исправить?

• Разобраться с многопоточностью (в нашем примере нужно указать 2 ядра `CMD stress-ng –cpu 2 –cpu-method matrixprod …`, а в реальных приложениях это может зависеть от архитектуры и особенностей выполнения кода).

• Проверить балансировку нагрузки между подами.

III. Команда sar и диагностика проблем: список метрик и что они означают

Ниже представлены таблица с основными опциями sar, их описанием, примерами использования, метриками и описанием возможных проблем.

⚠️ Указанные значения метрик, возможные проблемы и их причины приведены для общего ориентирования. По факту «норма» зависит от назначения, нагрузки сервера и других причин.

🔹 1. Общая информация по CPU

1.1 Статистика использования CPU

Пример вывода sar -u 1 3:

10:10:01 AM     CPU  %user  %nice   %system  %iowait  %steal  %idle
10:10:02 AM     all  12.34   0.00     5.67     0.89     0.00   81.10

Описание проблем общее

Описание проблем в зависимости от назначения сервера

🔹 2. Использование памяти

2.1 Использование оперативной памяти

Пример вывода sar -r 1 3 :

10:20:01 AM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit  %commit
10:20:02 AM   1024000  4096000    80.00     250000   1024000   2097152    50.00

Описание метрик

Описание проблем

🔹 3. Диски и ввод-вывод

3.1 Статистика операций ввода-вывода

Пример вывода sar -b 1 3:

10:30:01 AM       tps      rtps      wtps      bread/s      bwrtn/s
10:30:02 AM       5.42      3.12      2.30      512.00       256.00

Описание метрик

Описание проблем

3.2 Статистика по дискам

Пример вывода sar -d 1 3 :

18:57:59          DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
18:58:00          sda      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
18:58:00          sdb      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
18:58:00          sdc      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

Описание метрик

Описание проблем

🔹 4. Сетевые метрики

4.1 Статистика по сетевым интерфейсам

Пример вывода sar -n DEV 1 3:

10:40:01 AM IFACE  rxpck/s  txpck/s  rxkB/s  txkB/s  rxcmp/s  txcmp/s  rxmcst/s
10:40:02 AM  eth0   120.50   100.30   512.00   256.00   0.00     0.00     0.00

Описание метрик

🔹 5. Контекстные переключения и задержки

5.1 Частота переключений задач

Пример вывода sar -w 1 3:

10:50:01 AM     proc/s   cswch/s
10:50:02 AM       2.34     15.67

Описание метрик

5.2 Статистика подкачки

Пример вывода sar -W 1 3:

12:00:01 AM  pswpin/s pswpout/s
12:00:02 AM      0.00      0.00
12:00:03 AM      1.20      3.50
12:00:04 AM      0.00      0.00
Average:         0.40      1.17

Описание метрик

🔹 6. Использование ресурсов по процессам

6.1 Статистика по конкретному процессу

Пример вывода pidstat -x 673 1 3:

11:00:01 AM PID   %user  %system  %steal  %iowait  %idle 
11:00:02 AM 1234   50.00   10.00    0.00    5.00    35.00

Метрики такие же, как в п. 1 дляsar -u и sar -P ALL, кроме %nice.

🔹 7. Энергопотребление CPU

Пример вывода sar -m CPU 1 3:

17:16:38        CPU       MHz
17:16:39        all   2096.05

Описание метрик

🔹 8. Полный анализ системы

Вывод sar -A 1 3 эквивалентен команде:

sar -bBdFHISvwWy -m ALL -n ALL -q ALL -r ALL -u ALL

Где метрики:

• -b (статистика операций ввода-вывода)

• -B (статистика страничной активности)

• -d (статистика по дискам)

• -F (количество процессов, завершённых за секунду)

• -H (высокочастотные события ядра)

• -I (статистика аппаратных и программных прерываний)

• -S (статистика использования раздела подкачки swap)

• -v (файловые дескрипторы)

• -w (частота переключений задач)

• -W (статистика подкачки)

• -y (статистика процессов, ожидающих ввод-вывод)

• -m ALL (все доступные метрики по CPU)

• -n ALL (все доступные сетевые метрики)

• -q ALL (все доступные метрики нагрузки системы)

• -r ALL (все доступные метрики памяти)

• -u ALL (все доступные метрики использования CPU)

🔹 9. Другие полезные команды sar

9.1 Загрузка системы и очередь процессов

Вывод sar -q 1 3:

18:38:38      runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
18:38:39            0       328      0.04      0.01      0.00         0
18:38:40            0       328      0.04      0.01      0.00         0
18:38:41            0       328      0.04      0.01      0.00         0
Average:            0       328      0.04      0.01      0.00         0

Описание метрик

9.2 Информация о дескрипторах файлов

Вывод sar -v 1 3:

18:42:17    dentunusd   file-nr  inode-nr    pty-nr
18:42:18        29263      1568     44044         2
18:42:19        29263      1568     44044         2

Описание метрик

9.3 Информация о высокочастотных событиях ядра

Вывод sar -H 1 3:

19:01:01    kbhugfree kbhugused  %hugused kbhugrsvd kbhugsurp
19:01:02            0         0      0.00         0         0
19:01:03            0         0      0.00         0         0
Average:            0         0      0.00         0         0

Описание метрик

9.4 Информация об обращении к страницам памяти.

Вывод sar -B 1 3 :

19:10:53     pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
19:10:54         0.00      0.00     14.00      0.00     66.00      0.00      0.00      0.00      0.00
19:10:55         0.00      0.00      0.00      0.00     32.00      0.00      0.00      0.00      0.00
19:10:56         0.00      0.00      0.00      0.00      1.00      0.00      0.00      0.00      0.00
Average:         0.00      0.00      4.67      0.00     33.00      0.00      0.00      0.00      0.00

Описание метрик

10.5 Информация о числе операций чтения и записи файловой системы

Пример вывода sar -F 1 3:

19:21:54     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
19:21:55      1020086     10932      1.06      6.15  66933040    175824      0.26 /dev/sdc

19:21:55     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
19:21:56      1020086     10932      1.06      6.15  66933040    175824      0.26 /dev/sdc

19:21:56     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
19:21:57      1020086     10932      1.06      6.15  66933040    175824      0.26 /dev/sdc

Описание метрик

Заключение

В начале статьи мы упоминали список вопросов, на которые может ответить утилита sar из набора инструментов sysstat. И вот как именно.

Нагрузка на CPU

1. Какова средняя загрузка процессора за последние часы/дни?

   • Команда: sar -u .

   • Метрики: %user, %system, %iowait, %steal, %idle .

   • Пример: sar -u показывает среднюю загрузку CPU за текущий день.

2. Какие процессы потребляют больше всего ресурсов?

   • Команда: pidstat -u (не sar, но из пакета sysstat)

   • Метрики: %CPU для каждого процесса.

   • Пример: pidstat -u 1 3 покажет загрузку CPU конкретными процессами в реальном времени.

3. Были ли моменты высокой нагрузки на CPU?

   • Команда: sar -u .

   • Метрики: %user, %system, %idle .

   • Пример: sar -u -f /var/log/sysstat/saXX поможет проанализировать исторические данные и найти пики нагрузки.

4. Как распределена нагрузка между user, system, iowait, steal и idle?

   • Команда: sar -u .

   • Метрики: %user, %system, %iowait, %steal, %idle .

   • Пример: sar -u дает детальное распределение нагрузки.

Использование памяти

5. Как изменялось использование RAM за день?

   • Команда: sar -r .

   • Метрики: %memused, kbmemfree, kbcached .

   • Пример: sar -r покажет изменения использования оперативной памяти за день.

6. Был ли недостаток свободной памяти в определённое время?

   • Команда: sar -r .

   • Метрики: %memused, kbmemfree .

   • Пример: Если %memused > 90% или kbmemfree ≈ 0, это указывает на нехватку памяти.

7. Какова нагрузка на swap?

   • Команда: sar -S .

   • Метрики: %swpused, kbswpused .

   • Пример: sar -S покажет использование подкачки. Высокое значение %swpused может указывать на проблемы.

Сетевой трафик

8. Какой объем данных проходит через сетевые интерфейсы?

   • Команда: sar -n DEV .

   • Метрики: rxkB/s, txkB/s .

   • Пример: sar -n DEV показывает объем входящего (rxkB/s) и исходящего (txkB/s) трафика.

9. Были ли пики сетевой активности?

   • Команда: sar -n DEV .

   • Метрики: rxkB/s, txkB/s .

   • Пример: Анализ графиков rxkB/s и txkB/s поможет выявить пики активности.

10. Какой интерфейс нагружен больше всего?

    • Команда: sar -n DEV.

    • Метрики: rxkB/s, txkB/s.

    • Пример: Сравнение значений для разных интерфейсов (IFACE) покажет наиболее нагруженный.

Общая производительность системы

11. Как изменилась производительность системы за прошедший период?

    • Команда: sar -A -f /var/log/sysstat/saXX.

    • Метрики: Все метрики, включая CPU, память, диски, сеть.

    • Пример: Полная сводка за день покажет тренды по всем ресурсам.

12. Какие ресурсы работали на пределе возможностей?

    • Команда: sar -u, sar -r, sar -b, sar -n DEV.

    • Метрики: %idle (CPU), %memused (память), tps (диск), rxkB/s, txkB/s (сеть).

    • Пример: Низкое %idle или высокое %memused указывают на перегруженные ресурсы.

13. Были ли моменты, когда система испытывала нехватку CPU, памяти или сетевых ресурсов?

    • Команда: sar -u, sar -r, sar -n DEV.

    • Метрики: %idle (CPU), %memused (память), rxkB/s, txkB/s (сеть).

    • Пример: Если %idle < 10% или %memused > 90%, это указывает на проблемы.