Linux Ready | DevOps

👩‍💻 Сравниваем загрузку системы за разные дни!

Иногда нужно быстро понять, стал ли сервер жить тяжелее по сравнению со вчера или прошлой неделей, но поднимать Prometheus лень. Достаточно логировать loadavg в файл и один раз написать скрипт сравнения.

В этом посте:

• Логируем нагрузку системы в простой текстовый файл;

• Считаем среднюю нагрузку за выбранный день через awk;

• Функция, которая сравнивает два дня между собой;

• Как вывести среднюю нагрузку за вчера и сегодня.

Подойдёт тем, кто держит несколько VPS и хочет видеть динамику нагрузки без тяжёлых систем мониторинга.

🚪 Linux Ready | #задача

Мини-скрипт мониторинга файла с логом и простым alert (webhook)

Отслеживаем изменения файла/папки и логируем с таймстампом, при установленном ALERT_WEBHOOK отправляем короткий POST. Требуется inotifywait (inotify-tools):

#!/usr/bin/env bash
WATCH="$1"; LOG="${2:-/var/log/filewatch.log}"
inotifywait -m -e modify,create,delete,move --format '%T %w %e %f' --timefmt '%F %T' "$WATCH" |
while read -r ts path ev file; do
  echo "$ts $path $ev $file" >> "$LOG"
  [ -n "$ALERT_WEBHOOK" ] && curl -s -X POST -H 'Content-Type: application/json' --data "{\"text\":\"$ts $path $ev $file\"}" "$ALERT_WEBHOOK" >/dev/null 2>&1
done

Файл /var/log/filewatch.log начнёт пополняться строками вида:
YYYY-MM-DD HH:MM:SS /path MODIFY filename.

Запускаем скрипт в фоне (например, через nohup), чтобы он работал независимо от сессии:

nohup /usr/local/bin/file-monitor.sh /path/to/watch /var/log/filewatch.log >/dev/null 2>&1 &

Теперь скрипт работает в фоне, PID виден через pgrep -f file-monitor.sh.

Проверка работоспособности:

tail -n 3 /var/log/filewatch.log

Пример ожидаемого вывода

2025-11-11 12:34:01 /path/to/watch MODIFY important.conf

Остановка/очистка. Убираем процесс-монитор:

pkill -f file-monitor.sh && echo "Остановлено" || echo "Процесс не найден"

🔥 В результате скрипт даёт простой и надёжный способ отслеживать изменения файлов и записывать события в лог.

🚪 Linux Ready | #практика

📂 Напоминалка по структуре каталогов Linux!

Например, /bin содержит системные бинарные файлы, а /etc — конфигурации, управляющие поведением системы.

На картинке — директории Linux, их назначение и место в иерархии.

Сохрани, чтобы не забыть!

🚪 Linux Ready | #ресурс

👩‍💻 Базовый план мониторинга Linux-сервера без сложных систем!

Для одиночного сервера не всегда нужен Prometheus и сложные дашборды. Достаточно видеть загрузку CPU, памяти, диска, состояние сервисов и свежие ошибки в логах — это уже закрывает 80% реальных проблем.

В этом посте:

• Снимаем быстрый срез по ресурсам (CPU, RAM, диск);

• Простой способ проверки ключевых сервисов через systemd;

• Минимальные приёмы работы с логами nginx;

• Собираем всё это в лёгкий мониторинг.

Будет полезно тем, кто держит свои проекты на VPS и хочет видеть, что с ними происходит, без тяжёлых систем мониторинга.

🚪 Linux Ready | #гайд

Онлайн-профилирование CPU-интенсивного процесса через perf без даунтайма!

Когда сервис забирает почти весь CPU, важно быстро понять, где именно тратится время — в user-коде, ядре, библиотеках или на блокировках.

Найти PID:

pgrep -f myservice

Горячие функции в реальном времени:

sudo perf top -p <PID>

Показывает, какие функции потребляют больше всего CPU прямо сейчас.

Короткий профиль для детализации:

sudo perf record -F 99 -p <PID> -- sleep 15
sudo perf report

Небольшой профиль даёт репрезентативный срез и позволяет проваливаться в стеки.

User-space-only + стеки:

sudo perf record -F 99 -p <PID> -e cycles:u --call-graph=dwarf -- sleep 15
sudo perf report

Фокус на пользовательском коде и детальные стеки вызовов для точной локализации.

Проверка системных вызовов:

sudo strace -p <PID> -tt -T -f -o /tmp/strace.log

Нагрузка по потокам:

top -H -p <PID>

Помогает обнаружить конкретный поток, создающий основную нагрузку.

Права на профилирование:

cat /proc/sys/kernel/perf_event_paranoid

🔥 Этот набор команд позволяет без остановки сервиса быстро понять, куда именно уходит CPU, и принимать решения на основе объективного профиля.

🚪 Linux Ready | #практика

Многие не задумываются, что стандартизация имён сервисов спасает от путаницы!

Вместо nginx-web, postgres-main, redis-cache — используй простые имена: nginx.service, postgres.service, redis.service.

Тогда systemctl status/list/ restart работают без запоминания хаотичных названий.

Проверяем статус всех сервисов одной командой:

systemctl status nginx postgres redis

Быстрый поиск по части имени без путаницы:

systemctl list-units --type=service --state=running | grep nginx

Перезапуск группы сервисов brace expansion’ом:

systemctl restart {nginx,postgres,redis}.service

🔥 Стандартизация имён = команды работают везде без локальных танцев с бубном.

🚪 Linux Ready | #совет

👩‍💻 Быстрая диагностика медленной загрузки!

В этом посте собраны 7 команд для анализа проблем при старте системы: от времени запуска сервисов до задержек диска и ошибок драйверов. dmesg, top, iostat, systemd-analyze, journalctl, lsblk, smartctl — всё, что нужно, чтобы быстро понять, что тормозит загрузку.

🚪 Linux Ready | #шпора