Разработка приложений для мониторинга реальных пользователей
После установки ЕдиногоАгента в режиме полнофункционального мониторинга на хост, он отслеживает все приложения, работающие на этом хосте. В качестве отправной точки все данные мониторинга инкапсулируются в приложение-заглушку под названием «My web application». Мы предлагаем это приложение-заглушку для большей гибкости — вы сами решаете, как организовать свои приложения.
Ключ-АСТРОМ предлагает следующие подходы к определению вашего приложения для управления ресурсами пользователя (RUM).
| Подход к обнаружению приложений | Тип внедрения JavaScript RUM | Когда использовать |
|---|---|---|
| Предложенный подход | Автовнедрение | Когда ваши веб-приложения легко идентифицируются по доменам, и вы хотите создать приложение на основе уже перехваченного трафика мониторинга RUM. |
| Подход к обнаружению приложений на основе правил | Автовнедрение | Когда вам нужно создать новые приложения или когда разделения трафика по доменам недостаточно, используйте правила обнаружения приложений, чтобы определить более сложные шаблоны для группировки трафика мониторинга RUM по приложениям. |
| Ручной подход (также известный как «мониторинг без агентов») | Ручное внедрение | Когда у вас нет доступа к хосту вашего веб-приложения, но есть доступ к коду приложения. |
Приложения на основе Java Servlet
Если вы используете RUM для приложения на основе Java Servlet, обязательно перезапустите процесс после завершения первоначальной настройки. Датчик RUM не будет включен до перезапуска.
Предложенный подход
Приложение-заглушка «My web application» агрегирует трафик со всех обнаруженных доменов. Это приложение может служить отправной точкой для сопоставления идентифицированных доменов с отдельными приложениями в вашей среде.
- Перейдите в Веб-приложения.
- Выберите приложение-заглушку «My web application».
- Прокрутите вниз, чтобы найти панель «Топ-3 действий» .
На этой панели отображаются домены с наибольшим количеством действий пользователей, обнаруженных ЕдинымАгентом в вашей среде. - Выберите Просмотреть подробную информацию.
- В списке Наиболее популярные домены выберите кнопку со стрелкой в столбце «Перенос домена», чтобы развернуть запись о домене.
- Выберите один из вариантов ниже:
- Чтобы добавить новое приложение, выберите Создать новое приложение. Ваше приложение будет создано и отобразится на странице Приложения.
- Чтобы добавить домен к существующему приложению, выберите «Перенос».
Поскольку вам может потребоваться более осмысленное название для вашего приложения, замените автоматически сгенерированное имя на собственное, выбранное вами название приложения.
Переименовать приложение
- Перейдите в Веб-приложения.
- Выберите приложение, которое хотите настроить.
- В правом верхнем углу страницы обзора приложения выберите Дополнительно ( … ) > Редактировать.
- В настройках приложения выберите Основное > Название приложения.
- Введите желаемое название в поле вверху страницы. Обратите внимание, что названия приложений должны быть уникальными.
Возможные проблемы предложенного подхода
Неинструментированный компонент переписывает URL-адрес. При следовании предложенному подходу для вашего нового или обновленного приложения автоматически создается правило обнаружения приложения. Это правило сопоставляет действия пользователя, зафиксированные на домене, с вашим приложением. ЕдиныйАгент использует часть URL-адреса, относящуюся к хосту, для определения домена. Если неинструментированный компонент между браузером и первым инструментированным уровнем переписывает хост, вам необходимо настроить определение имени хоста. В противном случае ЕдиныйАгент может не иметь возможности применить ваше правило обнаружения приложения.
Действия по-прежнему привязаны к приложению-заглушке. Если действия пользователя по-прежнему привязаны к моему веб-приложению вместо вашего приложения, обратитесь к разделу Как быстро вступают в силу изменения правил обнаружения приложений? (ниже).
Подход к обнаружению приложений на основе правил
Если вы хотите создать больше приложений, изменить существующие сопоставления приложений или определить более сложные правила, основанные не только на доменах, но и на URL-адресах, вы можете использовать страницу настроек обнаружения приложений.
URL-адреса, используемые для определения приложения, имеют следующую структуру scheme://host:port/path?query, где строка запроса является необязательной, а порты по умолчанию для HTTP 80 и HTTPS 443 опущены. URL-адрес не включает возможный идентификатор фрагмента, как в scheme://host:port/path?query#fragment, поскольку правила определения приложения оцениваются на стороне сервера приложения, а идентификатор фрагмента используется только браузером и не добавляется к веб-запросам.
Добавить правило обнаружения приложения
- Перейдите в Настройки > Веб- и мобильный мониторинг > Обнаружение приложений. Отобразится список правил обнаружения приложений.
Для каждого приложения, определенного с использованием предложенного подхода, правило обнаружения автоматически генерируется и добавляется в конец списка. Правила применяются последовательно, при этом правила в начале списка имеют приоритет над правилами, перечисленными ниже. - Выберите Добавить правило обнаружения.
- Используйте параметры, представленные на странице, чтобы создать подходящее правило обнаружения для вашего приложения.
Вы можете применять правила к новым или существующим приложениям, а также создавать правила на основе URL-адреса или домена (хоста) вашего приложения. - Нажмите Сохранить, чтобы создать правило обнаружения приложений.
Правило будет размещено в самом конце списка правил обнаружения приложений. НеобязательноВыберите и удерживайте строку рядом с названием правила, затем перетащите правило вверх или вниз в списке, чтобы изменить его приоритет.
| В каждой среде можно создать до 1000 правил обнаружения приложений. |
Возможные проблемы подхода, основанного на правилах обнаружения приложений.
Неинструментированный компонент переписывает URL-адрес. Если неинструментированный компонент между браузером и первым инструментированным уровнем переписывает URL-адрес, необходимо принять особые меры (подробнее см. раздел Что делать, если неинструментированный компонент переписывает части URL-адреса? (ниже). В противном случае ЕдиныйАгент может не иметь возможности применить ваши правила обнаружения приложений.
Действия по-прежнему привязаны к предыдущему приложению. Если действия пользователя по-прежнему привязаны к предыдущему приложению вместо требуемого, обратитесь к разделу Как быстро вступают в силу изменения правил обнаружения приложений? (ниже).
Часто задаваемые вопросы о предлагаемых и применяемых подходах к правилам обнаружения
Как Ключ-АСТРОМ применяет ваши правила обнаружения приложений?
Правила обнаружения приложений оцениваются на стороне сервера вашего приложения ЕдинымАгентом на первом инструментированном уровне — том, который находится ближе всего к браузеру. Результат передается последующим ЕдинымАгентам с помощью заголовка x-astromkey-application. При таком подходе любое переписывание URL-адресов, которое может происходить между инструментированными серверными уровнями вашего приложения, не влияет на результат обнаружения приложения.
ЕдиныйАгент добавляет параметр app к JavaScript-коду RUM, внедряемому в HTML-код вашего приложения. Этот параметр содержит идентификатор обнаруженного приложения.
При отправке запросов маяков с зафиксированными действиями пользователя JavaScript-код RUM включает этот параметр app в строку запроса.
В кластере Ключ-АСТРОМ параметр app в строке запроса маяка используется для назначения действий пользователя приложениям.
Для проверки идентификатора приложения и сравнения его с параметром app.
- В Ключ-АСТРОМ перейдите в раздел Веб-приложения.
- Выберите приложение.
- Проверьте URL страницы, на которой вы сейчас находитесь. Этот URL содержит параметр
uemapplicationId, например,uemapplicationId=APPLICATION-4CC1C5694BF9B3AB. Его значение без префиксаAPPLICATION-— это идентификатор приложения, который вы ищете.
Что делать, если неинструментированный компонент перезаписывает части URL-адреса?
Как поясняется в разделе Как Ключ-АСТРОМ применяет правила обнаружения приложений? (выше), ваши правила обнаружения приложений оцениваются ЕдинымАгентом на первом инструментированном уровне вашего приложения. Однако между браузером и первым инструментированным уровнем вашего приложения может находиться неинструментированный компонент, например, обратный прокси-сервер или балансировщик нагрузки, который переписывает URL-адрес. В результате URL-адрес, используемый для обнаружения приложения, отличается от URL-адреса, первоначально запрошенного браузером. В этом сценарии необходимо учитывать особые моменты.
Перезапись хоста
Вы можете настроить такие компоненты, как прокси-серверы и балансировщики нагрузки, для передачи исходной информации о хосте на бэкэнд в заголовке запроса, например, в заголовке X-Forwarded-Host или Forwarded. ЕдиныйАгент может получить исходный хост из одного из этих заголовков или из любого проприетарного заголовка, имеющего тот же формат, что и X-Forwarded-Host.
Для использования исходного имени хоста при определении приложения.
- Настройте свой неинструментированный компонент так, чтобы он добавлял заголовок, перенаправляющий исходное имя хоста (если он еще этого не делает по умолчанию).
Например, если исходное имя хоста, запрошенное браузером, былоwww.example.com, и ваш неинструментированный компонент перенаправил запрос на внутренний хостbackend.com, то компонент должен добавить заголовок запроса, который передаетwww.example.com, как показано на диаграмме последовательности выше. - В Ключ-АСТРОМ перейдите в Настройки > Веб- и мобильный мониторинг > Определение имени хоста.
- Если заголовок, добавленный вашим компонентом, отсутствует в списке, выберите Добавить HTTP-заголовок.
- Заголовки запроса в списке обрабатываются последовательно, при этом приоритет имеют заголовки, находящиеся вверху списка. Переместите новую запись выше заголовка
Host, который является частью каждого HTTP/1.1-запроса.
В качестве альтернативы вы также можете использовать внутреннее имя хоста в правиле обнаружения приложений. Однако ЕдиныйАгент использует результат определения имени хоста не только для обнаружения приложений, но и для автоматического определения домена cookie. Поэтому, если вы не настроите определение имени хоста, как описано выше, вам необходимо настроить домен cookie вручную, как описано в разделе Ручная настройка домена cookie. Рекомендуемый вариант — eTLD+1 домена, который ЕдиныйАгент определяет автоматически.
Перезапись URL-пути
В отличие от хостовой части URL-адреса, здесь нет функции для определения исходного пути URL-адреса, поскольку компоненты редко устанавливают заголовки, передающие исходный путь последующим уровням. Поэтому вы не можете использовать часть пути URL-адреса, которая удаляется при перезаписи URL-адреса в неинструментированном компоненте, в правиле обнаружения приложения.
Как быстро вступают в силу изменения правил обнаружения приложений?
При изменении правил обнаружения приложений обновленные правила обычно передаются в ЕдиныйАгент в течение минуты. ЕдиныйАгент классифицирует входящие запросы в соответствии с настройками правил обнаружения приложений и appсоответствующим образом устанавливает параметр во внедренном JavaScript-коде RUM. Затем JavaScript-код RUM отправляет свои маяки, используя обновленный параметр app, определяющий, как классифицируются захваченные действия пользователя. Для получения более подробной информации см. раздел Как Ключ-АСТРОМ применяет правила обнаружения приложений? (выше).
Следующие факторы могут замедлить вступление в силу обновленных правил обнаружения приложений:
- HTML-код предоставляется через CDN или другой кэш. В этом случае ЕдиныйАгент может внедрить JavaScript RUM только тогда, когда HTML-код будет удален из кэша и повторно запрошен с подключенного исходного сервера.
- Приложение задает длительный срок действия HTML-документа, используя заголовок ответа
Expiresили директивуmax-ageзаголовка ответаCache-Control. Кэш может хранить его в течение времени, указанного в этих заголовках, включая внедренный параметрapp. Изменение правил обнаружения приложения не может быть отражено немедленно, поскольку кэш не отправляет запрос на исходный сервер, пока срок действия документа не истек. - Если приложение не указывает явное время истечения срока действия, это не означает, что страница не может быть кэширована (см. RFC7234: Расчет эвристической актуальности). Кэш может использовать страницу без повторной проверки до тех пор, пока считает это целесообразным, если только ответ не содержит директив, которые этому препятствуют, например,
Cache-Control: no-cache. - Одностраничные приложения динамически перезаписывают текущую страницу вместо загрузки новой страницы с сервера. Если HTML-код был загружен во вкладку браузера до изменения правил обнаружения приложений, то классификация захваченных действий пользователя XHR пока не отражает обновленную конфигурацию. Это меняется сразу после обновления страницы.
Безагентный подход RUM
Если у вас нет доступа к веб-серверу — и, следовательно, вы не можете установить OneAgent на хост, — но есть доступ к коду вашего приложения, выбирайте RUM без агента.
| Для некоторых технологий автоматическое внедрение JavaScript-кода RUM не поддерживается, даже если вы можете установить ЕдиныйАгент. Например, хотя ЕдиныйАгент может отслеживать серверную часть приложения Heroku, он не может внедрять JavaScript-код RUM на страницы приложения. В этом случае вам необходимо использовать RUM без агента и вручную добавлять JavaScript-код RUM на страницы вашего приложения. |
Методы и рекомендации
- Настраивайте свои приложения на основе принадлежности к команде, чтобы вы могли легко использовать менеджмент зоны для ограничения доступа.
- Возможно, целесообразно определять приложения на основе используемого технологического стека, чтобы применять правильные настройки и упрощать управление конкретными параметрами. Например, активация поддержки определенных XHR-фреймворков обычно требуется только для определенных частей большого приложения и для определенных правил именования действий пользователей. Это может помочь разделить такие большие приложения на более мелкие в зависимости от используемых технологий или принадлежности к команде.
- My web app -заглушка
- Избегайте переименования приложения-заглушки My web app, поскольку оно включает в себя все действия пользователей на всех доменах, которые не включены в правило обнаружения приложений. Если вы переименуете My web app, его будет сложно отличить от других ваших приложений.
- Удалить это приложение-заглушку невозможно.
- Если вы не можете найти приложение-заглушку My web app, возможно, кто-то переименовал его. Чтобы найти его, откройте любое другое приложение и замените идентификатор приложения в URL-адресе на
EA7C4B59F27D43EB. Вы будете перенаправлены на страницу My web app. - В новых средах это приложение-заглушка появится только после того, как начнёт поступать трафик от автоматически внедряемого приложения.
- Разделение приложений по доменам работает лучше всего, поскольку Ключ-АСТРОМ не может сопоставлять действия пользователей из разных доменов с конкретными пользовательскими сессиями. Эта корреляция осуществляется с помощью cookie, и поэтому работает только в том случае, если cookie может быть установлен в одном и том же домене. Например, действия пользователей для
www.astromkey.comиblog.astromkey.comмогут быть зафиксированы в одном приложении, поскольку cookie может быть установлен наastromkey.com. Однако трафик дляwww.astromkey.comиwww.internal-astromkey.comне может быть зафиксирован в одной пользовательской сессии. Вы по-прежнему можете разделять действия пользователей по домену, но пользовательские сессии не могут включать действия пользователей из нескольких доменов. - Группируйте приложения с низким трафиком. Если вы создадите приложение на основе домена, в котором выполняется менее 10 действий в минуту, Ключ-АСТРОМ не будет автоматически обнаруживать аномалии для этого вновь созданного приложения. Ключ-АСТРОМ зависит от стабильного трафика приложения для корректного определения многомерных базовых показателей и автоматического сообщения о проблемах приложения . Вы можете изменить настройки обнаружения аномалий в приложении на странице Обнаружение аномалий в настройках приложения. Хотя эта рекомендация противоречит упомянутой выше, объединение приложений с низким трафиком может быть целесообразным.
- Правила обнаружения приложений обрабатываются последовательно для каждого запроса. Чем больше правил, тем больше времени на обработку, и поскольку правила обрабатываются внутри ЕдиныхАгентов, следует стараться размещать правила для приложений с наибольшим трафиком в начале списка. Как только одно правило сработает, дальнейшая обработка запросов прекращается.
- В первую очередь следует определить более специфические правила обнаружения приложений, а более общие правила должны находиться в самом низу списка правил обнаружения приложений.
Предположим, вы хотите создать приложениеA, к которому будут привязаны следующие два домена:http://www.mydomain.com/cms/directory/shop/index.htmlhttp://shop.differentdomain.de/index.html
и еще одно приложениеBдля следующей области:http://newdomain.co.uk/hello/shop.html
Если вы создадите общее правило группировки на основе значенияshop, все три домена будут объединены в одно веб-приложение для мониторинга. Поэтому сначала следует определить более конкретное правило, например, «Если URL заканчивается наshop.html"», чтобы только третий URL был сопоставлен с приложениемB. Затем вы можете смело определить общее правило на основе значенияshop, поскольку третий URL уже будет сопоставлен с предыдущим приложением и, следовательно, не будет включен в приложениеA. - В зависимости от ваших потребностей вы можете настроить потребление ресурсов мониторинга и соответствующим образом сконфигурировать мониторинг реальных пользователей.
- Для мониторинга трафика в рамках одного приложения можно использовать действия пользователей и свойства сессии. Для мониторинга отдельных приложений и получения полной информации о потреблении трафика каждым приложением можно настроить отдельные приложения, использовать теги для разделения метрик и определить менеджмент зоны.


