Перейти к содержимому 
sar sysstat предоставляет мне исторические показатели серверов Linux, с помощью которых я могу четко отслеживать динамику нагрузки, узкие места и отклонения в поведении системы во времени. Таким образом, я анализирую загрузку ЦП, ОЗУ, ввода-вывода и сети в ретроспективе и выявляю повторяющиеся пики, которые простой инструмент для работы в режиме реального времени может легко упустить.
Центральные пункты
Ниже я кратко и четко изложу основные тезисы.
- История Вместо разового измерения: регулярная регистрация позволяет выявить характер нагрузки.
- Комбинация из сбора и анализа данных: sysstat собирает данные, sar обрабатывает их.
- Ширина по таким показателям: ЦП, ОЗУ, своп, дисковый ввод-вывод, сеть и др.
- Диагноз по причинам: целенаправленно настраивать временные интервалы и сравнивать их.
- Планирование с учетом тенденций: реалистичное определение мощностей.
Какую роль играют команды sar и sysstat в повседневной работе?
Я использую сар в качестве System Activity Reporter, который делает доступными для чтения данные, сохраняемые sysstat. sysstat регулярно собирает показатели ЦП, памяти, ввода-вывода и сети, а я с помощью sar целенаправленно получаю отчеты за определенные периоды времени. Благодаря этому я могу без догадок выявлять периоды повышенной нагрузки, связанные с резервным копированием, заданиями cron или пиками трафика. В отличие от Инструменты в режиме реального времени В отличие от top или htop я оцениваю не мгновенное состояние, а учитываю динамику во времени. Такой подход позволяет избежать ошибочных выводов, поскольку он отделяет причину от следствия и дает мне достоверные указания.
Установка и активация в популярных дистрибутивах
Я устанавливаю sysstat С помощью менеджера пакетов включите мониторинг и проверьте таймеры systemd. В Debian/Ubuntu обычно достаточно apt install sysstat и заглянуть в /etc/default/sysstatпосле systemctl enable --now sysstat. На RHEL/CentOS/Oracle Linux я использую dnf install sysstat и управляй таймерами с помощью systemctl. После этого файлы дневных данных обычно сохраняются в папке /var/log/sa/ с такими названиями, как sa10 на 10-е число месяца. Я проверяю правильность ввода данных с помощью сар без параметров или с sar -u 1 3 для краткой проверки в экстренном порядке.
Объяснение основных команд sar
В качестве процессора я использую sar -u и, при необходимости, на каждое ядро sar -u -P ALLдля того чтобы Советы невозможно не заметить. К вопросам хранения данных и кэширования я отношусь с sar -r и свопинг с помощью sar -S. Активность пластин я считываю с помощью sar -d, сеть с sar -n DEV,ETCP,TCP,UDP. Исторические файлы я открываю с помощью sar -f /var/log/sa/sa10 и ограничить временной интервал с помощью -s ЧЧ:ММ -e ЧЧ:ММ . Для детального анализа времени ожидания я дополняю sar следующим образом: Анализ ожиданий ввода-вывода, потому что так я могу лучше оценить очереди и пропускную способность, и Узкие места четко определить.
Как правильно интерпретировать показания: процессор, память, ввод-вывод, сеть
Я обращаю внимание на несколько ключевых показателей, которые позволяют мне быстро составить достоверную картину и которые я сравниваю в динамике. CPU-Холостой ход Значение, близкое к 0, и высокий показатель %iowait указывают на наличие очередей на диске. Высокое значение %steal указывает на нехватку ресурсов ЦП при виртуализации. Что касается оперативной памяти, я обращаю внимание на количество свободных страниц памяти, поведение кэша страниц и операции Swap-In/Out. В сети показатели ошибок пакетов, пропусков и повторных передач помогают выявить пределы пропускной способности или сбои.
| Метрики | переключатель sar | Необычные значения | неотложная мера |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle — очень низкий, %iowait — высокий | Проверка ввода-вывода, распределение потоков, проверка потребностей в ресурсах ЦП |
| Память | sar -r | мало свободного места, сильное сокращение объема кэша страниц | Оптимизация служб, расширение объёма оперативной памяти, оценка эффективности кэширования |
| Обмен | sar -S | частые замены игроков | Разгрузить оперативную память, настроить ограничения |
| Дисковый ввод/вывод | sar -d | высокие значения await/svctm, очередь растет | Проверить профиль ввода-вывода, настроить многоуровневое хранение данных или окна пакетной обработки |
| Сеть | sar -n DEV,ETCP | Пропуски, ошибки, повторные передачи | Тестирование MTU/разгрузки, анализ пропускной способности и задержки |
Анализ исторических данных и временных интервалов
Я почти всегда работаю с Временные окна, например sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 для ночных смен. Так я сравниваю одинаковые временные интервалы в разные дни и выявляю тенденции, а не единичные случаи. Для автоматического анализа я сохраняю данные с sadf -d в формате CSV и загружаю их в отдельную панель мониторинга. При необычных пиках я анализирую соседние интервалы, чтобы исключить побочные эффекты. Я считаю этот метод эффективным, поскольку он позволяет мне быстро получать полезную информацию без длительной предварительной подготовки.
Анализ тенденций и планирование производственных мощностей
Я использую заархивированные значения для Прогнозы и рассчитываю ресурсы на основе реальных данных, а не по интуиции. Если загрузка ЦП растет с каждой неделей, я планирую добавление ядер или резервов тактовой частоты. Если потребность в оперативной памяти растёт из-за кэшей, я сравниваю выгоду и возможность расширения ОЗУ. Если в канале ввода-вывода наблюдается увеличение времени ожидания, я принимаю решение о переходе на более быстрое хранилище или о развязке окон пакетной обработки. Для визуализации я альтернативно подключаю данные к Grafana и Prometheus и объединяй тренды SAR с показателями из экспортеров.
Практический пример: веб-сервер с пиковыми нагрузками
Я опишу ситуацию, в которой сайты на WordPress каждый вечер отвечают с задержкой и Пользователи Сообщать об абортах. С помощью sar -u -s 18:00:00 -e 20:00:00 и sar -d Я замечаю одновременные пики нагрузки на ввод-вывод во время резервного копирования. Параллельно с этим sar -n DEV рост пропускной способности сети, что дополняет картину нагрузки. Проверка на следующий день без резервного копирования подтверждает эту закономерность. Я переношу задание, оптимизирую запросы к базе данных и очищаю кэши, в результате чего исчезают вечерние пики, а время отклика вновь становится стабильным.
Рекомендации по ведению учета данных, их ротации и хранению
Я проверяю Хранение на сайте /etc/sysconfig/sysstat или /etc/default/sysstat и настраиваю срок хранения в зависимости от потребностей. Для критически важных хостов я сохраняю данные в течение 30–90 дней, чтобы выявить сезонные тенденции. Размер файлов остается приемлемым, пока интервалы остаются разумными и не используется чрезмерно частая синхронизация с точностью до секунды. Я перемещаю старые архивы в центральный каталог или помещаю их в простое хранилище длительного хранения. Таким образом я обеспечиваю доступность данных, не нагружая систему и не замедляя анализ.
Интеграция со стеками мониторинга и журналами
Я задаю sar как Необработанные данные-поставщика и объединяю его с централизованным мониторингом, анализом логов и системой оповещения. APM-стек или стек логов предоставляет мне события, а sar сортирует показатели инфраструктуры по времени. Для хостов с особенно высоким уровнем активности я дополнительно использую pidstat и iostat, чтобы сопоставить процессы и пути ввода-вывода. Кроме того, мне помогает Учет производственных затрат, чтобы точно выявить процессы, потребляющие много ресурсов. Такое сочетание данных о событиях и метриках позволяет избежать работы «вслепую» и значительно сокращает время на поиск ошибок.
Точная настройка конфигурации: интервалы, sa1/sa2 и таймер
Я положил Интервалы сбора данных таким образом, чтобы они соответствовали динамике системы. В качестве стандарта рекомендуется использовать минутный интервал, хотя для хостов с высокой волатильностью целесообразно использовать интервал 10–30 секунд. Сбор данных осуществляется sa1 (частые выборочные проверки), ежедневный отчет sa2 (Отчеты за день). В systemd я проверяю соответствующие таймеры или службы и настраиваю их частоту. В Debian/Ubuntu я часто явно запускаю сбор данных с помощью команды ENABLED="true" на сайте /etc/default/sysstat. Я фиксирую интервалы для каждой среды, чтобы впоследствии сравнения были точными и никто не сделал ошибочных выводов, сравнивая 5-секундные выборки с 1-минутными данными.
Обзор расширенных параметров sar
Помимо стандартных кнопок, мне помогают дополнительные переключатели для Обзор: sar -b показывает совокупную пропускную способность блочного ввода-вывода, sar -B поведение ядра при страничной организации памяти и sar -W Подробная информация об операциях своп. С помощью sar -q Я вижу очередь Runqueue (процессы, ожидающие доступа к ЦП) и динамику загрузки. sar -H предоставляет данные Hugepage, если это необходимо. Для дисков я использую, при необходимости, sar -d -p, чтобы рассматривать разделы по отдельности. Я осторожно подхожу к svctm: В современных ядрах это значение иногда бывает недостоверным или равным 0; я предпочитаю считать, что ожидайте (задержка от начала до конца) и avgqu-sz/aqu-sz (размер очереди). А если мне нужно быстро составить общее представление, то sar -A общий обзор, который я затем сужу.
Как правильно оценивать виртуальные машины и контейнеры
На сайте Виртуализация Я уделяю особое внимание показателю %steal: высокие значения Steal означают, что гипервизор отнимает время процессора у виртуальной машины. Это легко приводит к неверным выводам, если я анализирую только показатель %idle. Поэтому я сопоставляю загрузку ЦП, показатель Steal и Runqueue (sar -q) совместно. В контейнерных средах я разделяю представление хоста и рабочей нагрузки: sar отслеживает хост, а не отдельные контейнеры. Если мне нужны подробные данные по каждому сервису, я дополняю с помощью pidstat (на каждый процесс) и учитываю ограничения cgroups. Кроме того, я проверяю масштабирование частоты ЦП и состояния питания (смену тактовой частоты), поскольку они могут вызывать кратковременные задержки, которые без контекста выглядят как нехватка ресурсов ЦП.
Временные параметры: часовые пояса, летнее время и достоверная корреляция
Я обращаю внимание на постоянная временная шкала, чтобы сравнения давали верные результаты. По умолчанию sar сохраняет данные в локальном времени; в кластерах целесообразно использовать единую временную зону (часто UTC). В период перехода на летнее время я проверяю наличие дубликатов или пропущенных временных интервалов и, при необходимости, использую вывод команды sadf с временными метками в формате ISO. Для сопоставления с журналами или событиями APM я выравниваю часовые пояса, чтобы точно соотнести пики в метриках с событиями (развертываниями, резервными копиями, заданиями Cron). Чёткие временные ориентиры значительно сокращают количество недоразумений при анализе инцидентов.
Автоматизация и экспорт с помощью sadf
Для отчетов и информационных панелей я экспортирую данные с помощью sadf. В повседневной жизни я использую sadf -d (CSV) для простых анализов, либо sadf -j (JSON) для гибких конвейеров. Типичный экспорт выглядит следующим образом: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. Таким образом я создаю файл с показателями загрузки ЦП, ОЗУ, блочного ввода-вывода и сети за вечерний период. В скриптах я использую эти данные для автоматического сравнения показателей по дням недели, вычисления медианы и 95-го процентиля, а также выделения аномальных значений. Я сознательно ограничиваю набор показателей, чтобы сохранить читаемость данных и избежать ложных срабатываний.
Практический пример: нагрузка на сервер базы данных из-за кэша страниц
Хост MySQL сообщает о периодических задержках при выполнении запросов. sar -r показывает снижение объёма кэша страниц в вечернее время, sar -S периодические замены. Параллельно с этим растет sar -d die ожидайте-время, и sar -b указывает на повышенный поток записей. Корреляция с ротацией журналов и заданием ETL объясняет эту закономерность: большие последовательные волны записей вытесняют содержимое кэша и вынуждают операции чтения из базы данных переходить в режим ввода-вывода. Я распределяю задания, умеренно увеличиваю объем оперативной памяти и целенаправленно увеличиваю размер буфера базы данных. В результате значения await и swap остаются стабильными, задержки снижаются, а страничный кэш надежно удерживает «горячие наборы» в памяти.
Эксплуатационные аспекты: накладные расходы, списки оборудования и фильтры
Я держу Накладные небольшой, выбирая относительно представительные выборки. Sysstat в первую очередь считывает данные из /proc и записывает в двоичном формате; при интервалах в минуты я практически не ощущаю нагрузки. На хостах с очень большим количеством устройств или кратковременными блочными устройствами (например, при создании снимков) я целенаправленно фильтрую вывод и анализирую только релевантные пути. Для dm-crypt, MD-RAID или многопутевых устройств я проверяю как логическое, так и — где это возможно — базовое устройство, чтобы правильно определить место возникновения узких мест. При этом я документирую имена устройств, чтобы последующие сравнения не заканчивались неудачей из-за переименованных путей.
Методика: базовые показатели и дни сравнения
Я определяю для каждого хоста одну Базовый уровень по временным интервалам дня (например, 01:00–05:00 — пакетная обработка, 09:00–18:00 — офисный режим, 18:00–22:00 — пиковый период). Для каждого интервала я фиксирую типичные медианные значения и допустимые процентили (например, CPU-%idle, ожидайте, avgqu-sz, ретрансляции). При отклонениях я сначала ищу новые задания, развертывания или модели трафика — и только после этого задумываюсь о расширении мощностей. Такая дисциплинированная последовательность действий позволяет избежать поспешных решений: зачастую небольшое изменение плана или корректировка лимитов дают больший эффект, чем дорогостоящее увеличение аппаратных ресурсов. sar предоставляет мне для этого надежную фактологическую базу, охватывающую недели и месяцы.
Пределы и полезные дополнения
Я не считаю sar заменой для Оповещение, поскольку по умолчанию он не отслеживает пороговые значения и не рассылает уведомления. Оповещения в режиме реального времени должны обрабатываться в специализированных системах, которые поддерживают правила, эскалацию и рабочие процессы команд. Что касается глубоких метрик приложений, баз данных или JVM, то я использую для их сбора экспортеры и трассировку. sar показывает себя с лучшей стороны, когда мне нужно сравнить системные ресурсы за разные периоды и проанализировать узкие места в работе. В целом я использую его целенаправленно там, где требуются быстрые и воспроизводимые ответы на вопросы, касающиеся инфраструктуры.
Краткое резюме
Я использую сар и sysstat, чтобы на основе измеренных данных составить наглядную картину нагрузки на сервер. Сочетание регулярного сбора данных и целенаправленного анализа прошлых событий позволяет выявлять причины, а не гадать о симптомах. С помощью нескольких команд я выявляю проблемы с ЦП, памятью, вводом-выводом и сетью и фиксирую их во времени. На этой основе я принимаю обоснованные решения по вопросам пропускной способности и выявляю неэффективные процедуры, такие как резервное копирование в неподходящее время. Те, кто отвечает за серверы Linux, благодаря этому методу получают надёжную ориентацию и экономят время на анализе, планировании и эксплуатации.
