Что такое synthetic monitoring и чем он отличается от RUM

Synthetic monitoring — это подход, при котором система мониторинга сама регулярно прогоняет заранее заготовленные сценарии: открывает страницу, делает запрос к API, логинится, оформляет тестовый заказ. По результатам этих «искусственных» проверок и судят о работе сервиса.

В отличие от обычного uptime-мониторинга, синтетический мониторинг проверяет не один URL, а целый пользовательский путь и делает это даже тогда, когда живых пользователей нет. Это превращает его в полезный инструмент для контроля критичных бизнес-сценариев.

Что такое synthetic monitoring простыми словами

Идея проста: вместо того чтобы ждать жалоб от пользователей, мониторинг сам играет роль пользователя.

Типичный сценарий выглядит так:

• открыть главную;
• кликнуть «Войти»;
• ввести логин и пароль;
• проверить, что появился личный кабинет;
• сделать ключевое действие, например, создать заказ;
• зафиксировать время каждого шага.

Если на каком-то этапе сценарий упал или замедлился, мониторинг создает инцидент.

Чем synthetic monitoring отличается от RUM

Часто эти два подхода путают. На самом деле они отвечают на разные вопросы.

Хорошая практика — использовать оба подхода. Synthetic ловит регрессии и сбои круглосуточно, RUM показывает, как сервис ощущают живые пользователи.

Зачем нужен синтетический мониторинг

• Проверка ключевых пользовательских сценариев. Доступность главной страницы — это лишь верхушка айсберга. Реальный бизнес ломается на checkout, логине, оплате, поиске.

• Контроль ночью и в выходные. Когда трафик низкий, обычный uptime-мониторинг ловит только грубые падения. Синтетика честно прогоняет сценарии и тогда, когда никого нет.

• Раннее обнаружение регрессий. Если после релиза кнопка «Купить» перестала работать, synthetic-проверка увидит это раньше, чем соберется первый пользовательский фидбек.

• SLA по бизнес-процессам. Можно измерять uptime не сайта в целом, а конкретного сценария: «оформление заказа доступно 99.9% времени».

• Проверка из разных регионов. Синтетику легко запускать из нескольких локаций и фиксировать, где сервис работает хуже.

Какие бывают синтетические проверки

• HTTP-проверка. Самый простой случай: запрос к URL и проверка кода ответа, заголовков и тела. Подходит для статических страниц и API.

• API-сценарий. Цепочка из нескольких запросов: получить токен, дернуть защищенный endpoint, проверить статус. Хорошо подходит для бэкенда без UI.

• Browser-проверка. Полный прогон сценария в headless-браузере (обычно Chromium через Puppeteer или Playwright). Кликает по кнопкам, заполняет формы, читает текст со страницы.

• Транзакционный сценарий. Имитация бизнес-операции от и до: логин, добавление в корзину, оплата тестовой картой, проверка письма. Самый ценный, но и самый сложный в поддержке.

Что важно мониторить в сценарии

Один прогон сценария дает сразу несколько метрик:

• успешность всего сценария;
• успешность каждого шага в отдельности;
• время выполнения сценария;
• время отдельных шагов;
• размер ответов и количество запросов;
• появление ожидаемых элементов на странице.

Особенно полезно смотреть распределение времени по шагам. Если внезапно «логин» начал занимать вдвое дольше, это сигнал проблем с авторизацией задолго до того, как сайт упадет.

Где synthetic monitoring запускать

Точка запуска влияет на то, что вы измеряете.

• Внешние локации. Дают честную картину со стороны интернета: туда же входит DNS, CDN, фаервол, балансировщик. Подходит для критичных пользовательских сценариев.

• Внутри инфраструктуры. Полезно для внутренних сервисов и API, которые недоступны снаружи. Помогает отделить «сломалось приложение» от «сломался канал в интернет».

• С разных провайдеров. Если важно поймать сетевые проблемы и региональные сбои, имеет смысл запускать сценарии из нескольких независимых сетей.

Типичные ошибки при настройке синтетики

• Слишком хрупкие сценарии. Если тест ломается из-за каждой смены текста кнопки, команда быстро перестает ему доверять. Опирайтесь на стабильные селекторы и data-test-атрибуты.

• Зависимость от внешних аккаунтов. Сценарий, который ломается, как только истек тестовый пароль или поменялся курс капчи, дает много шума. Заведите отдельные сервисные аккаунты и тестовые карты.

• Тестирование «всего подряд». Чем больше сценариев, тем дороже их поддерживать. Лучше иметь 3-5 надежных проверок ключевых путей, чем 50 нестабильных.

• Прогон только в одной точке. Один регион не покажет географические проблемы и не отделит локальный сбой от глобального.

• Алерт на каждое падение. Браузерный сценарий по природе менее стабилен, чем HTTP-проверка. Используйте retries и подтверждайте инцидент несколькими прогонами.

Сколько проверок и как часто запускать

Универсального правила нет, но есть рабочие ориентиры:

Чем дороже сценарий, тем тщательнее стоит выбирать частоту и тем важнее не плодить дубли.

Как synthetic monitoring дружит с остальным мониторингом

Синтетика хорошо работает в связке с другими сигналами:

• uptime-проверки ловят грубые падения раньше всех;
• synthetic подтверждает, что ключевые сценарии действительно работают;
• RUM показывает, как сервис ощущают живые пользователи;
• метрики и логи помогают понять причину, когда сценарий упал.

В Statuser базовые сценарии можно начать с обычных HTTP- и API-проверок: задать интервал, локации и каналы уведомлений, а более сложные пользовательские пути добавлять по мере необходимости.

Что почитать дальше

• Что такое uptime monitoring и как он работает
• Что такое false positive в мониторинге и как его уменьшить
• Как выбрать интервал проверки сайта для мониторинга

Вывод

Synthetic monitoring закрывает важный пробел между «сайт открывается» и «пользователи довольны». Он ловит регрессии в ключевых сценариях, работает круглосуточно и дает понятный SLA по бизнес-процессам, а не только по доступности URL.

Главное — не пытаться покрыть синтетикой все. Несколько надежных сценариев на критичных путях обычно дают больше пользы, чем десятки хрупких тестов. А если хотите быстро начать с простых проверок и постепенно добавлять более сложные, в Statuser это удобно собирается на уровне настроек одного монитора.