Разбор ночного всплеска нагрузки задним числом возможен, если данные собирались заранее

Сервер ночью на полчаса встал колом, утром жалобы, а к моменту разбора всё давно пришло в норму. Открыть монитор процессов теперь бесполезно - он показывает настоящий момент, а не то, что творилось в три часа ночи. Живые инструменты диагностики хороши, когда проблема перед глазами, и совершенно бессильны, когда она уже миновала. Чтобы расследовать прошлое, нужны данные, записанные в момент происшествия, а для этого их надо было собирать заранее, ещё до того, как что-то случилось.

Ровно эту задачу решает пакет учёта системной активности и его главная утилита отчётов. Фоновый сборщик через равные промежутки записывает показатели системы в журналы, а утилита отчётов потом достаёт из этих журналов картину за любой прошлый момент. Поставил пакет однажды, и система молча копит историю своей нагрузки, чтобы наутро можно было заглянуть в любой час прошедших суток. Разберём, как устроен сбор, как настроить частоту и срок хранения, и как методично разобрать всплеск нагрузки задним числом.

Архитектура сбора держится на фоновом сборщике и заданиях по расписанию

Пакет учёта активности устроен из нескольких частей, и понимание их ролей снимает большую часть путаницы. Низкоуровневый сборщик опрашивает ядро и пишет показатели в двоичный журнал. Поверх него работает короткий скрипт-обёртка, который запускается по расписанию и вызывает сборщик для снятия очередного замера. Второй скрипт раз в сутки сводит накопленное за день в суточный отчёт. А утилита отчётов читает накопленные журналы и показывает их человеку.

Сбор запускается заданиями планировщика, которые пакет обычно прописывает сам при установке. Типичная настройка снимает замер каждые десять минут и подводит суточный итог поздно вечером.

# в файле расписания пакета учёта активности
*/10 * * * * root /usr/lib/sa/sa1 1 1
53 23 * * * root /usr/lib/sa/sa2 -A

Первое задание каждые десять минут вызывает скрипт-обёртку, который снимает один замер. Два числа после него означают один замер с интервалом в секунду - то есть мгновенный снимок раз в десять минут. Второе задание поздним вечером собирает суточную сводку и заодно убирает устаревшие журналы.

Двоичные журналы складываются в системный каталог под именами, привязанными к числу месяца. Журнал за двадцатое число месяца ляжет в файл с соответствующим номером в имени. Это двоичные файлы, и текстовым редактором их не прочитать - их читает только утилита отчётов.

Включение сбора и важная оговорка для части дистрибутивов

Установка пакета сама по себе не всегда означает, что сбор пошёл. В ряде дистрибутивов после установки сбор по умолчанию выключен, и его надо включить отдельным переключателем в файле настроек пакета. Это распространённая причина, по которой история оказывается пуста именно тогда, когда понадобилась.

# в файле настроек пакета, перевести в значение истины
ENABLED="true"

Без этого переключателя задания по расписанию могут стоять на месте, а журналы - не наполняться. Поэтому сразу после установки стоит убедиться, что сбор действительно идёт: проверить состояние службы пакета и заглянуть в каталог журналов - там должны появляться файлы.

systemctl status sysstat       # идёт ли сбор
ls -l /var/log/sysstat/        # появляются ли журналы

Каталог журналов в разных дистрибутивах разный - в одних он один, в других другой, и при разборе важно знать, где именно лежат файлы на конкретной системе. Утилита отчётов с указанием версии заодно подтвердит, что пакет установлен и работает.

Частота замеров и срок хранения это компромисс

Здесь кроется главное решение при настройке: как часто снимать замеры и как долго их хранить. Стандартные десять минут между замерами - компромисс. Такая частота ловит общие тренды нагрузки, но способна пропустить короткий резкий всплеск, уложившийся между двумя замерами. Если важно ловить кратковременные пики, интервал уменьшают, поменяв частоту в задании планировщика.

# замер каждые две минуты вместо десяти
*/2 * * * * root /usr/lib/sa/sa1 1 1

Расплата за частые замеры - больший объём журналов и чуть большая нагрузка от самого сбора. Для большинства систем десяти минут достаточно, чтобы увидеть, в какой час пришла беда, а для прицельной охоты за короткими пиками частоту повышают сознательно, понимая цену.

Срок хранения по умолчанию обычно невелик - около недели или чуть больше. Этого мало, если разбор происходит спустя время или нужно сравнить нагрузку с прошлым месяцем. Срок задаётся отдельным параметром в настройках пакета, и его увеличивают, чтобы история жила дольше.

# хранить историю 28 дней вместо недели
HISTORY=28

Стоит знать: когда срок хранения переваливает за месяц, журналы начинают раскладываться по подкаталогам помесячно, и при разборе старых данных это учитывают. Срок хранения - это запас глубины, в которую можно заглянуть, и его стоит выставить с оглядкой на то, как быстро в среднем доходят руки до разбора инцидентов.

Чтение прошлого через указание журнала и временного окна

Вот ради чего всё затевалось. Утилита отчётов умеет читать не только живые данные, но и любой прошлый журнал - для этого ей указывают файл журнала за нужный день. А чтобы сузить картину до окна происшествия, задают время начала и конца.

# нагрузка на процессор за вчерашний день
sar -u -f /var/log/sysstat/sa$(date -d yesterday +%d)

# сузить до окна ночного всплеска
sar -u -f /var/log/sysstat/sa15 -s 02:00:00 -e 04:00:00

Указание файла журнала за число месяца открывает данные того дня, а параметры начала и конца вырезают нужный промежуток. Так можно вернуться ровно в тот двухчасовой отрезок ночи, когда сервер встал, и посмотреть, что показывали датчики именно тогда. Это и есть разбор задним числом - инструмент показывает прошлое так же, как живые инструменты показывают настоящее.

Каждая запись в отчёте - это усреднение за интервал между замерами, и в конце утилита выводит средние за весь период. При разборе всплеска смотрят не на средние, а на конкретные записи в окне происшествия, где видно отклонение от обычного фона.

Методичный разбор всплеска идёт по подсистемам

Сам разбор ведут послойно, проверяя подсистемы одну за другой в окне происшествия. У утилиты для каждой подсистемы свой ключ. Нагрузку на процессор с разбивкой по видам времени показывает один ключ, память - другой, дисковые операции - третий, очередь задач и среднюю нагрузку - четвёртый.

# процессор в окне инцидента
sar -u -f /var/log/sysstat/sa15 -s 02:00:00 -e 04:00:00
# давление на память в том же окне
sar -r -f /var/log/sysstat/sa15 -s 02:00:00 -e 04:00:00
# дисковые операции
sar -b -f /var/log/sysstat/sa15 -s 02:00:00 -e 04:00:00
# очередь задач и средняя нагрузка
sar -q -f /var/log/sysstat/sa15 -s 02:00:00 -e 04:00:00

Логика разбора идёт от симптома к причине. Сперва смотрят процессор: если в окне всплеска велика доля системного времени или времени ожидания - это уводит к ядру или к диску. Затем проверяют память: ненулевой обмен с подкачкой в момент происшествия выдаёт, что в тот час система задыхалась от нехватки оперативки и вытесняла данные на диск. Дисковые показатели подтверждают или опровергают перегрузку накопителя. Очередь задач показывает, сколько процессов ждали процессора, объясняя рост средней нагрузки.

Так, переходя от подсистемы к подсистеме в одном и том же временном окне, складывают картину происшествия: что именно было перегружено в тот момент, когда сервер встал. Связать всплеск средней нагрузки с одновременным ростом подкачки - значит найти причину, и всё это уже после того, как инцидент миновал.

Графики и выгрузка для наглядности и интеграции

Числовые таблицы хороши для точечного разбора, но тренд нагляднее на графике. Накопленные данные можно превратить в графики сторонними просмотрщиками, рисующими историю нагрузки кривыми, - на них пик виден глазом сразу, без вчитывания в столбцы цифр.

Для передачи данных в другие инструменты служит отдельная утилита выгрузки из того же пакета. Она достаёт записанные показатели и выдаёт их в переносимых форматах - значения через запятую или разметку, - которые легко скормить системе построения графиков или анализа.

# выгрузка данных за день в формат значений через запятую
sadf -d /var/log/sysstat/sa15 -- -u

Это пригождается, когда историю нагрузки хотят влить в общую систему мониторинга или построить по ней собственные графики. Сам пакет учёта активности при этом остаётся источником сырых данных, а их представление отдают внешним средствам.

Что складывается в практику

Картина выстраивается ясно. Пакет учёта активности молча копит историю нагрузки: фоновый сборщик по расписанию пишет замеры в двоичные журналы, а утилита отчётов потом читает их за любой прошлый момент. Это превращает невозможный разбор миновавшего инцидента в обычную работу, но при одном условии - сбор должен был идти заранее.

Поэтому ключевые шаги настройки делают загодя. Убеждаются, что сбор включён, потому что в части дистрибутивов он по умолчанию выключен, и пустая история - частый сюрприз. Выбирают частоту замеров как компромисс между детальностью и объёмом, понимая, что стандартные десять минут пропустят короткий пик. Задают срок хранения с запасом под то, как нескоро доходят руки до разбора. А сам разбор ведут послойно по подсистемам в окне происшествия, идя от симптома к причине.

Главная мысль: расследовать прошлое можно, только если данные собирались до того, как оно случилось. Живые мониторы показывают лишь настоящее, а история нагрузки отвечает на вопрос, что творилось ночью, когда сервер встал. Стоит однажды поставить пакет, включить сбор, выставить частоту и срок хранения под свои нужды, и любой ночной всплеск перестаёт быть неразрешимой загадкой - его можно методично разобрать наутро, вернувшись инструментом отчётов ровно в тот час, когда всё пошло не так.