Stats.sh: Как я победил рутину и перестал набирать одни и те же команды

Знаете это чувство, когда ты делаешь одно и то же действие в сотый, тысячный раз? Со мной это случилось в прошлом месяце. Я получал доступ к свежеарендованному выделенному серверу и начинал набивать одну и ту же мантру: dmesg | tail, smartctl -A /dev/sda, df -h, cat /proc/mdstat, free -h, lscpu, vmstat 1 5, ps auxfww. Пальцы сами выбивали команды, а я уже мысленно был в другом месте.

Я инженер. Мне лень. А лень, как говорится, двигатель прогресса. Поэтому я сел и за вечер набросал скрипт, который делает всю эту грязную работу за меня. Встречайте: stats.sh!

Что под капотом? Рентген твоего сервера

Скрипт не лечит и не чинит. Он просто проходит по всем болевым точкам сервера и выгружает их состояние в текстовый файл. Вот его маршрут и заложенная инженерная логика:

ОС и ядро: Базовая инспекция через uname -a и /etc/os-release, чтобы понимать, с какой сборкой имею дело, плюс аптайм и load average.
Процессор: Выдергивает через lscpu только важное: модель, частота, количество ядер и потоков.
Оперативная память: Классический free -h: сколько занято, сколько свободно, сколько в кэше.
Дисковое пространство: Команда df -h с фильтрацией мусора через флаги -x tmpfs -x devtmpfs. Это отсекает рамдиски и виртуальные точки монтирования ядра, оставляя в выводе только реальные разделы.
I/O Wait (колонка wa): Мгновенный срез нагрузки. Обычный запуск vmstat отдает средние значения с момента аптайма. Конструкция vmstat 1 2 | tail -n 2 заставляет утилиту сделать два замера с интервалом в 1 секунду: первая строка отбрасывается, а вторая фиксирует процент времени, в течение которого CPU тупо ждал ответа от дисков.
Состояние RAID: Прямой парсинг виртуального файла ядра /proc/mdstat. Самый надежный способ мгновенно увидеть статус синхронизации софтового зеркала.
SMART жёстких дисков: Прямой опрос smartctl -A для /dev/sda и /dev/sdb. Запрашиваются низкоуровневые таблицы атрибутов здоровья без посредников.
Блочные устройства: Чистая структура дисков, разделов и их файловых систем через lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT для проверки метаданных разметки.
Сетевые порты: Через ss -tulpn собираются активные сокеты. Жесткий grep фильтрует порты, на которых висят наши медиа-сервисы и боты (python, liquidsoap, icecast). Это контроль сетевой гигиены периметра и поиск левых процессов.
Топ процессов: Команда ps с??кой по CPU (--sort=-pcpu) забирает первые 15 позиций, чтобы сразу видеть, кто утилизирует ресурсы прямо сейчас.
Логи ядра (dmesg): Сканирование кольцевого буфера ядра с флагом -T для человекочитаемого формата времени. Фильтр жестко выдергивает критические «красные флаги»: oom-killer (когда процессу не хватило ОЗУ и ядро его прибило), ошибки ввода-вывода или сбои накопителей.

Всё это падает в файл с именем вроде sys_report_2026-06-12_14-30-01.txt в папку ./logs. Никакой базы данных, никакого JSON. Просто плоский текст. Можно читать прямо в терминале через cat, можно скачать и спокойно анализировать на нормальном компьютере.

Как это выглядит на живом сервере. Разбор на примере Phoenix901

Запускаю скрипт на своём сервере. Том самом PROD, где крутятся боты, радио, почта на Mailcow и этот блог. Вот ключевой дамп из полученного отчёта:

--- OS & KERNEL ---
Debian GNU/Linux 13 (trixie), ядро 6.12.90
uptime: 12 days, load average: 2.15, 2.28, 2.33

--- CPU INFO ---
Intel Xeon E3-1231 v3 @ 3.40GHz, 8 потоков

--- MEMORY STATUS ---
15Gi total, 6.0Gi used, 9.6Gi available

--- DISK SPACE ---
RAID1, 7.3T, занято 8%

--- DISK I/O WAIT ---
wa: 0-1%

--- RAID STATUS ---
md2 : active raid1 sda4[0] sdb4[1] [UU]

--- SMART DATA: /dev/sda ---
5 Reallocated_Sector_Ct: 0
9 Power_On_Hours: 49301
187 Reported_Uncorrect: 0
197 Current_Pending_Sector: 0
199 UDMA_CRC_Error_Count: 0
Temperature_Celsius: 28

--- TOP PROCESSES ---
liquidsoap (радио): 4 инстанса по ~15-20% CPU
TTMediaBot: ~6-10% CPU

--- CRITICAL KERNEL LOGS ---
(пусто, ошибок нет)

Инженерный анализ параметров:

Железо старое (дискам по 5.5 лет активной наработки — Power_On_Hours: 49301), но работает стабильно. Критические RAW-значения SMART (5, 187, 197, 199) строго по нулям. Сектора не плывут, ошибок позиционирования нет, кабели и порты в порядке. Температура 28°C — норма.
Значение wa: 0-1% в vmstat означает, что процессор не ждет ответа от накопителей, дисковая подсистема полностью справляется с нагрузкой.
RAID в статусе [UU] — оба диска живы, зеркало софтового массива mdadm целое.
Нагрузка на CPU высокая из-за постоянного стриминга радио (liquidsoap), но для этого 8-поточного Xeon значения LA в районе 2.2 — легитимная рабочая норма.
Логи ядра чистые — ни единого намека на аппаратные сбои, проблемы файловой системы или убйиство процессов со стороны OOM-killer. Сервер стабилен.

Как читать отчёт: Пороговые значения и физика

Когда автоматизация выплевывает лог, смотреть нужно строго на цифры физических показателей. Вот жесткие критерии оценки:

Параметр	Норма	Внимание	Критический сбой
Атрибуты SMART 5 и 197	0	Рост переназначений (ID 5 > 0)	Появились бэды (ID 197 > 0) — диск блокируется при чтении, под замену
Атрибут SMART 199	0	Счетчик выше нуля	Рост ошибок интерфейса CRC — меняй шлейф, кабель или SATA-порт
I/O Wait (wa)	0-5%	5-15% (HDD под плотной нагрузкой)	>30% — дисковая подсистема заблокирована, сервер встал колом
Статус RAID	`[UU]`	—	`[_U]` или `[U_]` — массив деградировал, один из накопителей отвалился
Логи dmesg	Чисто	—	`I/O error` (отказ диска), `OOM-killer` (ядро прибило процесс из-за нехватки ОЗУ)

Где скрипт не работает

NVMe-накопители. Логика опроса SMART настроена на классические диски /dev/sda и /dev/sdb. Если на сервере стоят быстрые NVMe (/dev/nvme0n1) или дисков просто больше двух — пути нужно прописывать в коде руками. Точные имена всегда можно подсмотреть в секции блочных устройств, которую скрипт выводит через lsblk.
Аппаратные RAID-контроллеры. Скрипт видит только софтовый стек через mdadm. Железные контроллеры вроде LSI MegaRAID или HP Smart Array прячут физические диски за своим чипом. Чтобы пробросить их метрики, придется внедрять утилиты вендора (вроде storcli или hpssacli).
Виртуализация (VDS). Запустить скрипт на виртуалке можно, но это бесполезно. Вместо реальных физических параметров железа и RAW-значений SMART вы получите пустую эмулированную картинку и заглушки от гипервизора. Только честное железо (Bare Metal).
Требует root. Утилиты контроля вроде smartctl и чтение кольцевого буфера dmesg требуют повышенных привилегий в системе. Без прав суперпользователя отчет выйдет неполным.

Инструкция по запуску

chmod +x stats.sh
sudo ./stats.sh

Скрипт создаст папку ./logs в текущей директории и положит туда готовый текстовый файл с отчётом.

Автоматизация через cron

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

# Ежедневный сбор снимка системы в 6 утра
0 6 * * * /root/stats.sh

# Еженедельно по понедельникам в 8:00: удаление логов старше 30 дней и запуск свежего отчета
0 8 * * 1 find /root/logs -name "*.txt" -mtime +30 -delete && /root/stats.sh

?? Скачать stats.sh

Заключение

Скрипт — это просто рентгеновский снимок. Он не правит конфиги самостоятельно и не поднимает упавшие службы. Его задача — избавить администратора от ручного набора команд, мгновенно выдав чистый снимок физики и логов сервера здесь и сейчас. А принимать решения и устранять аварии всё равно придётся руками.

Скачивайте, гоняйте на своих дедиках, проверяйте RAW-параметры. Если wa зашкаливает, RAID развалился или поползли пендинги — вы знаете, что делать. Если всё чисто — сервер здоров, можно спать спокойно.

Код полностью открыт, адаптируйте под себя, добавляйте датчики температур или диски NVMe. База дана, дальше сами.

Работаем дальше. Верим только логам.

👁️ 14