Synthetic Monitoring: автоматическое измерение времени загрузки из нескольких регионов

Что показывает система Synthetic Monitoring

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

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

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

A частная репетиция отвечает на другой вопрос: она позволяет проверить, доступно ли приложение из частной сети. Это актуально, например, для внутренних сервисов, но не подтверждает их доступность из общедоступного Интернета. И наоборот, успешная проверка из общедоступного Интернета не означает, что доступ из любой корпоративной сети будет работать.

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

HTTP, браузеры и пользовательские пути

A Проверка HTTP запрашивает конечную точку и анализирует, например, код статуса или ответ. В случае страницы продукта он может быстро показать, что сервер отвечает не так, как ожидалось. Если он возвращает HTTP 200, это означает лишь выполнение проверенного критерия ответа: остается неясным, виден ли интерфейс и доступен ли он для управления.

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

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

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

Дополнительный визуальный осмотр позволяет выявить изменения в отображении, которые не обнаруживаются при проверке отдельных элементов. Для этого можно, например, сравнить скриншоты; обнаруженные отклонения необходимо затем проанализировать, поскольку не каждое видимое изменение является ошибкой. Другие подходы описаны в статье по теме Визуальная проверка и автоматизированные проверки сайта.

Как правильно различать время загрузки

„Без дополнительных уточнений термин “время загрузки» не обозначает однозначно сопоставимую величину. При открытии страницы в первую очередь важно время до получения первого ответа от сервера: оно помогает оценить задержки до поступления ответа. Однако оно ещё не говорит о том, когда браузер отобразил что-либо видимое или полностью обработал страницу.

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

Der Крупнейшая содержательная краска (LCP) учитывает момент появления крупнейшего значимого элемента контента в видимой области экрана. На странице товара это может быть, например, большое изображение товара. Сравнивайте показатель LCP только с соответствующими значениями LCP и фиксируйте условия работы браузера и сети; время до получения ответа от сервера измеряется на другом этапе.

Die Продолжительность сценария в свою очередь, не всегда соответствует времени загрузки отдельной страницы. Скрипт может вызывать несколько страниц, ожидать появления элементов и выполнять авторизацию. В случае проверок браузера Grafana-k6 указанная продолжительность выполнения скрипта, как правило, не включает фазу запуска k6; такие ограничения инструмента также следует учитывать при интерпретации результатов.

Показатель «Interaction to Next Paint» (INP) отражает время реакции на взаимодействия. При этом синтетический тест может анализировать только те взаимодействия, которые он фактически выполняет. Поэтому автоматический клик, выполняемый в заданных условиях, не дает представления о распределении результатов всех реальных посетителей, которые используют другие устройства, типы подключений и способы взаимодействия.

План измерений для целевых регионов

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

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

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

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

Настройка проверок и процедур тестирования

Для собственной тестовой страницы сначала можно создать HTTP-проверку, которая будет проверять ожидаемый код статуса. Добавь проверку браузера, которая загружает ту же страницу и ожидает появления ожидаемого заголовка. Первая проверка анализирует ответ конечной точки; вторая дополнительно показывает, отображается ли ожидаемое содержимое в браузере.

Для каждого запуска запишите место проведения измерения, время, результат и соответствующую продолжительность. Если проверка браузера завершилась неудачей при успешной проверке HTTP, проверьте содержимое и отображение, а не спешите сразу предполагать наличие конкретной ошибки. Также проверьте, не был ли заголовок изменен намеренно или не был ли установлен слишком короткий таймаут.

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

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

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

Сравнение инструментов и моделей работы

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

Grafana Cloud Синтетический мониторинг объединяет конфигурации проверок с общедоступными и частными пробами и поддерживает проверки браузеров на основе k6. Общедоступные и частные точки измерения дают ответы на разные вопросы о доступности. Заранее проверьте также доступную частоту проверок: для проверок браузеров и скриптов действуют другие ограничения, чем для некоторых простых проверок конечных точек.

Выполненное на месте Модуль браузера k6 это следует рассматривать отдельно. Для этого тебе понадобятся k6 и браузер на базе Chromium; локальный запуск скрипта не настраивает ни автоматические региональные точки мониторинга, ни постоянное расписание. Для распределенного мониторинга тебе придется дополнительно организовать выполнение, инфраструктуру и управление результатами либо воспользоваться подходящим сервисом.

AWS CloudWatch Synthetics выполняет запланированные тесты «Canaries». Эти Функция «Мультилокация» реплицирует Canary в выбранные регионы AWS и объединяет результаты в основном регионе. Перед внедрением проверьте указанные в документации минимальные версии поддерживаемых сред выполнения Node.js Puppeteer или Playwright, а также отдельную региональную доступность этой функции.

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

Грамотный анализ региональных результатов

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

При повторных успешных измерениях индикатор показывает Медиана среднее значение отсортированных результатов. Верхний процентиль, например 95-й, позволяет выявить более медленные прогоны: 95 процентов рассматриваемых значений не превышают этого значения. Запишите при этом период времени и количество измерений, чтобы было понятно, насколько широким является диапазон анализа.

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

Держи неудачные забеги отображаются отдельно, например, в виде количества ошибок и доли всех выполнений. В противном случае статистика времени загрузки, содержащая только успешные вызовы, может ложно показать, что регион с частыми таймаутами работает нормально. В случае сбоя без действительного значения времени загрузки нельзя просто использовать значение нормального времени загрузки.

Мониторинг реальных пользователей дополняет контролируемое тестирование данными об опыте реальных посетителей. Отчет Chrome UX предоставляет доступные полевые данные за скользящий 28-дневный период; в него не включены все страницы или группы пользователей. Поэтому этот долгосрочный обзор не заменяет актуальную синтетическую сигнализацию и не может быть непосредственно приравнен к отдельному тестовому запуску.

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

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

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

Если страница продукта загружается медленно только в одном регионе, начните со сравнения аналогичных сеансов и определите момент появления отклонения. Затем проверьте разрешение DNS, доставку через CDN, время загрузки ресурсов и время отклика сервера. Различные сетевые маршруты и близость к инфраструктуре могут влиять на региональные исходные показатели; одно только значение измерения ещё не позволяет определить причину.

В случае ресурсов других Origins подробности измерений браузера могут быть ограничены. Без соответствующего Timing-Allow-Origin-В заголовках отдельные значения API Resource Timing могут быть равны нулю. Это не всегда означает, что соединение было чрезвычайно быстрым; сначала проверь, какие данные предоставляет внешний сервер для измерения.

На следующем уровне анализа тебе нужно сопоставить время, регион и затронутый процесс с имеющимися логами и трасами. Так, например, можно выявить медленный запрос, не делая при этом из одной корреляции доказательства причины. О том, как взаимодействуют метрики, логи и трасы, рассказывается в статье по теме Наблюдаемость в хостинге.

Осуществлять мониторинг на постоянной основе

Начните с простых проверок конечных точек для важных общедоступных целей и дополните их целевыми тестами взаимодействия с браузером для критически важных для бизнеса страниц или процессов входа в систему. Проверка HTTP может выполняться чаще, в то время как более сложный тест в браузере проверяет выбранные функции. Интервалы следует выбирать исходя из желаемого времени обнаружения, ограничений сервиса и затрат, а не исходя из фиксированного значения в минутах.

Определите для каждого проверки Компетенция: Кто получает сигнал тревоги, кто проверяет соответствующую службу и кто отвечает за точку измерения? Также укажите, когда сигнал тревоги передается дальше и где можно найти соответствующие результаты. Проверка без реагирования на повторяющиеся ошибки, конечно, предоставляет данные, но не устраняет инцидент.

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

Относитесь к скриншотам и протоколам как к потенциально конфиденциальным данным: они могут содержать информацию о сеансе или данные из приложения. Ограничьте доступ и срок хранения в соответствии с целью и проверьте, что именно записывается в ходе тестирования. Для входа в систему используйте тестовую учетную запись с ограниченными правами и храните учетные данные в виде секретов, а не в скрипте.

Регулярно проверяйте, не Места проведения измерений соответствуют ли они вашим целевым рынкам и позволяют ли тарифы, хранение данных и требования к защите данных продолжать работу. В случае самостоятельно управляемых пробных серверов к этому добавляются обновление и мониторинг среды. Один только запущенный локально скрипт браузера k6 ещё не обеспечивает постоянную распределённую инфраструктуру мониторинга.