Мониторинг API: что проверять из мобильной сети
Монитор должен подтверждать небольшой критичный путь, а не постоянно воспроизводить весь набор тестов. Для мобильного маршрута особенно важно отделять проблему API от проблемы соединения.
Главное за минуту
- У каждого шага должен быть отдельный критерий успеха.
- Частота мониторинга не должна превращаться в нагрузочный тест.
- Монитор использует синтетические данные и ограниченный cleanup.
- Алерт строится по окну и базовой линии, а не по одному запросу.
Минимальный сценарий
Начните с health endpoint, затем добавьте безопасное чтение и один разрешённый многошаговый путь. Изменяющие операции выполняйте только на тестовых данных.
Разделите коллекцию на обязательный read-only smoke и необязательный бизнес-сценарий. Для изменяющего запроса создавайте синтетический объект с уникальным префиксом, удаляйте его в cleanup и ограничивайте срок жизни на сервере. Монитор не должен использовать реальные заказы, платежи или клиентские реквизиты: такая проверка создаёт операционный и финансовый риск.
Порог времени
Фиксируйте DNS, соединение, TLS и общее время там, где инструмент это позволяет. Алерт по общей задержке дополняйте сетевой диагностикой.
Сначала соберите базовую линию для каждого маршрута, затем задайте порог p95 и допустимую долю превышений за окно, а не алерт на один медленный запрос. Сравнивайте мобильный путь с контрольной точкой и отмечайте время DNS, TCP и TLS, если исполнитель это поддерживает. Так задержка приложения не смешивается с установлением соединения.
Ошибки и 429
Разделяйте 4xx, 5xx и транспортный отказ. При 429 снижайте частоту и учитывайте Retry-After вместо немедленного повтора.
Для 429 прочитайте Retry-After, временно уменьшите частоту конкретного монитора и добавьте jitter, чтобы несколько проверок не повторились одновременно. Для 401 или 407 не запускайте автоматический шторм повторов: проверьте срок и область реквизитов. Транспортный timeout повторяйте один раз после короткой паузы, сохраняя первый результат для диагностики.
История результатов
Храните идентификатор монитора, версию коллекции и среду. Секреты передавайте через защищённые переменные и не печатайте в console log.
История должна связывать run ID, версию коллекции, environment ID, маршрут и каждый этап без значений секретов. Ограничьте срок хранения подробных response body; для длительной статистики достаточно кода, длительности и обезличенного результата assertion. Просмотр и экспорт сырых результатов разрешайте только ответственным и также записывайте в аудит.
Практический чек-лист
- 1Выберите безопасный критичный путь.
- 2Настройте пороги кода и времени.
- 3Разделите API-ошибку и сетевой отказ.
- 4Запретите реальные платежи и заказы в мониторе.
- 5Проверьте обработку Retry-After и jitter.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.