Мониторинг доступности и нагрузочный тест: не путайте цели
Мониторинг задаёт редкие повторяемые проверки состояния. Нагрузочное тестирование намеренно создаёт контролируемую интенсивность. У них разные разрешения, метрики и риски.
Главное за минуту
- Монитор отвечает «работает ли сейчас», нагрузочный тест — «что будет при заданной интенсивности».
- Один и тот же сценарий можно использовать, но с разными профилями запуска.
- Монитор и нагрузка используют разные расписания и сервисные аккаунты.
- Повтор проверки не должен увеличивать интенсивность отказа.
Частота
Монитор выполняет минимальное число запросов с интервалом. Нагрузочный тест управляет VU, итерациями или RPS в согласованном окне.
Для монитора задайте интервал, timeout, один ограниченный повтор и максимальное число запросов в час. Для нагрузки храните отдельный профиль stages или arrival rate и запускайте его только в разрешённом окне. Технически разведите расписания и сервисные аккаунты, чтобы ошибочная настройка cron не превратила постоянную проверку доступности в незапланированный stress-тест.
Критерий успеха
Для мониторинга важны доступность и корректность ответа. Для нагрузки добавляются перцентили, доля ошибок, пропускная способность и потребление ресурсов.
Монитор оценивайте по доступности за окно, корректности ответа и времени обнаружения. Нагрузку — по фактическому RPS, error rate, перцентилям и использованию ресурсов на каждой ступени. Общая панель может показывать оба набора, но названия и единицы должны различаться. Среднее время без распределения и объёма запросов не даёт полезного сравнения.
Реакция на отказ
Монитор создаёт событие и ограниченно перепроверяет. Нагрузочный тест при стоп-условии прекращает рост, чтобы не усугублять деградацию.
После отказа монитор создаёт один инцидент, выполняет независимую перепроверку и подавляет дубли до изменения состояния. Нагрузочный сценарий немедленно прекращает рост и при необходимости весь запуск. Не позволяйте механизму повторов компенсировать ошибку увеличением трафика. В отчёте сохраните первое событие, стоп-причину и действия ответственного.
Мобильный маршрут
Для него полезен лёгкий монитор пользовательского пути. Генерировать тяжёлую нагрузку через общий мобильный канал следует только при отдельной цели и расчёте ёмкости.
Для общего мобильного маршрута установите собственный бюджет соединений и пропускной способности. Лёгкие проверки распределяйте с jitter, а тяжёлый тест выполняйте на выделенной ёмкости или стенде. Если одновременно деградирует большая часть локации, приостанавливайте автоматические переключения и сначала подтверждайте масштаб сбоя независимым каналом.
Практический чек-лист
- 1Назовите тип каждой проверки.
- 2Задайте предел запросов.
- 3Разведите расписания мониторинга и нагрузки.
- 4Ограничьте число запросов монитора в час.
- 5Разведите панели и единицы измерения.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.