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

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

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

Второй подход, с которым synthetic регулярно путают, — Real User Monitoring (RUM). Разберём, как работает каждый из них, в чём между ними разница и почему выбирать между ними обычно не нужно.

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

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

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

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

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

Что такое Real User Monitoring (RUM)

RUM устроен наоборот: он ничего не проверяет сам, а собирает данные с браузеров настоящих посетителей. Обычно это небольшой JavaScript-скрипт на странице, который отправляет в систему мониторинга:

• время загрузки страницы и отрисовки контента;
• задержку до первого взаимодействия с интерфейсом;
• ошибки JavaScript;
• устройство, браузер и регион пользователя;
• показатели Core Web Vitals — LCP, INP, CLS.

Разница именно в источнике данных, и она сильнее, чем кажется. Сервер может отвечать за 150 мс, но пользователь со слабым мобильным интернетом всё равно будет ждать страницу несколько секунд: у него дольше DNS, TLS, загрузка скриптов и рендеринг. Проверка из дата-центра по оптике этого не увидит, RUM покажет сразу.

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

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

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

Почему одного подхода недостаточно

Проще всего это видно на двух зеркальных сценариях.

Ночью API не отвечал десять минут. Synthetic-проверка увидит это на первом же прогоне и создаст инцидент. RUM в это время, скорее всего, не покажет ничего: живого трафика почти нет, а значит нет и данных — в отчете останется просто провал по количеству сессий.

Все synthetic-проверки зелёные, но пользователи одного региона жалуются на медленную загрузку. Причина может быть в CDN, у конкретного провайдера или на участке сети, через который агенты мониторинга просто не ходят. Такую деградацию видно только по данным реальных браузеров, с разбивкой по регионам, провайдерам и устройствам.

Ни один подход не закрывает оба случая: 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 показывает, как сервис ощущают живые пользователи;
• метрики и логи помогают понять причину, когда сценарий упал.

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

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

• Что такое uptime monitoring и как он работает
• Что такое false positive в мониторинге и как его уменьшить
• Как выбрать интервал проверки сайта для мониторинга
• Четыре золотых сигнала в мониторинге: latency, traffic, errors, saturation
• Что такое SLI, SLO и SLA: в чём разница

Вывод

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

RUM отвечает на другой вопрос — каким сервис получился у реальных людей на их устройствах и каналах связи. Поэтому выбирать между подходами обычно не нужно: synthetic сообщает, что сломалось и когда, RUM — насколько это задело пользователей.

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