✍️ perf-tools — набор инструментов для анализа производительности!

Репозиторий от Brendan Gregg — одного из главных экспертов по performance и Linux-трейсингу. Здесь собраны готовые скрипты и утилиты для поиска узких мест по CPU, памяти, дискам и сети с использованием perf, ftrace, bcc и eBPF.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #репозиторий

Как диагностировать нестабильные systemd-сервисы!

Если система в целом работает корректно, но отдельные сервисы периодически падают или перезапускаются, диагностику удобно начинать со systemd и его журналов.

Сервисы в ошибочном состоянии:

systemctl --failed

Показывает юниты, завершившиеся с ошибкой — базовая точка входа.

Перезапуски конкретного сервиса:

journalctl -u nginx --no-pager -g 'Starting|Stopped|Failed'

Позволяет быстро выявить циклические рестарты и их частоту.

Автоматические рестарты systemd:

journalctl -b | grep -Ei 'systemd\[1\].*(restart|Restart)'

Помогает обнаружить сервисы, которые systemd регулярно перезапускает.

Количество рестартов:

systemctl show nginx -p NRestarts

Счётчик рестартов с момента запуска systemd. Рост значения обычно указывает на нестабильность сервиса.

Причина остановки:

journalctl -xeu nginx

Даёт максимальный контекст ошибки и системные пояснения.

Проверка OOM-killer:

journalctl -k -b | grep -Ei 'oom|oom-kill|killed process'

Актуально, если сервис завершается без явных ошибок в собственных логах.

Конфигурация сервиса:

systemctl cat nginx

Позволяет проверить параметры рестарта, drop-in override’ы, зависимости и условия запуска.

🔥 Такой разбор покрывает большинство случаев нестабильной работы systemd-сервисов без дополнительных инструментов.

➡️ DevOps Ready | #практика

👍 Linux Kernel Documentation — официальная документация по ядру!

Здесь собраны материалы о том, как работает ядро Linux: управление памятью, планировщик задач, драйверы устройств, файловые системы и взаимодействие с железом. Документация показывает внутренние механизмы системы, а не только внешнее поведение.

📌 Оставляю ссылочку: docs.kernel.org

➡️ DevOps Ready | #ресурс

Нагружаем приложение и смотрим, как оно себя ведёт!

Сегодня прогоняем тестовое веб‑приложение через обычную нагрузку и простейшую «атаку», чтобы увидеть разницу по метрикам и логам. Всё через терминал и пару утилит: hey/ab для нагрузки и curl для имитации агрессивного клиента.

Сначала замерим «здоровое» состояние с равномерной нагрузкой:

hey -z 30s -c 20 http://localhost:8080/

За 30 секунд получим средний RPS, latency и процент ошибок. Это будет базовый уровень, с которым будем сравнивать.

Теперь устроим «атаку» с одного IP — резкий всплеск запросов:

hey -z 30s -c 200 http://localhost:8080/login

Следим в это время за приложением:

tail -f app.log
htop

В логах увидишь частые обращения к одному эндпоинту и рост 5xx/4xx, а по ресурсам — скачок CPU/памяти.

Можно вынести это в простой скрипт:

load_test() {
  hey -z 20s -c 30 "$1"
  hey -z 20s -c 200 "$1"
}
load_test "http://localhost:8080/login"

🔥 Так удобно быстро смотреть, где приложение начинает «сыпаться» под нагрузкой: код, база или сеть.

➡️ DevOps Ready | #практика