Синтетический мониторинг транзакций
Мониторинг транзакций сайта от HostTracker воспроизводит реальный пользовательский сценарий - вход, поиск, добавление в корзину, оформление заказа - в реальном браузере из 300+ локаций и оповещает вас в момент, когда шаг ломается.
Как выполняется проверка транзакции: от первого шага до оповещения
Каждый запуск - от первого перехода до вердикта.
Никакой записи макросов, которая устаревает. Назовите шаги - это имя и появится в оповещении.
checkout · 5 шагов · 3.6 s
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
navigate, click, type, select, checkContent, hover, waitForNavigation, sleep, screenshot и back - у каждого свой тайм-аут и имя.
Любая ошибка в консоли браузера проваливает проверку, а список разрешённых фрагментов - до десяти подстрок - позволяет игнорировать шумный сторонний скрипт.
Создавайте и редактируйте мониторы транзакций через REST, SDKs, Terraform или MCP - с полным набором действий.
ПодробнееНачните с того единственного сценария, чей сбой стоит вам денег, доведите его до стабильной работы, и только потом добавляйте остальные. Один отслеживаемый сценарий, которому вы доверяете, лучше пяти наполовину настроенных.
Откройте страницу товара, кликните «добавить в корзину», проверьте, что значок корзины показывает один товар, откройте оформление заказа, проверьте, что сумма и форма оплаты отрисовались. Остановитесь на один шаг раньше фактического оформления заказа - и вы получите полное покрытие без тестовых заказов в базе данных.
Введите учётные данные выделенного тестового аккаунта, отправьте форму, дождитесь перехода, а затем проверьте текст, который существует только при реальной сессии. Это сценарий с самой высокой ценностью для большинства приложений - сломанный вход означает полный сбой, который на каждой странице всё равно возвращает 200.
Заполните поля, отправьте форму, проверьте текст благодарности. Тихая поломка форм - классический невидимый сбой: ничего не выдаёт ошибку, ничего не оповещает, а заявки просто перестают поступать, пока кто-нибудь не заметит это спустя недели.
Введите запрос, который всегда должен что-то находить, отправьте форму, а затем проверьте одновременно, что известный результат присутствует, а текст «ничего не найдено» отсутствует. Именно вторая проверка выявляет поисковый индекс, который незаметно перестал перестраиваться.
Пройдите форму регистрации до финального экрана подтверждения и проверьте его, направив форму на тестовую цель, чтобы мониторинг никогда не создавал реальные аккаунты. Регистрация ломается тихо и дорого - никто не жалуется на регистрацию, которую не смог завершить.
Запросите сброс пароля и проверьте, что появляется экран подтверждения. Это зависит от вашего почтового конвейера, очереди и сервиса токенов, поэтому это необычно хороший канарейка для проблем бэкенда, которые никогда не проявляются на главной странице.
Сервис проверки транзакций HostTracker убеждается, что все этапы онлайн-транзакции работают корректно. Он проверяет каждый шаг процесса - от добавления товаров в корзину до завершения покупки. Это помогает находить и устранять проблемы, которые могли бы помешать клиентам совершить покупку, что улучшает пользовательский опыт и сокращает потерю продаж.
Функция проверки транзакций HostTracker охватывает различные аспекты транзакции в интернет-магазине. Она включает отправку форм, нажатия кнопок и переходы между страницами, повторяя поведение реальных пользователей. Это тестирует весь процесс покупки, чтобы убедиться, что он работает исправно. Также предоставляются подробные логи и отчёты, которые помогают администраторам быстро находить и устранять проблемы, не затрагивая путь покупателя.
Проверки транзакций делают сайты интернет-магазинов надёжнее и эффективнее. Они помогают транзакциям проходить без сбоев, устраняя проблемы ещё до их возникновения. Это повышает удовлетворённость клиентов и доверие к сайту. Это также помогает удерживать клиентов, избегая потери продаж. Поэтому это полезный инструмент для любого интернет-магазина.
Шаг по имени, его скриншот и время выполнения каждого предыдущего шага.
Результат и оповещение содержат имя шага, поэтому «недоступен» превращается в «3 - отправка логина перестала перенаправлять».
Делается, когда шаг завершается ошибкой, рядом со снимком после последнего шага - как страница выглядела на пути к нему.
Сайты, серверы, API, сертификаты. Один тип проверки на страницу, за всеми - те же локации, оповещения и отчёты.
"Я давно пользуюсь этим сервисом мониторинга, и моя повседневная рутина перестала быть проблемой. Он тихо следит за всеми моими сайтами и позволяет мне реагировать в тот момент, когда что-то идёт не так."
Нам доверяют команды из
Каждая глава открывается на месте, поэтому страница остаётся короткой.
Синтетический мониторинг означает, что трафик создаётся намеренно: вместо того чтобы ждать, пока посетитель столкнётся с проблемой, и надеяться, что он вам об этом сообщит, сервис мониторинга сам обращается к вашему сайту по расписанию, извне вашей сети. Мониторинг транзакций - это его многошаговая форма. Простая синтетическая проверка запрашивает один URL и смотрит на ответ. Проверка транзакции открывает настоящий браузер, проходит упорядоченный сценарий - открыть страницу, войти в аккаунт, выполнить поиск, добавить в корзину, оформить заказ - и на каждом шаге проверяет то, что обнаруживает.
Это различие важно, потому что бóльшая часть того, что клиенты на самом деле делают на сайте, - это последовательность действий, а не просмотр одной страницы. Каждая отдельная страница в процессе оформления заказа может возвращать HTTP 200, в то время как сам процесс оформления сломан: кнопка, удалённая при развёртывании, форма, отправляющая данные на эндпоинт, который теперь возвращает 404, ошибка JavaScript, останавливающая мастер настройки на третьем шаге. Ничего из этих сбоев не отражается в коде состояния, поэтому ничего из этого не отражается и в обычном мониторинге доступности.
Это не то же самое, что финансовый мониторинг транзакций. В банковской сфере и комплаенсе «мониторинг транзакций» означает проверку платежей на предмет мошенничества и отмывания денег. Эта страница посвящена значению термина в веб-эксплуатации: автоматическому воспроизведению пользовательского сценария на вашем собственном сайте, чтобы доказать, что он по-прежнему работает. HostTracker - это сервис мониторинга сайтов: он следит за вашим сценарием оформления заказа, а не за вашей платёжной книгой.
Быстрая HTTP-проверка - правильный инструмент для вопроса «сайт работает?». Это один запрос, поэтому и вердикт один: код состояния, время ответа и любое ключевое слово или правило проверки, которое вы задали для полученного тела ответа. Это очень много покрытия за очень небольшую цену - и она заканчивается именно там, где заканчивается первый ответ. Всё, что находится ниже черты в этой таблице, происходит уже после этой точки.
| Что на самом деле сломалось | Быстрая HTTP-проверка | Проверка транзакции |
|---|---|---|
| Сервер недоступен, сбой DNS, отказ TLS-рукопожатия | Выявлено | Выявлено |
| Главная страница возвращает 500 после развёртывания | Выявлено | Выявлено |
| Страница загружается, но кнопка «Добавить в корзину» удалена релизом | Пропущено - HTML по-прежнему возвращает 200 | Выявлено - шаг клика не может найти свой селектор |
| Форма входа отправляет данные на эндпоинт, который теперь возвращает 404 | Пропущено - сама страница формы в порядке | Выявлено - шаг после отправки так и не доходит до страницы аккаунта |
| Исключение JavaScript останавливает мастер оформления заказа на втором шаге | Пропущено - JavaScript не выполняется | Выявлено - браузер выполняет скрипт, и проверка может провалиться из-за ошибок консоли |
| Страница оплаты показывает баннер с ошибкой вместо подтверждения | Пропущено - отрисованная ошибка всё равно даёт 200 | Выявлено - проверка содержимого по тексту подтверждения не проходит |
| Cookie сессии перестаёт устанавливаться, поэтому третий шаг возвращает на страницу входа | Пропущено - здесь нет сессии, которую можно потерять | Выявлено - весь сценарий выполняется в рамках одной сессии браузера |
| Сторонний скрипт - виджет чата, менеджер тегов, SDK платежей - блокирует отрисовку | Пропущено - сторонние ресурсы никогда не запрашиваются | Выявлено - браузер запрашивает их точно так же, как это делает посетитель |
| Сценарий работает, но каждый шаг теперь занимает восемь секунд | Частично - замеряется только первый ответ | Выявлено - каждый шаг замеряется по времени, и шаг может превысить тайм-аут |
Ни одна из проверок не заменяет другую. Разумная рекомендация - использовать обе: одноминутную HTTP-проверку того же сайта для быстрого обнаружения сбоев и проверку транзакции для одного-двух сценариев, которые действительно приносят доход. Если хотите начать с половины про доступность, начните с распределённого мониторинга доступности из 300+ точек проверки и добавьте сценарий поверх него.
Каждый запуск открывает настоящий headless-браузер Chromium на одном из чекпоинтов HostTracker и выделяет ему одну сессию браузера на весь сценарий. Именно эта деталь делает проверку осмысленной: cookies, токены и состояние входа, установленные на втором шаге, всё ещё присутствуют на пятом - точно так же, как это было бы у человека, переходящего по вашему сайту. JavaScript выполняется, редиректы отслеживаются - включая те, что запускают ваши собственные скрипты, - а сторонние ресурсы загружаются так же, как в браузере посетителя.
Сценарий последовательный и завершается при первом сбое. Шаги выполняются в том порядке, в котором вы их написали, и первый же сбойный шаг завершает выполнение и становится указанной причиной. Вы никогда не получите лавину последующих ошибок, вызванных одной сломанной кнопкой - вы получите именно эту сломанную кнопку.
Два опциональных переключателя меняют строгость выполнения. Считать ошибку консоли сбоем превращает любую ошибку в консоли браузера в провал проверки - мощный инструмент для хорошо ведущего себя приложения, дополняемый списком до десяти разрешённых подстрок, чтобы известный «шумный» сторонний скрипт не поднимал ложную тревогу. Пропускать загрузку медиафайлов включено по умолчанию; отключите этот параметр, когда объектом тестирования является само медиасодержимое.
Транзакция - это список шагов, и каждый шаг - это одно действие над страницей. Здесь нет макрозаписи, которая со временем перестаёт работать: вы строите сценарий явно, и именно поэтому он продолжает работать, когда команда маркетинга меняет текст на кнопке.
| Действие | Что делает шаг |
|---|---|
| navigate | Открывает URL. Первая навигация - на собственный адрес монитора - добавляется автоматически как нулевой шаг. |
| click | Клик по элементу, найденному по CSS-селектору, или по координате во viewport. Левая, правая или средняя кнопка мыши, с опциональной задержкой удержания. |
| type | Ввод текста в поле, опционально с задержкой между нажатиями клавиш, чтобы собственные обработчики ввода страницы успевали реагировать. |
| select | Проверка мощности селектора: он должен не совпасть ни с чем, совпасть ровно с одним элементом, хотя бы с одним, или с любым количеством. Действует над всеми совпадениями, первым или случайным. |
| checkContent | Проверка отрисованного текста. До десяти ключевых слов, любое или все из них, с учётом регистра или без, при наличии или намеренном отсутствии, опционально только в видимом тексте. |
| hover | Наведение курсора на элемент - способ добраться до меню или подсказки, которые существуют только при наведении мыши. |
| waitForNavigation | Ожидание перехода страницы, опционально с провалом шага, если переход не произошёл вовремя. |
| sleep | Пауза от 1 миллисекунды до 10 секунд, с опциональным случайным разбросом, чтобы сценарий не бил в одну и ту же миллисекунду при каждом запуске. |
| screenshot | Захват страницы в середине сценария, чтобы сбой двумя шагами позже всё равно показывал, как выглядела страница по пути к нему. |
| back | Возврат на одну запись назад в истории браузера. |
Любой шаг может нести скриншот и ожидание навигации после себя, собственное переопределение тайм-аута и короткое имя длиной до 19 символов. Называйте свои шаги - это имя отображается в результате и в оповещении, и «3 - отправка входа» - это разница между страницей, которая «недоступна», и страницей, чей POST-запрос входа перестал выполнять редирект. В веб-редакторе скриншоты и ожидания навигации предлагаются как поведение после шага; полный набор действий, включая hover, доступен через API.
id или атрибут data-, который
вы контролируете, а не сгенерированное имя класса, меняющееся при следующей сборке.checkContent после каждого значимого перехода - это то,
что превращает последовательность кликов в настоящий тест: после входа проверяйте текст страницы
аккаунта; после оформления заказа - текст подтверждения.Если хотите быстро проверить стартовый URL перед созданием сценария, запустите бесплатную мгновенную HTTP-проверку без входа в аккаунт - или измерьте, как страница загружается в настоящем браузере, с помощью бесплатного теста скорости страницы.
Выполнение останавливается на сбойном шаге и фиксирует, что было обнаружено. Результат называет шаг, классифицирует сбой - тайм-аут, элемент, который селектор не смог найти, не совпавшая проверка содержимого, ошибка HTTP, ошибка соединения, ошибка консоли браузера или неправильно настроенный шаг - и сохраняет длительность каждого шага, URL, IP-адрес и HTTP-статус, на котором завершилась каждая навигация, сообщения консоли браузера и скриншот страницы в момент сбоя.
Затем это перепроверяется, прежде чем кого-то разбудят. Единичное неудачное наблюдение не считается сбоем: проверка повторяется на дополнительных независимых чекпоинтах, и изменение состояния подтверждается только тогда, когда кворум согласен. По умолчанию это вердикт большинства среди до семи агентов, минимум трёх - так что один нестабильный чекпоинт или один временный сетевой сбой между дата-центром и вашим хостом не может самостоятельно спровоцировать оповещение.
После подтверждения перехода оповещение следует задержке, которую выбрал каждый контакт: немедленно, либо через 3, 5, 15, 30 или 60 минут, либо через 3, 6, 12 или 24 часа непрерывного сбоя. Оповещения отправляются по девяти каналам уведомлений, которые поддерживает HostTracker - email, SMS, голосовой звонок, webhook, Slack, веб-push и мессенджеры Telegram, Discord и Viber - а когда сценарий снова начинает завершаться успешно, приходит уведомление о восстановлении.
Проверка транзакции - самый мощный монитор из тех, что предлагает HostTracker, и при этом обладающий наибольшим количеством реальных ограничений. Знание их заранее сэкономит вам целый вечер.
Эти два подхода отвечают на разные вопросы, и команда, понимающая это различие, перестаёт ждать, что один заменит другой. HostTracker - сервис синтетического мониторинга сайтов: он сам генерирует трафик со своих собственных чекпоинтов по расписанию, которое вы контролируете.
| Синтетический мониторинг транзакций | Мониторинг реальных пользователей | |
|---|---|---|
| Кто генерирует трафик | Сервис мониторинга, по фиксированному расписанию | Ваши реальные посетители, когда бы они ни зашли |
| Работает до появления трафика | Да - staging-сайт без пользователей всё равно проверяется | Нет - нет посетителей, нет данных |
| Замечает сбой в 3 часа ночи | Да - расписание не спит | Нет, пока кто-то не зайдёт |
| Называет точный сбойный шаг | Да - сценарий детерминирован | Редко - вы видите симптом, а не последовательность |
| Отражает реальный опыт клиентов | Нет - это контролируемая выборка | Да - в этом весь смысл |
| Требует кода на вашем сайте | Нет - выполняется полностью извне | Скрипт или SDK на каждой странице |
| Покрывает сценарий, который клиенты редко завершают | Да - вы выбираете, что именно тестировать | Нет - редкие пути остаются неизмеренными |
Если далее вам нужна не половина про сценарий, а половина про тайминги, HostTracker также измеряет загрузку страниц в реальном браузере - см. мониторинг тайминга доступа в браузере - а для машинного эквивалента транзакции проверка мониторинга API проверяет контракт ответа, а не отрисованную страницу. На стороне сервера монитор запросов к базе данных часто объясняет, почему сценарий изначально стал медленным.
Мониторинг транзакций сайта - это проверка, которая автоматизирует реальный многошаговый пользовательский сценарий: заполнение формы, вход в аккаунт, добавление товара в корзину или оформление покупки - и проверяет, что каждый шаг выполняется корректно, а вся последовательность приводит к ожидаемому результату. В отличие от простой проверки, которая лишь подтверждает загрузку одной страницы, мониторинг транзакций повторяет тот же путь, что и реальный посетитель: отправляет данные и последовательно переходит по страницам, а затем сверяет результат с заданными вами правилами. Это важно, потому что сайт может выглядеть полностью работоспособным по всем простым показателям доступности - главная страница загружается, отдельные страницы возвращают код 200 - в то время как критический многошаговый процесс, например оформление заказа, незаметно ломается на одном из этапов. Мониторинг транзакций HostTracker создан специально для того, чтобы выявлять именно такие сбои.
Мониторинг транзакций HostTracker может автоматизировать и проверять различные взаимодействия на сайте, включая отправку форм, нажатия кнопок и переходы между страницами, которые в совокупности моделируют то, как реальный пользователь перемещается по вашему сайту. Сюда входят такие распространённые сценарии, как прохождение регистрации или входа, отправка контактной формы или формы для сбора заявок, а также многошаговые процессы покупки - добавление товаров в корзину и оформление заказа. Поскольку проверка пошагово имитирует поведение реального пользователя, а не просто загружает одну страницу, она позволяет убедиться, что каждый этап процесса действительно работает и даёт ожидаемый результат, а не просто что вовлечённые страницы загружаются. Это делает её полезной для любого сайта, где сломанный интерактивный сценарий - а не просто неработающая страница - обойдётся вам потерей лидов, регистраций или продаж.
Базовый мониторинг доступности проверяет, отвечает ли отдельная страница или конечная точка и возвращает ли она нормальный код состояния, что говорит о доступности сервера, но ничего не сообщает о том, работает ли построенный поверх него многошаговый процесс. Мониторинг транзакций идёт дальше: он автоматизирует всю последовательность шагов - отправку формы, переходы по страницам, завершение процесса покупки - и проверяет, что каждый шаг выполняется успешно, а весь сквозной процесс приводит к правильному результату. Сайт может проходить все проверки доступности, в то время как процесс оформления заказа полностью сломан на этапе оплаты, потому что каждая отдельная страница по-прежнему загружается нормально сама по себе; заметить это способна только проверка, которая действительно проходит всю транзакцию. Для любого сайта, где конверсии зависят от многошагового сценария, мониторинг транзакций покрывает категорию сбоев, которую базовые проверки доступности просто не способны увидеть.
Да, это один из основных сценариев использования мониторинга транзакций. Проверки транзакций HostTracker проходят заданную последовательность шагов - например, добавление товара в корзину, переход к оформлению заказа, заполнение обязательных полей и достижение страницы подтверждения - и на каждом этапе проверяют, что всё выполняется как ожидается. Это означает, что сбой, возникший в любой точке сценария - будь то неработающая кнопка «добавить в корзину», ошибка валидации формы или страница оформления заказа, переставшая загружаться после недавнего развёртывания, - будет обнаружен и зафиксирован в подробных логах с указанием конкретного шага, на котором произошёл сбой. Быстрое обнаружение подобных проблем важно, потому что сломанный шаг оформления заказа напрямую приводит к потере продаж, и он может долго оставаться незамеченным при простых проверках доступности, поскольку отдельные вовлечённые страницы могут по-прежнему возвращать нормальный код состояния.
Когда один из шагов проверки транзакции завершается сбоем - форма не отправляется, ожидаемая страница не загружается или не выполняется условие проверки, - HostTracker фиксирует точку сбоя и отправляет оповещение через настроенные вами каналы уведомлений, чтобы вы знали не только о том, что что-то сломалось, но и в каком именно месте сценария это произошло. К оповещению прилагаются подробные логи и отчёты, дающие администраторам конкретный шаг и результат, необходимые для быстрого расследования, вместо того чтобы вручную повторно проходить весь сценарий. Именно эта детализация на уровне шагов делает мониторинг транзакций практически полезным для быстрого устранения проблем: знать, что «оформление заказа не работает», гораздо менее полезно, чем знать, что сбой происходит именно на шаге подтверждения оплаты после конкретного недавнего изменения, что существенно сужает круг вероятных причин.
Нет, хотя многошаговые сценарии покупки - распространённый пример, мониторинг транзакций полезен для любого сайта, где должна корректно работать не просто загрузка одной страницы, а последовательность действий пользователя. Сюда входят сценарии входа и регистрации для SaaS-приложений, формы для сбора заявок и обратной связи для сервисных компаний, многостраничные процессы подачи заявок и любые сценарии перемещения по сайту, где неработающая ссылка или неудачная отправка формы посреди процесса помешают посетителю завершить то, ради чего он пришёл. Любой интерактивный процесс, в котором потеря пользователя на полпути имеет реальную цену - упущенная регистрация, брошенная заявка, незавершённая подача формы, - выигрывает от того, что этот конкретный сценарий автоматизирован и регулярно проверяется, вместо того чтобы просто предполагать, что он всё ещё работает лишь потому, что вовлечённые страницы загружаются без ошибок.
Проверка транзакции выполняется с интервалом, который вы выбираете - от 10 минут до 24 часов: 10, 15, 30 и 45 минут, затем 1, 2, 4, 6, 12 и 24 часа. Этот минимальный порог выше, чем одноминутный минимум, который HostTracker предлагает для простых HTTP-проверок, и это сделано намеренно: проверка транзакции запускает настоящий браузер, загружает страницу вместе с её JavaScript и пошагово проходит ваш сценарий, что занимает секунды реальной работы, а не единственный запрос. Обычная практика - сочетать оба типа: одноминутная HTTP- или ping-проверка отвечает на вопрос «доступен ли сайт прямо сейчас», а проверка транзакции каждые 10-15 минут отвечает на более сложный вопрос - по-прежнему ли завершается оформление заказа, вход в аккаунт или регистрация. Такое сочетание выявляет полный сбой в течение минуты и сломанный сценарий в течение одного цикла проверки, не запуская сессию браузера против вашего приложения каждые шестьдесят секунд.
Нет, и делать этого не стоит. Проверка транзакции отправляет настоящие формы на ваш настоящий сайт, поэтому правильная настройка - это выделенный тестовый аккаунт, тестовый товар или SKU и, если сценарий доходит до оплаты, песочница или режим тестовых карт вашего платёжного провайдера - точно так же, как для любого автоматизированного end-to-end теста. Многие команды останавливают отслеживаемый сценарий на один шаг раньше необратимого действия: доходят до страницы оплаты, проверяют, что она отобразилась с верной суммой, и завершают сценарий там. Это по-прежнему доказывает, что все шаги вплоть до момента оплаты работают, но не создаёт заказ каждые десять минут. То же правило применимо к сценариям регистрации и сбора заявок - направьте сценарий на тестовую форму или отфильтруйте отправки монитора на своей стороне, чтобы трафик мониторинга никогда не засорял ваши реальные данные.
Начните бесплатный пробный период и следите за ключевыми сценариями пользователей - вход, поиск, оформление заказа - круглосуточно.
Часть инструментов мониторинга сайтов HostTracker.