Сегодня рассмотрим, чем отличаются два подхода к сбору метрик - pull или push ⚖️

(Постоянно путаю эти движения при взаимодействиях с дверьми 😂)

Статья разделена на две части (сиквел выйдет позже на этой неделе 2️⃣)

#статья | 🍩 Донейшн | 📈 Забустить канал

Наводим порядок в Docker: команды для чистоты и спокойствия 🧹

Привет, коллеги! 👋

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


🛑 Остановка всех контейнеров:

docker stop $(docker ps -aq)

Что это делает?
Эта команда останавливает все запущенные контейнеры.
$(docker ps -aq) возвращает список всех контейнеров (и запущенных, и остановленных), а
docker stop завершает их работу.

Зачем это нужно?
Иногда контейнеры "зависают" или занимают порты впустую. Это как сказать: "Всем отдыхать!" 🌙

⚠️ Будьте внимательны:
Останавливаются ВСЕ контейнеры. Проверьте, нет ли среди них тех, что должны работать 24/7. Для точечной остановки лучше использовать docker stop <container_id>.


🗑 Удаление всех контейнеров:

docker rm $(docker ps -aq)

Что это делает?
Удаляет все остановленные контейнеры. Тот же $(docker ps -aq) даёт список, а docker rm убирает их без следа.

Зачем это нужно?
Если у вас накопились старые контейнеры, которые только занимают место, эта команда — как удаление сразу всех приложений 🧼

⚠️ Будьте внимательны:
Удаляется ВСЁ. Если в контейнерах остались важные данные, лучше сначала проверить список с помощью docker ps -a и удалить выборочно.


🧹 Полная очистка системы:

docker system prune -a

Что это делает?
Удаляет всё неиспользуемое: остановленные контейнеры, сети, образы без тегов и кэш. Флаг -a усиливает эффект, убирая даже неиспользуемые образы. После ввода команды Docker попросит подтвердить действие нажатием y.

Зачем это нужно?
Со временем Docker обрастает "мусором", который ест место на диске. Эта команда — как весенняя очистка корзины. 🌸

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


📦 Уборка томов:

docker volume prune -a

Что это делает?
Удаляет все неиспользуемые тома — места, где контейнеры хранят данные. Как и в предыдущем случае, нужно подтвердить нажатием y.

Зачем это нужно?
Тома могут копиться, как старые коробки в кладовке. Эта команда освобождает место и возвращает порядок. 📦

⚠️ Будьте внимательны:
Если тома содержат данные, которые могут понадобиться, сначала проверьте их список с помощью docker volume ls. Удаление — это навсегда!


Выполните эти команды последовательно, чтобы полностью очистить вашу систему от докера и вернуться в изначальное состояние

docker stop $(docker ps -aq)

docker rm $(docker ps -aq)

docker system prune -a

docker volume prune -a

#полезности | 🍩 Донейшн | 📈 Забустить канал

🐳 Docker vs Docker Compose: когда использовать один контейнер, а когда управлять целым набором?

Сегодня разберемся с популярными инструментами контейнеризации: чем Docker отличается от Docker Compose и когда что использовать для тестирования производительности.

🔍 Docker: одиночный контейнер
Docker — это платформа, которая позволяет упаковать приложение со всеми зависимостями в изолированный контейнер. По сути, это как виртуальная машина, только намного легче и быстрее.

✅ Когда использовать Docker:
- Для запуска одиночного сервиса (например, только базы данных или только API)
- Если нужно быстро протестировать одну компоненту системы
- Для создания воспроизводимой среды разработки
- Когда важна изоляция процессов

💻 Пример команды:

# Запуск одиночного контейнера с PostgreSQL

docker run -d --name my-postgres -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 postgres:13

🚢 Docker Compose: набор контейнеров
Docker Compose — это инструмент для определения и запуска ОДНОВРЕМЕННО нескольких приложений. С его помощью можно описать всю инфраструктуру в одном файле с расширением .yml.

✅ Когда использовать Docker Compose:
- Когда тестируемая система состоит из нескольких взаимосвязанных сервисов
- Для создания полноценного тестового окружения
- Когда требуется сложная настройка сети между контейнерами
- Для запуска интеграционных и нагрузочных тестов

📄 Пример файла docker-compose.yml для запуска сразу нескольких сервисов:

version: '3'
services:
  api:
    build: ./api
    ports:
      - "8000:8000"
    depends_on:
      - db
    environment:
      - DB_HOST=db
      - DB_USER=postgres
      - DB_PASSWORD=mysecretpassword

  db:
    image: postgres:13
    environment:
      - POSTGRES_PASSWORD=mysecretpassword
    volumes:
      - pgdata:/var/lib/postgresql/data

  loadtest:
    image: jmeter:5.4
    volumes:
      - ./test-plans:/test-plans
    command: -n -t /test-plans/load-test.jmx -l /test-plans/results.jtl
    depends_on:
      - api

volumes:
  pgdata:

🔥 Реальный кейс: нагрузочное тестирование с Docker Compose
Представьте: вам нужно протестировать микросервисную архитектуру под нагрузкой. Вот как это может выглядеть:

1. В docker-compose.yml описываем все микросервисы:
- Базы данных
- Prometheus + Grafana для мониторинга
- Сам сервер, на котором будут проводиться тесты

2. Все сервисы запускаем одной командой:

docker-compose up -d

3. Получаем полноценное тестовое окружение с мониторингом!

🤔Чтобы запустить такую же конфигурации через обычный docker (не docker compose) потребовалось бы писать "простыню" команд для каждого сервиса отдельно


🎁В комментарии приложил файл docker-compose.yml с набором сервисов для сбора метрик

#полезности | 🍩 Донейшн | 📈 Забустить канал

🔍 grep: мощный инструмент для анализа логов в нагрузочном тестировании

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

📋 Что такое grep?

grep — это консольная утилита для поиска текста по шаблону.

Если простыми словами: grep помогает найти иголку в стоге сена, когда ваш лог-файл весит несколько гигабайт! 🧵

🚨 Быстрый поиск ошибок в логах
Одно из самых частых применений grep в тестировании производительности — быстрый поиск проблем в логах. После нагрузочного теста вы можете быстро проверить наличие ошибок:

grep ERR application.log

Или предупреждений:

grep WRN application.log

В большинстве приложений используются стандартные уровни логирования, поэтому вы также можете искать:

grep ERROR application.log
grep WARNING application.log
grep CRITICAL application.log

💡 Флаг -C: не забывайте про контекст!
Но одна строка с ошибкой часто не дает полной картины.

grep -C 3 ERROR application.log

Эта команда покажет не только строки с ошибками, но и 3 строки до и 3 строки после каждого совпадения. Это дает бесценный контекст для анализа проблемы.

Вы также можете отдельно указать, сколько строк до и после показывать:

-B n (Before): показать n строк до совпадения
-A n (After): показать n строк после совпадения

# 2 строки до и 5 строк после каждой ошибки
grep -B 2 -A 5 ERROR application.log

💬 Знаком ли вам grep? Делитесь, какие еще командные утилиты помогают вам в работе? Для этого природой и были придуманы комментарии 🤔


🎁В комментарии приложил шпаргалку по основным флагам grep


#полезности | 🍩 Донейшн | 📈 Забустить канал

🔥 Пятница! Время нагрузочного тестирования… и правильной музыки! 🔥

Нагрузочное тестирование – это не только метрики, отчеты и графики 📊, но и атмосфера. А что лучше всего задает нужный вайб? Конечно же, мощный плейлист!

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

🎧 LET’S LOAD PLAYLIST 🎧
🎵 Spotify
🎵 Яндекс-Музыка

Теперь нагрузочное тестирование пройдет максимально бодро 💥.

💬 Какой трек вы бы добавили в этот плейлист? Пишите в комменты, соберем лучший саундтрек для тестировщиков!

🎁 В комментарии приложил другие варианты обложек для плейлиста

#юмор 🍩 Донейшн | 📈 Забустить канал

🔍 Уровни логирования: ключ к эффективному тестированию производительности

Привет, друзья! Задумывались ли вы, какую роль играют логи при анализе производительности системы? Правильная настройка уровней логирования может превратить хаос данных в четкую картину проблем! 💡

🎯 Разбираемся в основных уровнях логирования:

💥 DEBUG — самый детальный уровень. Содержит всю техническую информацию, необходимую для отладки.

DEBUG 2025-04-07 12:34:56 [LoadTest] - Запрос выполнен за 235ms, использовано памяти: 45MB

ℹ️ INFO — стандартный уровень для штатных событий. Показывает, что система работает как задумано.

INFO 2025-04-07 12:35:00 [LoadTest] - Тестовый сценарий "Авторизация" запущен с 1000 виртуальными пользователями

⚠️WARN — предупреждения о потенциальных проблемах, которые пока не нарушают работу системы.

WARN 2025-04-07 12:36:05 [LoadTest] - Среднее время ответа превысило порог в 500ms (текущее: 678ms)

⛔️ERROR — критические ситуации, требующие немедленного вмешательства.

ERROR 2025-04-07 12:38:12 [LoadTest] - Соединение с базой данных разорвано, тест прерван

☠️FATAL — катастрофические события, после которых система не может функционировать.

FATAL 2025-04-07 12:40:00 [LoadTest] - Критическая нехватка памяти, система остановлена

🔄 Как эти уровни настроить?
Вот что действительно удобно — настраивать логирование прямо из конфигурации Docker! Особенно когда нужно быстро переключить уровень для тестирования 🚀
Пример конфигурации в docker-compose.yml 👇

version: '3'
services:
  api-service:
    image: your-service:latest
    environment:
      - LOGGING_LEVEL=INFO  # Базовый уровень для обычной работы
    # другие настройки...

  api-service-debug:
    image: your-service:latest
    environment:
      - LOGGING_LEVEL=DEBUG  # Расширенное логирование для отладки
    # другие настройки...

(🤔 не забудьте пересобрать контейнер)

💡Также можно собирать контейнер для разных профилей с разным уровнем логирования:

version: '3'
services:
  api-service:
    image: your-service:latest
    environment:
      - SPRING_PROFILES_ACTIVE=${LOG_PROFILE:-prod}  # Используем переменную окружения
    # другие настройки...

Теперь можно запускать с разными профилями:

LOG_PROFILE=debug docker-compose up -d  # Для отладки
LOG_PROFILE=prod docker-compose up -d   # Для обычной работы

🎁В комментарии приложил пример анализа лога


#полезности | 🍩 Донейшн | 📈 Забустить канал

Что такое хост и порт? Понимаем на простом примере!

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

🔑 Основная аналогия: дом с квартирами

Хост (Host) — это как многоквартирный дом с уникальным адресом на улице. В мире компьютеров это любое устройство с IP-адресом в сети (сервер, компьютер, смартфон).

Порт (Port) — это как номер квартиры в этом доме. Позволяет определить, куда именно (в какое приложение или сервис) должны попасть данные на конкретном устройстве.

👨‍💻 Как это работает на практике?
Представьте многоквартирный дом по адресу
ул. Серверная, 192.168.1.10 (это наш IP-адрес).
В этом доме:

📞 Квартира 80 — веб-сервер (HTTP)
🔐 Квартира 443 — защищённый веб-сервер (HTTPS)
📧 Квартира 25 — почтовый сервис (SMTP)
📁 Квартира 21 — FTP-сервер для файлов
🔌 Квартира 22 — SSH для удалённого доступа

Когда к вам приходит запрос на 192.168.1.10:80, это всё равно что письмо с адресом "ул. Серверная, 10, кв. 80" — оно попадёт именно в веб-сервер, а не в почтовый сервис!

⚡️ Важные моменты для тестирования производительности:
- Порты как узкие места
Слишком много посетителей пытаются попасть в одну "квартиру"? В реальном мире образуется очередь! Так же и с портами — они могут стать узким местом при высокой нагрузке.

- "Зарезервированные квартиры"
Порты 0-1023 — привилегированные, как элитные квартиры. Для их использования нужны особые права (root/admin).

- "Стандартные планировки"

80   — HTTP
443  — HTTPS
3306 — MySQL
6379 — Redis
5432 — PostgreSQL
8080 — Альтернативный веб-порт (часто для тестовых окружений)

- "Свободные квартиры"

Порты 1024-49151 — зарегистрированные, но многие свободны.
Порты 49152-65535 — динамические, используются временно.

🛠 Как проверить "жильцов" во время тестирования?
🐧 В Linux:

# Показать все открытые порты и слушающие сокеты
netstat -tuln

# Узнать, какое приложение использует порт 8080
lsof -i :8080

🪟 На Windows:

# Показать все открытые порты
netstat -an

# Узнать, какой процесс использует порт 8080
netstat -ano | findstr :8080

❓ Почему это важно для нагрузочного тестирования?
При создании тестового сценария вы должны точно знать, к какому "дому" (хосту) и в какую "квартиру" (порт) стучаться

💭 А вы сталкивались с ситуациями, когда проблемы с производительностью системы были связаны именно с портами? Как вы их решали? Делитесь опытом в комментариях!


#полезности | 🍩 Донейшн | 📈 Забустить канал