Хорошо спроектированные целевые уровни обслуживания (SLO) помогают отслеживать показатели, которым должно соответствовать ваше приложение для обеспечения успешного пользовательского опыта (UX). Чтобы отслеживать производительность в отношении этих SLO, многие SRE-команды обращаются к мониторингу реальных пользователей (RUM) и синтетическому мониторингу для своих индикаторов уровня обслуживания (SLI), поскольку эти формы данных обеспечивают более прямые измерения UX, чем метрики производительности бэкенда. SLI на основе RUM измеряют события из реальных пользовательских сессий, в то время как синтетические SLI используют запланированные тесты для симуляции критически важных пользовательских сценариев.
Здесь, в Datadog, данные об использовании нашего продукта показывают увеличение количества созданных клиентами синтетических SLO на 273% за последний год (август 2025 г. – август 2026 г.).
Тем не менее, не все ориентированные на пользователя SLI одинаковы. Понимание того, когда выбирать между данными реальных и синтетических пользователей, важно для создания эффективных SLI, особенно по мере того, как ваши SLO развиваются в ответ на меняющиеся цели. В этой статье мы рассмотрим:
- Когда вам следует рассмотреть возможность переконфигурации ваших SLI для использования RUM и синтетических данных
Когда вам следует рассмотреть возможность переконфигурации ваших SLI для использования RUM и синтетических данных
- Как выбрать между синтетическими данными и данными RUM для ваших SLI
Как выбрать между синтетическими данными и данными RUM для ваших SLI
- Как эффективно мониторить ваши SLI на основе RUM и синтетических данных
Как эффективно мониторить ваши SLI на основе RUM и синтетических данных
Когда следует переконфигурировать ваши SLI?
По мере изменения вашего приложения и пользовательских сценариев ваши SLI могут перестать давать надежную картину влияния на пользователей. Несколько распространенных признаков могут помочь вам решить, когда использовать другие источники данных, особенно когда речь идет о внедрении синтетических SLI или SLI на базе RUM:
Ваши цели по надежности изменились
Команда может сначала установить цели по надежности, связанные с доступностью и производительностью приложения, а затем расширить эти цели по мере взросления приложения, чтобы охватить конкретное поведение пользователей. Чтобы оценить, соответствует ли их приложение этим целям, команде понадобятся SLI, которые измеряют, могут ли пользователи выполнять критически важные действия. Для приложения электронной коммерции это может означать отслеживание процента успешных оформлений заказов.
В ваших SLI отсутствуют проблемы на критических пользовательских путях
SLO должны отражать реальное состояние ваших сервисов. Если ваши SLO показывают, что вы достигаете своих целей во время крупных инцидентов или на фоне снижения ключевых показателей эффективности (KPI), вам, вероятно, необходимо переконфигурировать свои SLI для обеспечения лучшего покрытия. Для этого вам нужно будет переоценить пути, которые вы отслеживаете, чтобы убедиться, что они соответствуют тому, что пользователи на самом деле делают в вашем приложении, а не идеальным маршрутам, которые вы разработали изначально.
Ваши алерты по скорости сгорания бюджета нестабильны в периоды низкого трафика
Чтобы сбалансировать долгосрочный анализ надежности с быстрым обнаружением проблем, команды часто используют многооконные алерты по скорости сгорания (burn rate), которые включают как длинные, так и короткие временные окна.
Короткое окно может выглядеть как соотношение ошибок к общему количеству запросов, зафиксированное в течение 5-минутного периода времени. Поскольку в периоды низкого трафика общее количество запросов часто ниже, это может приводить к небольшим знаменателям, которые могут вызывать высокие показатели ошибок в течение этого короткого окна. Пять ошибок оказывают большее влияние на ваш бюджет, когда у вас 100 запросов за 5 минут, по сравнению с 10 000 запросов.
Это означает, что низкий трафик может сделать алерты по скорости сгорания более чувствительными к отдельным сбоям и привести к усталости дежурных от алертов. Синтетические данные могут помочь вам лучше измерять работоспособность вашего приложения независимо от колебаний трафика.
Как выбрать между синтетическими данными и данными RUM для ваших SLI
Вы определили, что ваши SLI нуждаются в метриках, которые надежно отражают ваш UX. Теперь вам нужно выяснить, в каких случаях RUM или синтетические данные имеют больше смысла.
Определение того, следует ли основывать ваши метрики на синтетических данных или данных реальных пользователей, не всегда является очевидным выбором. Хотя может показаться, что RUM всегда будет давать наиболее реалистичную картину вашего приложения, внешние факторы, такие как боты, изменения трафика и конфигурация браузера, могут привносить шум, который скрывает более общие тенденции.
Ваша конкретная настройка SLI, скорее всего, будет зависеть от целей вашей команды, размера и аудитории вашего приложения, а также от типа получаемого вами трафика. В таблице ниже описаны некоторые факторы, которые следует учитывать при принятии решения. Тем не менее, в целом вам следует использовать синтетические SLI для обеспечения стабильности и данные RUM для понимания реального пользовательского опыта.
Используйте синтетические SLI для обеспечения стабильности
Синтетические SLI используют тесты для оценки работоспособности вашего приложения. Эти тесты выполняются с заданными пользователем интервалами, которые могут длиться от 30 секунд до недели. Многие команды измеряют синтетические SLI с помощью мониторов, которые периодически проверяют последние данные тестов, обычно примерно раз в минуту. Мониторы сравнивают результаты тестов с настроенными условиями оповещения, чтобы определить, следует ли перейти в состояние АВАРИИ (ALERT). Для SLO на основе мониторов потребление бюджета ошибок зависит от того, как долго монитор синтетического теста остается в состоянии ALERT в течение заданного окна. Синтетические SLI также могут использовать SLO на основе временных срезов (time slice SLO), которые вычисляют время безотказной работы на основе состояния метрики без необходимости использования монитора.
Эти временные ограничения ограничивают синтетические SLI двумя способами:
- Ограниченная гранулярность: гранулярность синтетических SLI привязана к частоте выполнения тестов и оценок монитора. Синтетический тест, который запускается каждые 15 минут, может быть хорош для мониторинга общего состояния здоровья системы, но вы упустите более мелкие, кратковременные ошибки, которые возникают за пределами этого временного окна. Если эти крошечные ошибки накапливаются за выделенное по бюджету окно, вы можете в итоге получить SLO, которые показывают, что все в порядке, даже когда пользователи сталкиваются с проблемами.
Ограниченная гранулярность: гранулярность синтетических SLI привязана к частоте выполнения тестов и оценок монитора. Синтетический тест, который запускается каждые 15 минут, может быть хорош для мониторинга общего состояния здоровья системы, но вы упустите более мелкие, кратковременные ошибки, которые возникают за пределами этого временного окна. Если эти крошечные ошибки накапливаются за выделенное по бюджету окно, вы можете в итоге получить SLO, которые показывают, что все в порядке, даже когда пользователи сталкиваются с проблемами.
- Ограниченная точность: ограниченная гранулярность синтетических SLI также приводит к проблемам при расчете точности. Короткие окна бюджета ошибок для высокоточных SLO имеют невероятно малые допустимые погрешности. Например, 7-дневное окно с целевым показателем 99,999% имеет бюджет ошибок всего в 6 секунд. Поскольку каждая оценка синтетического монитора представляет собой минуту работы системы, один неудачный запуск исчерпает весь ваш 7-дневный бюджет.
Ограниченная точность: ограниченная гранулярность синтетических SLI также приводит к проблемам при расчете точности. Короткие окна бюджета ошибок для высокоточных SLO имеют невероятно малые допустимые погрешности. Например, 7-дневное окно с целевым показателем 99,999% имеет бюджет ошибок всего в 6 секунд. Поскольку каждая оценка синтетического монитора представляет собой минуту работы системы, один неудачный запуск исчерпает весь ваш 7-дневный бюджет.
Тем не менее, запланированные интервалы дают синтетическим тестам преимущество: они позволяют синтетическим SLI обеспечивать стабильное представление о работоспособности и производительности системы независимо от колебаний трафика. Поскольку синтетические тесты выполняются многократно каждый день в течение всего года, их расчеты не зависят от падения числа запросов в периоды спада, что дает вам надежное представление о базовом состоянии системы. Такая стабильность делает их полезными для регрессионного тестирования, позволяя оценивать влияние новых релизов или крупных инцидентов на функциональность приложения.
Сочетание ограниченной детализации и большей стабильности делает синтетические данные идеальными для мониторинга доступности критически важных пользовательских сценариев от начала до конца. Например, вы можете использовать синтетические данные для разработки SLO для сценария публикации в социальной сети. Этот сценарий может включать вход в учетную запись, создание черновика публикации, добавление фотографий и музыки и, наконец, публикацию. Здесь проблемы на отдельных этапах имеют значение лишь постольку, поскольку они влияют на весь путь в целом.
Тем не менее, синтетические тестовые данные не измеряют реальную производительность вашего приложения в реальных условиях.
Используйте данные RUM для оценки пользовательского опыта
В отличие от периодических снимков, предоставляемых синтетическими SLI, SLI на основе RUM дают непрерывную картину активности реальных сеансов. В ходе каждого сеанса ваша платформа RUM собирает соответствующие метрики по мере их возникновения и обновляет агрегированные расчеты SLI. Такие функции, как Datadog RUM without Limits, позволяют рассчитывать RUM SLI, используя предварительно выбранные данные сеансов для получения еще более полной картины производительности приложения.
Непрерывные метрики RUM обеспечивают большую точность и детализацию по сравнению с синтетическими тестами. Однако они не обязательно обеспечивают безошибочную отчетность. Данные RUM особенно чувствительны к:
- Проблемам надежности: в отличие от синтетических тестов, которые проводятся на тщательно контролируемых браузерах и устройствах, данные RUM подвержены влиянию реальных условий, которые могут повлиять на сбор данных, таких как блокировщики рекламы и боты.
Проблемам надежности: в отличие от синтетических тестов, которые проводятся на тщательно контролируемых браузерах и устройствах, данные RUM подвержены влиянию реальных условий, которые могут повлиять на сбор данных, таких как блокировщики рекламы и боты.
- Колебаниям трафика: изменения трафика могут легко повлиять на данные RUM, делая их зависимыми от всего — от моделей ежедневного использования до сезонных трендов.
Колебаниям трафика: изменения трафика могут легко повлиять на данные RUM, делая их зависимыми от всего — от моделей ежедневного использования до сезонных трендов.
В совокупности эти факторы могут исказить результаты RUM, требуя от вас фильтрации не пользовательского трафика и учета погрешностей выборки и сбора. Вы также захотите сегментировать данные RUM по таким измерениям, как браузер, регион и устройство, чтобы выявить тенденции, которые могут скрывать агрегированные результаты.
Тем не менее, реальные препятствия также являются причиной того, почему мониторинг RUM SLI так важен. Данные RUM могут выявить скрытые условия, которые ваши идеализированные синтетические тесты могут упустить из виду. Фактическое взаимодействие с пользователем часто происходит на устаревших устройствах, в медленных сетях и связано с неожиданным пользовательским вводом.
В результате RUM SLI часто лучше всего подходят для детального просмотра особенно важных действий. Например, вы можете отслеживать частоту успешных платежей или регистраций учетных записей. Эти действия важны как для общей удовлетворенности пользователей, так и, зачастую, для ключевых бизнес-целей. Поэтому даже небольшое падение заслуживает внимания.
Мониторинг данных RUM и синтетических данных вместе для получения полной картины
Поскольку данные о реальных и синтетических пользователях дают вам представление о различных аспектах пользовательского опыта (UX), вы должны использовать их в качестве взаимодополняющих SLI.
Синтетические тесты дают вам общее представление о том, поддерживает ли ваше приложение пользовательские сценарии на базовом уровне. Они помогают убедиться, что пользователи могут перемещаться по вашему приложению, не сталкиваясь с ошибками или узкими местами. Между тем, для наиболее важных шагов в этих сценариях вы можете использовать RUM SLI, чтобы увидеть, могут ли реальные пользователи выполнять важные операции в реальных условиях.
Эти разные точки зрения отражены в инструментах, которые вы используете для отслеживания и оценки своих SLI. Для синтетических SLI вы захотите сгруппировать свои тестовые данные в тестовые наборы путей, чтобы вы могли легко оценить сценарии, которые страдают больше всего. Полезные визуализации включают карты топологии, которые помогают понять различные маршруты, которые пользователи выбирают для выполнения определенной задачи, а также воронки, отображающие коэффициенты конверсии, что позволяет увидеть влияние сценария на общий UX.
В Datadog Journey Monitoring эти данные организованы в виде общего обзора, на котором отображаются результаты Synthetics SLO для пользовательских сценариев, помогая вам быстро обнаруживать деградировавшие потоки.
Вы можете контекстуализировать эти нарушенные SLO с помощью карт топологии и воронок конверсии. Неудачные тесты, связанные с каждым сценарием, выделяются, а сводки обнаруженных проблем предоставляются посредством интеграции с Bits Investigation.
Для RUM SLI важно иметь более глубокое представление об отдельных действиях. Вам понадобятся графики временных рядов метрик запросов, включая средний показатель успешности и время выполнения, чтобы помочь определить, представляют ли нарушенные SLO внезапные инциденты или постепенную деградацию. Диаграммы путей также полезны, поскольку они помогают контекстуализировать отдельные действия в рамках более масштабных путей и более эффективно отлаживать проблемы.
Каждый сценарий в Journey Monitoring включает SLO наряду с сопутствующими операциями RUM. Операции RUM — это критические моменты в пути пользователя, которые должны быть производительными и доступными для успешной работы вашего приложения. В результате операции обычно сопоставляются как минимум с одним RUM SLO. Связывая SLO с операциями, вы можете группировать RUM SLO по функциональности, к которой они относятся. Вы можете просматривать как операции, так и их SLO в Journey Monitoring вместе с графиками временных рядов и диаграммами путей, которые помогают в устранении неполадок.
Для более глубокого расследования вы можете перейти непосредственно к Datadog Operations Monitoring. Здесь вы можете получить доступ к подробным разбивкам каждого SLO в рамках ваших операций, включая визуализации потребления бюджета ошибок и скорости исчерпания (burn rate).
Если вам нужно создать новый RUM SLO для операции, вы можете сделать это, используя готовые метрики, которые отслеживают доступность и задержку.
Начало работы с RUM и синтетическими SLI
По мере развития команд и сервисов SLO часто перестают за ними поспевать. Объединяя ваши RUM и синтетические SLI в единое представление, Datadog Journey Monitoring упрощает внедрение и устранение неполадок SLI, ориентированных на пользователя, для получения более точных и надежных отчетов о вашем пользовательском опыте.
Вы можете прочитать нашу документацию, чтобы узнать больше о создании RUM SLO на основе метрик, а также синтетических SLO на основе мониторов и срезов времени в Datadog. Вы также можете
Или, если вы новичок в Datadog, вы можете зарегистрироваться для бесплатной 14-дневной пробной версии.
