Синтетический мониторинг против мониторинга реальных пользователей

Что делает каждый из них

Синтетический мониторинг, иногда называемый активным или проактивным, отправляет заданный вами запрос с контролируемой вами машины с заданным вами интервалом. Этот запрос может быть таким маленьким, как HTTP GET, или таким большим, как заскриптованная браузерная сессия, которая входит в систему, добавляет товар в корзину и оформляет заказ. Каждый запуск дает результат независимо от того, заходил ли кто-нибудь на сайт.

Мониторинг реальных пользователей, обычно сокращаемый до RUM, пассивен. Небольшой скрипт на ваших страницах сообщает то, что измерил браузер за этот визит: тайминги навигации, загрузку ресурсов, ошибки и Core Web Vitals так, как их пережил посетитель. Он дает данные пропорционально вашему трафику и не дает ничего, когда никого нет.

Что ловит синтетика и пропускает RUM

• Сбои в 4 утра или на любой странице с малым трафиком. Если никто не загружает страницу, RUM нечего сообщить, а полный сбой - это как раз тот случай, когда маяк отправить невозможно
• Доступность из мест, где у вас пока еще нет пользователей, - именно так вы узнаете, что новый рынок до вас не дотягивается
• Чистую базовую линию. Один и тот же скрипт, из одной и той же локации, с одним и тем же интервалом, так что изменение числа - это изменение сайта, а не того, кто случайно зашел
• Многошаговые потоки, которые вы не хотели бы прогонять на реальных пользователях, например оформление заказа, создающее настоящий заказ, или вход, который можно выполнять на тестовом аккаунте
• Сбои истечения и конфигурации, которые вообще никогда не доходят до браузера: сертификаты, DNS-записи, попадание в блеклисты, открытые порты
• Первый сбой после деплоя, еще до прихода трафика, который бы его выявил

Что ловит RUM и пропускает синтетика

• Реальное распределение устройств, сетей и локаций. Синтетическая проверка с подключения дата-центра никогда не воспроизведет телефон среднего класса на мобильном интернете
• Сторонние скрипты, баннеры согласия и персонализацию, которые загружаются только для настоящих сессий с настоящими cookie
• Проблемы, затрагивающие подмножество пользователей: одну версию браузера, один регион, один вариант A/B-теста
• Какие именно медленные страницы важны, взвешенные по числу людей, которые их видят
• Полевые Core Web Vitals, которые как раз и используют поисковые системы, в противовес лабораторным значениям, которые дает синтетический прогон

Когда нужно и то, и другое

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

Используйте RUM, чтобы решить, что чинить. Когда страница медленная для части людей, RUM говорит, для кого именно и скольких, а это как раз та информация, которая нужна для аргумента в пользу приоритизации, и которую синтетическая проверка дать не может.

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

Где здесь место мониторинга транзакций

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

Поскольку это синтетика, она работает по расписанию, не требуя трафика, а поскольку она использует настоящий браузер, она задействует JavaScript, сторонние зависимости и редиректы, которые пропускает обычная HTTP-проверка. Мониторинг транзакций HostTracker работает именно так, а руководство по проверке транзакций рассказывает, как записывается скрипт и что сообщает каждый шаг.

Превращение замера в оповещение

Ни один из подходов не полезен, пока по его результату никто не действует. Синтетическая проверка ценна тем, что работает независимо от того, следите вы за ней или нет, и тем, что сбой может дойти до вас немедленно: HostTracker выполняет свои проверки из 300+ точек в 158 городах по 13 типам мониторов и отправляет оповещения по email, SMS, голосовым звонком, в Slack, Telegram и другими способами при каждом изменении результата. Сочетайте это с любым RUM, который вы уже собираете, и у вас будут обе половины: оповещение, когда сайт ломается, и доказательства того, для кого именно он тормозил. Термины, на которых строятся оба этих подхода, разбирает остальной раздел о понятиях мониторинга.