Стратегии Application Insights для веб-API, обслуживающих несколько клиентов

У нас есть серверный API, работающий под управлением ASP.Net Core, с двумя внешними интерфейсами: веб-сайт SPA (Vuejs) и прогрессивная веб-страница (для мобильных пользователей). Внешний интерфейс — это в основном только клиентский код, и все службы находятся в разных доменах. Мы не используем файлы cookie, так как аутентификация использует токены носителя.

Мы экспериментировали с Application Insights для мониторинга, но, поскольку документация не очень описывает наши ситуации, я хотел бы получить дополнительные сведения о наилучшей стратегии и возможностях для:

  • Отслеживание пользователей и показателей без файлов cookie, например. нажатие кнопки в приложениях для вызова сервера, запрос Entity Framework/SQL (я вижу, что в настоящее время это не поддерживается, Как включить отслеживание зависимостей с помощью Application Insights в проекте Asp.Net Core), обработка данных и представление результата на клиенте.
  • Простое разделение вызовов с мобильных и стандартных веб-приложений в запросах Application Insights. Любой способ показать это на стандартных диаграммах, которые появляются изначально, был бы полезен.
  • Убедитесь, что наша стратегия также подходит для ситуаций, когда другие внешние клиенты будут получать доступ к API, и мы должны иметь возможность легко их идентифицировать и видеть, какую нагрузку они создают для системы.
  • Выполнение всего вышеперечисленного с наименьшим количеством кода.

asp.net-core azure-application-insights
person Pal-B    schedule 02.05.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

это может быть достойно нескольких независимых вопросов, если вы хотите узнать подробности по любому из них. (и вообще всегда подразумевается ваша последняя пуля, не так ли? :))

что ты уже испробовал? Тем не менее, большинство вещей «лучший способ для вас» будут мнениями.

Для общих ответов:

  • Re: отслеживание пользователей...

Если вы уже выполняете информацию/аутентификацию пользователя для других целей, вы просто устанавливаете различные поля context.user.* с информацией, которая у вас есть в контексте телеметрии входящего запроса. все другие данные телеметрии, которые происходят с использованием того же контекста телеметрии, будут инициировать любую информацию о пользователе, которая у вас уже есть.

  • re: разделение вызовов с мобильного и стандартного...

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

  • Re: внешние абоненты через API

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

В целом настраиваемые свойства (пары строка:строка ключ-значение) и пользовательские показатели (пары строка:двойной ключ-значение) — ваши друзья. вы можете установить их в контекстах, чтобы все события, сгенерированные в этом контексте, наследуют одни и те же свойства, вы можете явно установить их для отдельных TrackEvent (или любых других вызовов Track*) для отправки определенных свойств/метрик с любым отдельным событием.

Вы также можете использовать инициализаторы телеметрии для дополнения или фильтрации любой телеметрии, которая генерируется автоматически (например, запросы или зависимости на стороне сервера или просмотры страниц и зависимости ajax на стороне клиента)

person John Gardner    schedule 03.05.2017