Веб- и мобильные приложения зависят от технических шагов, выполнение которых пользователи ожидают в каждом сценарии: загрузка результатов поиска, вход в систему, сохранение способа оплаты или обработка платежа. Datadog Real User Monitoring (RUM) собирает подробные события об этих взаимодействиях, включая просмотры, действия, ресурсы и ошибки. Однако анализ этих событий по отдельности не всегда дает прямой ответ на более фундаментальные вопросы: сработал ли критический шаг приложения и сколько времени это заняло?
Мониторинг операций (Operations Monitoring), включенный в состав RUM без дополнительной платы, предоставляет командам способ отслеживать шаги, управляемые приложением, на основе трафика реальных пользователей. Операция — это технический шаг, который выполняет приложение и который пользователи ожидают успешно завершить. Например, «оформление заказа» может представлять более широкий пользовательский сценарий, в то время как «ввод платежных данных» и «обработка платежа» являются операциями с измеримым началом, результатом и длительностью. Определяя операции, вы можете независимо отслеживать их доступность и задержку, сохраняя при этом понимание их роли в более широком пользовательском опыте.
В этой статье мы покажем вам, как:
- Определять и мониторить критические операции в RUM
- Отслеживать работоспособность операций с помощью целевых показателей уровня обслуживания (SLO)
- Исследовать деградации операций с помощью Bits AI
- Связывать операции с пользовательскими сценариями для сквозного мониторинга пользовательского опыта
Определение и мониторинг критических операций в RUM
Четко определенная операция изолирует работу, управляемую приложением, чтобы вы могли измерять ее надежность без влияния несвязанного поведения пользователей. Рассмотрим процесс оформления заказа в интернет-магазине: пользователь может потратить несколько минут на раздумья о покупке, но когда он нажимает кнопку «Оплатить сейчас», приложение должно надежно обработать этот платеж в приемлемые сроки. Вы можете определить «обработку платежа» как операцию, которая начинается при отправке платежа пользователем, завершается успешно при подтверждении завершения платежа приложением и завершается с ошибкой, если бэкенд возвращает код состояния ошибки.
Сохранение этих границ сосредоточенными на работе, управляемой приложением, помогает сделать измерения задержки более репрезентативными для производительности приложения. Если операция включает время ожидания чтения контента пользователем или принятия решения, ее длительность может увеличиваться, даже когда приложение работает ожидаемым образом. Аналогично, для каждой операции должны быть записаны начало и конец. В качестве передовой практики поддерживайте уровень таймаутов на уровне 1% или ниже, чтобы Datadog мог классифицировать как минимум 99% начатых операций как успешные или неуспешные. Дополнительные рекомендации см. в разделе лучших практик настройки операций RUM.
Datadog предоставляет несколько способов определения операций. Если у вас есть полный контроль над кодом фронтенда, вы можете использовать API RUM SDK для настройки того, когда операция начинается, завершается успешно или завершается с ошибкой. Вы также можете добавлять пользовательские атрибуты для предоставления дополнительного контекста о каждой операции. Если вы не хотите определять операции в коде приложения, вы можете использовать Datadog MCP Server для создания операций в рамках совместимого с MCP рабочего процесса или воспользоваться RUM Operations API для создания их программно или массово. Вы также можете создавать операции в пользовательском интерфейсе Datadog, сопоставляя существующие события RUM с условиями, которые отмечают начало, успех или неудачу операции.
После определения операции Datadog группирует вхождения с одинаковым именем в каталоге операций. В этом центральном месте вы можете отслеживать важные технические взаимодействия независимо от какого-либо более широкого сценария. Datadog также генерирует готовые метрики из вашего полного, полученного, невыборочного трафика RUM: rum.measure.operation отслеживает объем операций, а rum.measure.operation.duration измеряет время между началом и концом операции. Вы можете детализировать эти сигналы по таким измерениям, как имя операции, статус и причина сбоя.
События операций также дают вам больше контроля над тем, какие данные реальных пользователей вы сохраняете и исследуете. Например, вы можете настроить фильтры хранения RUM для сохранения сеансов, в которых критическая операция завершилась с ошибкой или превысила ожидаемую длительность. Затем вы можете запрашивать события операций из сохраненных сеансов RUM в обозревателе RUM Explorer для проверки их атрибутов и окружающего контекста сеанса.
Отслеживание работоспособности операций с помощью SLO
Сценарий оформления заказа может не завершиться из-за того, что пользователь передумал, но операция «обработка платежа» имеет более четкий технический результат: приложение либо успешно обрабатывает запрос, либо нет. В результате операции полезны для установки целей надежности в отношении поведения приложения, которое контролирует ваша команда.
Вы можете создавать отдельные SLO для доступности и задержки операции. SLO доступности измеряет, успешно ли завершается операция, а SLO задержки измеряет, завершается ли она в пределах ожидаемой длительности. Разделение этих целей помогает отличить стабильно работающую, но слишком медленную операцию от той, которая работает быстро, когда функционирует, но сбоит слишком часто.
Например, команда интернет-магазина может создать SLO доступности для своей операции «обработка платежа», чтобы измерять процент успешно завершенных попыток оплаты. Команда может отдельно создать SLO задержки, чтобы измерять, завершаются ли успешные платежи в пределах ожидаемого порога производительности. Лучшие практики Datadog по созданию SLO для операций RUM включают рекомендуемые запросы и руководства по выбору подходящих целевых показателей.
Исследование деградаций операций с помощью Bits AI
SLO и метрики операций сообщают вам, когда важное взаимодействие работает некорректно. Следующий вопрос — почему. Вместо того чтобы вручную переключаться между ошибками, сеансами, каскадами ресурсов, трейсами и другими телеметрическими данными, вы можете использовать Bits Investigation for Operations (в настоящее время в режиме предварительного просмотра) для анализа сигналов, связанных с деградацией.
Bits исследует деградации операций, такие как ошибки, таймауты, отказы, регрессии задержки и стабильно высокую задержку. В ходе расследования инструмент анализирует соответствующие телеметрические данные для выявления потенциальных причин на фронтенде, бэкенде и в сети. Затем он выводит вспомогательные данные, такие как связанные ошибки, эндпоинты, расположения кода, сеансы и информацию о бэкенде.
Связывание операций с пользовательскими сценариями для сквозного мониторинга пользовательского опыта
Операции полезны сами по себе, но некоторые технические шаги также являются критическими частями более крупного рабочего процесса пользователя. Мониторинг сценариев (Journey Monitoring) позволяет связать эти два уровня пользовательского опыта. Инженерные команды могут продолжать мониторинг каждой операции независимо в интерфейсе RUM Operations Monitoring и одновременно связывать их с соответствующим сценарием, чтобы понять, как эти технические шаги соотносятся с более широким рабочим процессом.
Связывание необязательно: операция не обязательно должна принадлежать journey, чтобы предоставлять полезные сигналы о доступности, задержке и SLO. Вы можете связать операцию при ее создании, а затем добавлять или удалять связи с journey по мере развития мониторинга. Когда вы создаете операцию из отчета с деталями journey, Datadog связывает ее с этим journey.
Явное связывание операций с journey устанавливает взаимосвязь, которая выходит за рамки корреляции на этапе запроса. Корреляция на основе частоты может быть менее полезна для journey с низким трафиком или низкой конверсией, а важная операция может стать менее заметной, поскольку объем ее выполнения падает во время проблемы. Явная связь определяет операцию как критическую часть journey независимо от трафика или объема выполнения.
При принятии решения о том, какие операции связать с journey, начните с технических шагов, которые оказывают наибольшее влияние на то, смогут ли пользователи завершить journey. В частности, важен последний шаг, контролируемый приложением. Для journey оформления заказа этим последним шагом может быть обработка платежа после того, как пользователь нажимает «Оплатить сейчас». Для входа в систему это может быть аутентификация пользователя после отправки им действительных учетных данных. Дополнительные сведения о настройке journey и работе со связанными операциями см. в документации по мониторингу journey (Journey Monitoring).
Начните мониторинг технических шагов, лежащих в основе критически важных пользовательских сценариев
Операции RUM предоставляют инженерным командам специальный способ измерения доступности и задержки контролируемых приложением технических шагов, которые лежат в основе важных пользовательских сценариев. Вы можете установить SLO для этих взаимодействий, исследовать ухудшения с помощью Bits AI и подключать операции к мониторингу journey (Journey Monitoring), когда вам нужно понять их роль в более широком рабочем процессе пользователя. Для получения дополнительной информации ознакомьтесь с документацией по мониторингу операций (Operations Monitoring) и лучшими практиками настройки операций RUM.
Если у вас еще нет учетной записи Datadog, вы можете зарегистрироваться для 14-дневного бесплатного пробного периода, чтобы начать работу с мониторингом операций (Operations Monitoring).
