sar: мониторинг активности системы со временем

Если ты когда-нибудь ловил себя на мысли “Что же, чёрт возьми, грузит мой сервер?”, или слышал сакраментальное “а почему у нас всё тормозит?”, значит, ты уже близко к тому, чтобы открыть для себя sar — один из самых недооценённых инструментов мониторинга системной активности в Linux. Сегодня расскажу, как с его помощью можно не только увидеть, что происходит на сервере прямо сейчас, но и отмотать время назад, чтобы найти виновника тормозов или понять, когда начались проблемы. Всё просто, быстро и с минимальными затратами ресурсов.

О чём эта статья и зачем тебе вообще нужен sar?

Эта статья — для тех, кто хочет:

• Понять, что происходит с сервером или VPS в динамике, а не только “здесь и сейчас”.
• Автоматизировать сбор статистики по CPU, памяти, дискам, сети — и иметь возможность быстро показать начальству/клиенту/самому себе, когда и почему всё сломалось.
• Не тратить часы на настройку сложных мониторингов, а получить рабочее решение за 10 минут.

Здесь не будет занудных объяснений про “мониторинг ради мониторинга”. Только практика, реальные команды и кейсы. Если ищешь, как быстро и понятно начать с sar — ты по адресу.

Почему мониторинг активности системы со временем — это важно?

Вот типичная ситуация из жизни любого админа или девопса: сервер внезапно начинает тормозить, пользователи жалуются, а ты открываешь top или htop — а там всё уже нормально. Или наоборот: ночью был пик нагрузки, а днём всё спокойно, и ты не можешь понять, что случилось.

В такие моменты хочется иметь машину времени — чтобы посмотреть, какие процессы грузили CPU, сколько было свободной памяти, какой трафик шел по сети, и когда именно всё пошло не так. Вот тут и появляется sar — твой персональный “черный ящик” для Linux.

Что такое sar и как он работает?

sar (System Activity Reporter) — часть пакета sysstat. Это инструмент для сбора и анализа статистики системной активности: процессора, памяти, дисков, сети и многого другого.

Алгоритм работы и структура

• Сбор данных: В фоне работает демон sar (обычно через cron или systemd), который периодически (например, каждую минуту) сохраняет срезы статистики в бинарные файлы (по умолчанию в /var/log/sa/).
• Анализ данных: В любой момент можно получить отчёт за текущий или предыдущий день/неделю/месяц (зависит от настроек хранения) с помощью команды sar — и увидеть, что происходило в системе по минутам.
• Гибкость: Можно анализировать CPU, память, swap, диски, сеть, работу процессов, задержки IO, использование файловых систем и т.д.

В отличие от “живых” утилит вроде top или iotop, sar позволяет смотреть историю — и это его главное преимущество.

Как быстро и просто настроить sar: пошаговая инструкция

Обещал без воды — держу слово. Вот что нужно сделать, чтобы запустить сбор статистики с помощью sar на любом сервере (будь то VPS, выделенный сервер или Docker-хост).

1. Установка sysstat (sar входит в этот пакет)

Для большинства дистрибутивов Linux установка — одна команда:

# Для Debian/Ubuntu
sudo apt update
sudo apt install sysstat

# Для CentOS/RHEL/Fedora
sudo yum install sysstat
# или
sudo dnf install sysstat

# Для Arch Linux
sudo pacman -S sysstat

2. Включение сбора статистики

В некоторых дистрибутивах (например, Ubuntu/Debian) после установки sysstat сбор данных по умолчанию выключен из соображений экономии ресурсов. Нужно включить его вручную.

Открой файл /etc/default/sysstat (или /etc/sysstat/sysstat — зависит от дистрибутива) и найди строку:

ENABLED="false"

Поменяй на:

ENABLED="true"

Сохрани файл и перезапусти сервис:

sudo systemctl restart sysstat

или (если нет systemd):

sudo service sysstat restart

3. Проверка, что всё работает

Через несколько минут после включения можно проверить, что данные начали собираться:

# Посмотреть статистику за сегодня (по умолчанию)
sar

# Посмотреть статистику за вчера
sar -f /var/log/sa/sa$(date --date="yesterday" +%d)

# Посмотреть только статистику по CPU
sar -u

# По памяти
sar -r

# По дискам
sar -d

# По сети
sar -n DEV

Формат файлов saXX — где XX — номер дня месяца (например, sa01, sa15, sa31).

4. Настройка частоты сбора данных

По умолчанию sysstat собирает данные раз в 10 минут, но это можно изменить. Для этого редактируй /etc/cron.d/sysstat (или /etc/cron.daily/sysstat — зависит от дистрибутива).

Например, чтобы собирать данные каждую минуту (рекомендуется для активных серверов):

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

Или для RHEL/CentOS:

* * * * * root /usr/lib64/sa/sa1 1 1

Внимание: слишком частый сбор может слегка нагрузить систему, но для большинства серверов 1 минута — это оптимально.

5. Хранение данных: сколько и где?

По умолчанию sysstat хранит данные за 7 дней. Если нужно больше — редактируй /etc/sysstat/sysstat:

# Количество дней хранения
HISTORY=28

После изменения не забудь перезапустить сервис!

Примеры и кейсы: когда sar спасает (и когда нет)

Ключевые команды sar: шпаргалка

• sar — статистика по всем основным метрикам (CPU, память, диски и пр.)
• sar -u — только CPU
• sar -r — только память
• sar -S — swap
• sar -d — диски
• sar -n DEV — сеть (по интерфейсам)
• sar -n EDEV — ошибки по сети
• sar -q — load average
• sar -f /var/log/sa/saXX — анализ файла за конкретный день
• sar -s HH:MM:SS -e HH:MM:SS — за определённый интервал времени

Ошибки новичков и мифы о sar

• Миф: sar сильно грузит систему.
  Факт: На большинстве серверов overhead не превышает 1-2% CPU и несколько мегабайт диска в сутки. Для VPS — вообще незаметно.
• Миф: sar показывает, какой процесс грузил систему.
  Факт: sar работает только с агрегированными метриками (CPU, память и т.д.), а не с конкретными процессами. Для этого нужны psacct, atop или auditd.
• Ошибка: думают, что sar “всё хранит навсегда”.
  Реальность: По умолчанию хранит 7 дней, но это легко меняется.
• Ошибка: не настраивают частоту сбора — а потом удивляются, что “ничего не видно”.
  Совет: Ставь 1 минуту для активных серверов.
• Ошибка: не делают резервные копии статистики перед переустановкой/апгрейдом.
  Совет: Если важна история — копируй /var/log/sa/ заранее.

Похожие решения и сравнение с sar

Статистика: насколько популярен sar?

• Входит в стандартные репозитории всех популярных дистрибутивов Linux.
• Используется на тысячах серверов в дата-центрах, в том числе для расследования инцидентов.
• Почти всегда установлен на облачных VPS и выделенных серверах.

Интересные факты и нестандартные способы использования sar

• Можно экспортировать данные sar в CSV или XML для анализа в Excel или BI-системах:

# Экспорт в CSV
sar -u -f /var/log/sa/sa15 -s 00:00:00 -e 23:59:59 -o output.csv

• Можно писать свои скрипты, которые автоматически анализируют отчёты sar и присылают алерты в Telegram/Slack, если, например, CPU был выше 90% больше 5 минут подряд.
• Любишь графики? Есть проекты ksar (Java-программа для построения графиков из sar) и ksar на GitHub.
• Можно собирать статистику sar с десятков серверов в одну точку, чтобы анализировать “что творится в облаке” — идеально для тех, у кого много VPS или выделенных серверов.
• В Docker-контейнерах sar тоже работает, если есть доступ к /proc и /sys (например, с флагом --privileged).

sar для автоматизации и скриптов: новые горизонты

Поскольку sar — это командная строка и стандартные текстовые файлы, его удобно использовать в автоматизации:

• Пишешь скрипт, который каждое утро анализирует отчёты за прошедшие сутки и присылает тебе отчёт на почту/в Telegram.
• Автоматически ищешь “аномалии” (скачки CPU, памяти, IO) и запускаешь дополнительные сборы логов.
• Интегрируешь с системами алертов: если что-то не так — сразу пуш в Slack/Discord.
• Можно “отдавать” статистику sar в Prometheus через sar-exporter — и строить красивые графики в Grafana.

Выводы и рекомендации: почему, как и где использовать sar

• sar — это must-have для любого, кто обслуживает серверы. Особенно если нужен быстрый, лёгкий и надёжный мониторинг “на вырост”.
• Он почти не грузит систему, легко настраивается и позволяет быстро найти “узкие места” — будь то VPS, выделенный сервер или облачный инстанс.
• Рекомендую ставить sysstat сразу после развёртывания сервера — и не забывать настраивать частоту сбора и срок хранения.
• Если нужно больше детализации — смотри в сторону atop или Prometheus, но для 90% задач sar более чем достаточно.
• Для автоматизации — используй скрипты анализа, интеграции с алертами и графиками.
• Если нужен сервер для экспериментов — смотри VPS или выделенные серверы.

Официальные ссылки:

• https://github.com/sysstat/sysstat — исходники и документация
• https://man7.org/linux/man-pages/man1/sar.1.html — man-страница sar
• https://github.com/vlsi/ksar — графики для sar
• https://github.com/tycho/sar-exporter — экспорт sar в Prometheus

В общем, если хочешь быть готовым к любым “форс-мажорам” на сервере — ставь sar и спи спокойно. А если вдруг что — всегда сможешь доказать, что “это не ты всё сломал” 🙂