Вопросы и ответы по Application Insights. Часто задаваемые вопросы

Подробные сведения об инструментировании приложений для включения Application Insights см. в разделе основы сбора данных.

После включения Application Insights и настройки приложения, мы рекомендуем сначала проверить Live-метрики и карту приложений.

С веб-приложений сервера:

• HTTP-запросы.
• Зависимости. Вызовы к базам данных SQL, вызовы HTTP к внешним службам, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage и Azure Queue Storage.
• Исключения и трассировки стека.
• Счетчики производительности: счетчики производительности доступны при использовании:
  • Агент Azure Monitor Application Insights
  • мониторинг Azure для виртуальных машин или наборов масштабирования виртуальных машин
  • Application Insights collectd пишущий.
• Пользовательские события и метрики, которые вы кодируете .
• журналы трассировки при настройке соответствующего коллектора.

С веб-страниц клиента:

• Неперехваченные исключения в приложении, включая указанные ниже сведения.

  • Трассировка стека
  • Сведения об исключении и сообщение, сопровождающее ошибку
  • Номер строки и столбца с ошибкой
  • URL-адрес, где возникла ошибка
  • Запросы зависимости сети, выполняемые вашим приложением через XML Http Request (XHR) и Fetch (по умолчанию сбор данных отключен), включают следующую информацию:
    • URL-адрес источника зависимостей
    • Команда и метод, используемые для запроса зависимости
    • Длительность запроса
    • Код результата и состояние успеха запроса
    • Идентификатор (если есть) пользователя, выполняющего запрос
    • Контекст корреляции (если есть), где выполняется запрос

• Сведения о пользователе (например, расположение, сеть, IP-адрес)

• Сведения об устройстве (например, браузер, ОС, версия, язык, модель)

• Сведения о сеансе

  Замечание

  Для некоторых приложений, таких как одностраничные приложения (SPAs), длительность не всегда записывается и, в этих случаях, по умолчанию используется значение 0.

  Дополнительные сведения см. в разделе Сбор данных, их хранение и сохранение в Application Insights.

Если вы их настроите, из других источников:

• Диагностика Azure
• Импорт в Log Analytics
• Анализ журналов
• Logstash.

При использовании фреймворков ведения журнала, таких как Serilog, сообщения журнала принимаются сервисом Application Insights как телеметрия трассировки и хранятся в traces таблице (либо AppTraces в Log Analytics). Это связано с тем, что таблицы, например requests, dependenciesи exceptions зарезервированы для соответствующих типов телеметрии.

Дополнительные сведения см. в модели данных телеметрии Application Insights.

Сведения о количестве ресурсов Application Insights, необходимых для покрытия приложений или компонентов в разных средах, см. в руководстве по планированию развертывания Application Insights.

Вы можете писать скрипты PowerShell с помощью Azure Resource Monitor:

• создание и обновление ресурсов Application Insights;
• Установите ценовой план.
• Получите строку подключения.
• Добавьте метрическое оповещение.
• добавление теста доступности.

Невозможно настроить отчет обозревателя метрик или настроить непрерывный экспорт.

Используйте REST API для выполнения запросов Log Analytics.

Рекомендуется Azure Monitor OpenTelemetry Distro.

Схема приема данных и протокол конечной точки доступны для всех.

Как правило, время сбора данных Application Insights не превышает 5 минут. Некоторые данные могут занять больше времени, что обычно для больших файлов журнала. См. соглашение об уровне обслуживания Application Insights.

Счет за использование Application Insights выставляется через рабочую область Log Analytics, в которую поступают данные его журналов. Уровень цен по умолчанию для Log Analytics включает 5 ГБ бесплатного объема данных в месяц для каждой учетной записи для выставления счетов. Узнайте больше о параметрах ценообразования журналов Azure Monitor.

• Если веб-приложение Azure размещено в центре обработки данных, где есть конечная точка коллекции Application Insights, плата не взимается.
• Если в дата-центре вашего узла отсутствует конечная точка сбора, телеметрия вашего приложения приведет к исходящему трафику Azure, который будет платным.

Этот ответ зависит от распределения конечных точек, а не от того, где размещен ресурс Application Insights.

Да, вы можете нести дополнительные затраты на сеть, которые зависят от региона, от которого поступает телеметрия и откуда она идет. Подробности см. в разделе Цены на пропускную способность в Azure.

Если вы видите непредвиденные расходы или высокие затраты в Application Insights, это руководство может помочь. В ней рассматриваются распространенные причины, такие как высокий объем телеметрии, пики приема данных и неправильно настроенная выборка. Особенно полезно, если вы устраняете проблемы, связанные с резким увеличением затрат, объемом телеметрии, неисправной выборкой, ограничениями данных, высокой нагрузкой на прием данных или неожиданными счетами. Чтобы начать работу, см. статью Troubleshoot проблем с высоким уровнем потребления данных в Application Insights.

Application Insights использует TLS 1.2 и 1.3.

Общие вопросы об устаревшей проблеме TLS см. в статье Решение проблем TLS и Поддержка TLS в Azure Resource Manager.

Дополнительные сведения см. в разделе "Введение в Application Insights".

Контекст

Application Insights собирает данные телеметрии из приложения и сохраняет его в рабочей области Log Analytics. Он работает для приложений, размещенных в любом месте, а не только в Azure.

Что собирается и откуда

Телеметрия поступает из: (1) пакета SDK, который вы добавляете в свое приложение, включая любые пользовательские данные телеметрии, которые вы отправляете, (2) необязательных агентов сервера и (3) тестов доступности, проводимых корпорацией Майкрософт. Типичные данные включают запросы, зависимости, исключения и сбои, счетчики производительности, контекст клиента и сервера, трассировки и любые пользовательские события или метрики, которые вы отправляете. Чтобы проверить, что отправляется, запустите приложение в режиме отладки и проверьте выходные данные или окна диагностики интегрированной среды разработки. Для веб-страниц откройте инструменты разработчика браузера и просмотрите вкладку "Сеть". Перед отправкой можно фильтровать или дополнять данные телеметрии, реализуя обработчик телеметрии.

Хранение и удержание данных

Хранение необработанных данных может иметь значение 30, 60, 90, 120, 180, 270, 365, 550 или 730 дней. Срок, превышающий 90 дней, может привести к начислению дополнительной платы. Агрегированные метрики сохраняются с детализацией в 1 минуту на протяжении 90 дней. Снимки отладки хранятся в течение 15 дней. Данные хранятся в регионе, выбранном при создании ресурса. Телеметрия неизменяема после приема. Невозможно изменить данные телеметрии. Очистка доступна для удаления данных при необходимости.

Доступ, безопасность и шифрование

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

Конфиденциальность и ответственное использование

Модули SDK по умолчанию сосредоточены на производительности, использовании и диагностике, а также обычно не включают конфиденциальные персональные данные. Не помещайте конфиденциальные данные в URL-адреса. Просмотрите настраиваемые данные телеметрии, чтобы они не включали персональные данные. IP-адрес клиента используется для географического расположения, а по умолчанию сохраненное поле IP-адреса равно нулю. Если требуется маскирование, добавьте инициализатор телеметрии. Если вашему приложению требуется опция отказа, отключите сбор данных в коде. Также просмотрите, казалось бы, безобидные поля, например имя устройства на личных устройствах. Вы можете управлять или отключать некоторую коллекцию в конфигурации или с помощью кода. Для получения дополнительной информации см. обработку геолокации и IP-адресов.

TLS

Используйте современный TLS для передаваемых данных. Не следует жестко кодировать старые версии протокола. Разрешите платформе согласовывать новые версии по мере их доступности. Дополнительные сведения см. в статье Защита развертывания Azure Monitor.

Локальная буферизация и сбои

Если подключение к Azure потеряно или регулируется, SDK буферизуют телеметрию локально и повторяют попытку. Устаревшие элементы автоматически удаляются, например, через 48 часов — для журналов и через 30 минут — для метрик. Локальное временное хранилище не шифруется, поэтому обеспечьте безопасность любого настраиваемого каталога хранения. В браузерах sessionStorage используется для буферизации отправок.

Локальное хранилище для каждого языка: быстрая справка

• .NET (ServerTelemetryChannel): по умолчанию используется значение %LOCALAPPDATA%\Microsoft\ApplicationInsights или %TMP%. Можно задать сохраненную папку в конфигурации или коде.

  Config (ApplicationInsights.config):

  <TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel">
      <StorageFolder>D:\NewTestFolder</StorageFolder>
  </TelemetryChannel>
  

  Код C#:

  var channel = new Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel();
  channel.StorageFolder = @"D:\NewTestFolder";
  channel.Initialize(Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active);
  Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.TelemetryChannel = channel;
  

• .NET (ASP.NET Core): те же значения по умолчанию, что и выше. В Linux и macOS пакет SDK может автоматически создавать папку storage. Порядок предпочтения: ${TMPDIR}затем /var/tmp, затем /tmp. Вы также можете задать папку в Startup.cs.

  ASP.NET Core Startup:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  // inside ConfigureServices
  services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel { StorageFolder = "/tmp/myfolder" });
  

• Java: использует папку temp OS, например C:\Users\username\AppData\Local\Temp в Windows. Этот путь не настраивается с помощью стандартного файла конфигурации.

• Node.js: по умолчанию используется значение %TEMP%/appInsights-node{CONNECTION STRING}. Можно изменить префикс файла, используемый для временного каталога во время выполнения программы.

  Пример узла:

  const appInsights = require('applicationinsights');
  appInsights.Sender.TEMPDIR_PREFIX = 'my-app-ai';
  appInsights.setup(process.env.APPLICATIONINSIGHTS_CONNECTION_STRING).start();
  

• JavaScript (браузер): использует sessionStorage ключи AI_buffer и AI_sent_buffer. Чтобы отключить буферизацию в sessionStorage:

  import { ApplicationInsights } from '@microsoft/applicationinsights-web';
  const appInsights = new ApplicationInsights({
    config: {
      connectionString: '<YOUR-CONNECTION-STRING>',
      enableSessionStorageBuffer: false
    }
  });
  appInsights.loadAppInsights();
  

• Python (OpenCensus): по умолчанию используется значение %USERNAME%/.opencensus/.azure/. Можно задать пользовательский путь:

  from opencensus.ext.azure.log_exporter import AzureLogHandler
  handler = AzureLogHandler(connection_string='<YOUR-CONNECTION-STRING>',
                            storage_path='/var/tmp/ai-cache')
  

Во многих случаях Application Insights автоматически собирает данные об использовании продукта для Майкрософт. Эти данные хранятся в хранилище данных Майкрософт и не влияют на объем мониторинга и затраты клиентов. Application Insights собирает основные и неосновные метрики о:

• Дистрибутив Azure Monitor OpenTelemetry
• Автоинструментация (автоматическое инструментирование)
• Пакеты SDK Application Insights (классический API)

Основными целями этой коллекции данных являются следующие:

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

Поддерживаемые языки

* Не поддерживается классическим API или автоинструментацией (только OTel)

Поддерживаемые регионы ЕС

Сбор данных об использовании поддерживает границу данных ЕС для ресурсов Application Insights в следующих регионах:

Собранные данные об использовании

Сетевые метрики

Присоединение метрик

Метрики компонентов

Несущественные метрики

Отслеживайте сбой ввода-вывода диска при использовании сохраняемости дисков для надежной телеметрии.

Настройка брандмауэра

Метрики отправляются в следующие расположения, к которым должны быть открыты исходящие подключения в брандмауэрах:

Отключение сбора данных об использовании

.NET

Сбор данных об использовании включен по умолчанию. Это поведение можно изменить, задав для переменной среды APPLICATIONINSIGHTS_STATSBEAT_DISABLED значение true.

Java

Чтобы отключить невенсиальные метрики, добавьте следующую конфигурацию в файл конфигурации:

{
  "preview": {
    "statsbeat": {
        "disabled": "true"
    }
  }
}

Вы также можете отключить эту функцию, задав для переменной APPLICATIONINSIGHTS_STATSBEAT_DISABLED среды значение true. Затем этот параметр имеет приоритет над disabledпараметром, указанным в конфигурации JSON.

Node.js

Сбор данных об использовании включен по умолчанию. Это поведение можно изменить, задав для переменной среды APPLICATION_INSIGHTS_NO_STATSBEAT значение true.

Python

Сбор данных об использовании включен по умолчанию. Это поведение можно изменить, задав для переменной среды APPLICATIONINSIGHTS_STATSBEAT_DISABLED_ALL значение true.

Архивированные сведения

Архивные сведения см. в разделе Сбор, хранение и сохранение данных в службе Application Insights.

Обе telemetryChannels потеряют буферизованную телеметрию, если она не очищается до завершения работы приложения.

Чтобы избежать потери данных, очистите TelemetryClient при завершении работы приложения.

Дополнительные сведения см. в разделе "Очистка данных".

Нет. Вам не нужно помещать их в конструкции try-catch. Если пакет SDK сталкивается с проблемами, он регистрирует сообщения, которые отображаются в консоли отладки, и, если сообщения успешно передаются, — в поиске по журналу диагностики.

Да, API для доступа к данным . Другие способы извлечения данных включают Power BI на ресурсе, основанном на рабочей области.

Пакет SDK Application Insights несовместим с автоинструментацией. Если включена автоинструментация, вызовы Track() и другие пользовательские события и метрики API будут проигнорированы.

Отключите автоинструментацию в Azure portal на вкладке Application Insights страницы App Service или задайте для параметра ApplicationInsightsAgent_EXTENSION_VERSION значение disabled.

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

Каждый переданный itemCount элемент содержит свойство, показывющее количество исходных событий, которые представляет элемент. Чтобы наблюдать за выборкой в операции, этот запрос можно выполнить в Log Analytics:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

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

Для получения дополнительной информации см. API Application Insights для пользовательских событий и метрик.

Да. Существует несколько способов скачивания агента Application Insights:

• Если на вашем компьютере есть доступ к интернету, вы можете зарегистрироваться в PowerShell Gallery с помощью параметров -Proxy.
• Вы также можете вручную скачать модуль и либо установить его на компьютер, либо использовать напрямую.

Каждый из этих вариантов описан в подробных инструкциях.

Да. В Application Insights Agent 2.0.0 и более поздних версий поддерживаются ASP.NET Core приложения, размещенные в IIS.

• Можно использовать командлет Get-ApplicationInsightsMonitoringStatus для проверки успешного включения.

• Используйте динамические метрики, чтобы быстро определить, отправляет ли ваше приложение данные телеметрии.

• Вы также можете использовать log Analytics для получения списка всех облачных ролей, отправляющих данные телеметрии:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Для обеспечения сквозного прохождения через прокси, настройте прокси на машинном уровне или на уровне приложения. См. раздел DefaultProxy.

Пример файла Web.config:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Дополнительные сведения см. в разделе "Развертывание агента Application Insights" для локальных серверов.

Application Insights и Azure Monitor не управляют версией TLS, используемой для подключений HTTPS. Версия TLS зависит от операционной системы и среды выполнения, в которой выполняется приложение.

Чтобы подтвердить используемую версию TLS, выполните следующие действия.

• Ознакомьтесь с документацией по операционной системе и среде выполнения или платформе.
• Если вам нужна дополнительная помощь, обратитесь в соответствующую службу поддержки. Не открывайте запрос на поддержку в Application Insights.

Пример поддержки языка и среды выполнения для TLS 1.2+

Следующие версии включают встроенную поддержку TLS 1.2 или более поздней версии:

• .NET / .NET Core: .NET Framework 4.6.2 или более поздней версии, а также все версии .NET Core
• Java: обновление Java 8 до версии 161 (8u161) или более поздней
• Python: дистрибутивы Python, созданные с помощью OpenSSL 1.0.1 или более поздней версии
• Node.js: Node.js версии 10 или более поздней

Пример поддержки операционной системы для TLS 1.2+

Следующие операционные системы включают встроенную поддержку TLS 1.2 или более поздней версии:

• Windows: Windows 8, Windows Server 2012 и более поздних версий
• Linux: большинство современных дистрибутивов Linux, использующих OpenSSL 1.0.1 или более поздней версии

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

Затронутые ресурсы Application Insights перестают извлекать данные и не могут получить доступ к необходимым компонентам приложения. В результате некоторые функции перестают работать.

Отказ от использования Transport Layer Security (TLS), описанный в этом документе, должен повлиять только на поведение после 1 мая 2025 года. Дополнительные сведения об операциях CRUD см. в статье Поддержка TLS в Azure Resource Manager. Этот ресурс содержит дополнительные сведения о поддержке TLS и временных рамках прекращения поддержки TLS.

Общие вопросы о устаревшей проблеме TLS см. в разделе "Решение проблем TLS".

Дополнительные сведения см. в разделе поддержки TLS.

Чтобы удалить Application Insights, необходимо удалить пакеты NuGet и ссылки из API в приложении. Пакеты NuGet можно удалить с помощью Package Manager NuGet в Visual Studio.

1. Если коллекция трассировки включена, сначала удалите пакет Microsoft.ApplicationInsights.TraceListener с помощью пакета NuGet Package Manager но не удаляйте зависимости.
2. Удалите пакет Microsoft.ApplicationInsights.Web и удалите его зависимости с помощью NuGet Package Manager и параметров Uninstall в элементе управления NuGet Package Manager Options.
3. Чтобы полностью удалить Application Insights, проверьте и вручную удалите добавленный код или файлы вместе с любыми вызовами API, добавленными в project. Дополнительные сведения см. в статье "Что автоматически создается при добавлении пакета SDK Application Insights?".

При добавлении Application Insights в project он автоматически создает файлы и добавляет код в некоторые файлы. Удаление пакетов NuGet не всегда удаляет файлы и код. Чтобы полностью удалить Application Insights, необходимо проверить и вручную удалить добавленный код или файлы вместе с любыми вызовами API, добавленными в project.

При добавлении телеметрии Application Insights в проект ASP.NET Visual Studio добавляются следующие файлы:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

Следующие фрагменты кода добавляются автоматически.

• [имя проекта].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  Если project имеет файл Layout.cshtml, добавляется следующий код.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               connectionString:'<YOUR-CONNECTION-STRING>'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

Сведения об отключении корреляции телеметрии в конфигурации см. в разделе <ExcludeComponentCorrelationHttpHeadersOnDomains> в Application Insights для консольных приложений.

Дополнительные сведения см. в разделе Configure Application Insights для веб-сайта ASP.NET.

ASP.NET Core 3.1 больше не поддерживается корпорацией Майкрософт.

пакет SDK Application Insights для ASP.NET Core версии 2.8.0 и Visual Studio 2019 или более поздней версии можно использовать с приложениями ASP.NET Core 3.1.

Получите экземпляр TelemetryClient с помощью внедрения конструктора и вызовите необходимый TrackXXX() метод на нем. Не рекомендуется создавать новые экземпляры TelemetryClient или TelemetryConfiguration в приложении ASP.NET Core. Одиночный экземпляр TelemetryClient уже зарегистрирован в контейнере DependencyInjection, который разделяет TelemetryConfiguration с остальной телеметрией. Создайте новый экземпляр TelemetryClient только в том случае, если требуется конфигурация, отличная от остальной телеметрии.

В следующем примере показано, как отслеживать дополнительные данные телеметрии из контроллера.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Дополнительные сведения о настраиваемых отчетах данных в Application Insights см. в разделе Справочник по API настраиваемых метрик Application Insights. Аналогичный подход можно использовать для отправки пользовательских метрик в Application Insights с помощью API GetMetric.

ASP.NET Core поддерживает встроенную поддержку для ведения журнала сведений о HTTP-запросе и ответе (включая текст) через ILogger. Рекомендуется воспользоваться этим. Это может потенциально раскрыть персональные данные (PII) в телеметрии, а также привести к значительному увеличению затрат (затрат на производительность и выставление счетов Application Insights), поэтому тщательно оцените риски перед использованием этого.

По умолчанию для Application Insights используется только запись предупреждений и более серьезных журналов.

Захват сведений и менее серьезных журналов путем изменения конфигурации ведения журнала для поставщика Application Insights следующим образом.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "<YOUR-CONNECTION-STRING>"
    }
}

Важно отметить, что в следующем примере поставщик Application Insights не будет собирать журналы Information. Он не фиксирует его, поскольку пакет SDK добавляет фильтр ведения журнала по умолчанию, который дает указание ApplicationInsights записывать только журналы с уровнем серьезности Warning и выше. Для Application Insights требуется чёткое переопределение.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

Дополнительные сведения см. в статье, посвященной конфигурации ILogger.

Метод расширения UseApplicationInsights() по-прежнему поддерживается, однако он отмечен как устаревший в пакете SDK для Application Insights версии 2.8.0 и последующих. Он удален в следующей основной версии пакета SDK. Чтобы включить телеметрию Application Insights, используйте AddApplicationInsightsTelemetry(), так как она предоставляет перегрузки для управления некоторыми аспектами конфигурации. Кроме того, в приложениях ASP.NET Core 3.X services.AddApplicationInsightsTelemetry() является единственным способом включения Application Insights.

Если пакет SDK установлен во время сборки, как показано в этой статье, не нужно включить расширение Application Insights на портале App Service. Если расширение установлено, оно отключается при обнаружении уже добавленного пакета SDK. Если включить Application Insights из расширения, то не потребуется устанавливать и обновлять пакет SDK. Но если вы включили Application Insights, следуя инструкциям в этой статье, то достигнете большей гибкости, поскольку:

• Данные телеметрии Application Insights продолжают собираться в:
  • со всеми операционными системами, включая Windows, Linux и Mac;
  • Все режимы публикации, включая автономные или зависящие от фреймворка.
  • Все целевые платформы, включая полную .NET Framework.
  • Все варианты размещения, включая Web Apps, виртуальные машины, Linux, контейнеры, AKS и размещение без Azure.
  • Все версии .NET Core, включая предварительные версии.
• Данные телеметрии отображаются локально при отладке из Visual Studio.
• Можно отслеживать больше пользовательских метрик телеметрии с помощью API TrackXXX().
• Вы полностью контролируете конфигурацию.

Да. В Application Insights Agent 2.0.0-beta1 и более поздних версий поддерживаются приложения ASP.NET Core, размещенные в IIS.

Да. Поддержка функций для пакета SDK одинакова на всех платформах, за исключением следующих:

• Пакет SDK собирает счетчики событий в Linux, поскольку счетчики производительности поддерживаются только в Windows. Большинство метрик одинаковы.

Нет. Вместо этого используйте Application Insights для приложений рабочих служб (не предназначенные для HTTP приложений) для рабочих служб.

Чтобы удалить Application Insights, необходимо удалить пакеты NuGet и ссылки из API в приложении. Пакеты NuGet можно удалить с помощью Package Manager NuGet в Visual Studio.

1. Удалите пакет Microsoft.ApplicationInsights.AspNetCore с помощью NuGet Package Manager.
2. Чтобы полностью удалить Application Insights, проверьте и вручную удалите добавленный код или файлы вместе с любыми вызовами API, добавленными в project. Дополнительные сведения см. в статье "Что создается при добавлении пакета SDK Application Insights?".

При добавлении Application Insights в project он создает файлы и добавляет код в некоторые файлы. Удаление пакетов NuGet не всегда удаляет файлы и код. Чтобы полностью удалить Application Insights, необходимо проверить и вручную удалить добавленный код или файлы вместе с любыми вызовами API, добавленными в project.

При добавлении телеметрии Application Insights в проект шаблона Visual Studio ASP.NET Core добавляется следующий код:

• [имя проекта].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "<YOUR-CONNECTION-STRING>"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

Сведения об отключении корреляции телеметрии в коде см. в разделе <ExcludeComponentCorrelationHttpHeadersOnDomains> в Application Insights для консольных приложений.

Дополнительные сведения см. в разделе Application Insights для ASP.NET Core.

• Exception rate: частота исключений — это счетчик производительности системы. CLR подсчитывает все обработанные и необработанные исключения, которые выбрасываются, и делит общее количество в интервале выборки на длину интервала. Пакет SDK Application Insights получает этот результат и отправляет его на портал.
• Exceptions: Метрика исключений подсчитывает TrackException отчеты, полученные порталом, в интервале выборки диаграммы. Он включает только обрабатываемые исключения, где вы пишете вызовы TrackException в вашем коде. Он не включает все необработанные исключения.

Дополнительные сведения см. в разделе Counters для .NET в Application Insights.

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

расширение Application Insights для ASP.NET Core пока не поддерживает эту функцию.

Дополнительные сведения см. в разделе Counters для .NET в Application Insights.

По умолчанию для ASP.NET Core приложений включен мониторинг на стороне клиента. Если вы хотите отключить ее, определите переменную среды на сервере со следующими сведениями:

• Имя: APPINSIGHTS_JAVASCRIPT_ENABLED
• Значение: false

Дополнительные сведения см. в разделе Application Insights для виртуальных машин Azure и наборов масштабируемых виртуальных машин.

Неудачные вызовы зависимостей имеют success значение False. Модуль DependencyTrackingTelemetryModule не сообщает данные ExceptionTelemetry. Полная модель данных для зависимостей описана в модели данных телеметрии Application Insights.

Используйте следующий код:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

В представлении запросов Log Analytics значение timestamp соответствует моменту, когда был инициирован вызов TrackDependency(), что происходит сразу после получения отклика на вызов зависимости. Чтобы вычислить время начала вызова зависимости, необходимо из timestamp вычесть записанное значение duration вызова зависимости.

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

Дополнительные сведения см. в разделе "Отслеживание зависимостей".

Тесты доступности выполняются на точках присутствия, распределенных по всему миру. Есть два решения.

• Firewall door: Разрешите запросы к вашему серверу из длинного и изменяемого списка агентов веб-тестирования.
• Пользовательский код: напишите собственный код для отправки периодических запросов на сервер из интрасети. Для этого можно запустить Visual Studio веб-тесты. Тестировщик может отправлять результаты в Application Insights с помощью TrackAvailability() API.

Строка агента пользователя — Mozilla/5.0 (совместима; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Дополнительные сведения см. в разделе "Тесты доступности".

Тесты доступности выполняют роль распределенного клиента в каждом из поддерживаемых расположений веб-тестов. Каждый раз, когда веб-тест выполняется, служба тестирования доступности пытается обратиться к удаленной конечной точке, определенной в конфигурации веб-теста. Сообщение TLS Client Hello отправляется, содержащее всю поддерживаемую конфигурацию TLS. Если удаленная конечная точка использует общую конфигурацию TLS с клиентом тестирования доступности, то TLS-рукопожатие проходит успешно. В противном случае веб-тест завершается ошибкой при установлении соединения TLS.

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

Нет ни одного типа исключения, на которые влияют все сбои рукопожатия TLS, затронутые этой утратой поддержки. Однако, наиболее распространенное исключение в вашем веб-тесте будет завершаться сбоем The request was aborted: Couldn't create SSL/TLS secure channel. Кроме того, вы сможете просмотреть все связанные с TLS сбои в шаге "Транспорт TLS" Troubleshooting Step для результата веб-теста, возможно затронутого.

Конфигурация TLS, согласованная во время выполнения веб-теста, не может быть просмотрна. Если удаленная конечная точка поддерживает общую конфигурацию TLS с тестами доступности, влияние не должно быть заметно после устаревания.

Отказ от использования TLS, подробно описанный в этом документе, должен повлиять только на поведение выполнения веб-тестов доступности после 1 мая 2025 г. Дополнительные сведения о взаимодействии со службой тестирования доступности для операций CRUD см. в разделе Поддержка TLS Azure Resource Manager. Этот ресурс содержит дополнительные сведения о поддержке TLS и временных рамках прекращения поддержки TLS.

Общие вопросы о устаревшей проблеме TLS см. в разделе "Решение проблем TLS".

Дополнительные сведения см. в разделе "Поддерживаемые конфигурации TLS".

Сведения зависят от типа project. Ниже приведен пример веб-приложения.

• Добавляет файлы в ваш проект:

  • ApplicationInsights.config
  • ai.js

• Устанавливает пакеты NuGet:

  • API для Application Insights: основной интерфейс API
  • API Application Insights для веб-приложений: используется для отправки данных телеметрии с сервера
  • API Application Insights для приложений JavaScript: используется для отправки данных телеметрии из клиента

• Включает сборки в пакетах:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Вставляет элементы в:

  • Web.config
  • packages.config

• Вставляет фрагменты кода в код клиента и сервера для их инициализации с идентификатором ресурса Application Insights. Например, в приложении MVC код вставляется в главную страницу Views/Shared/_Layout.cshtml. Только для новых проектов вы можете добавить Application Insights в существующий проект вручную.

Application Insights собирает телеметрические данные о запросах, которые поступили в приложение. Если сбой возникает в WebApps/WebServer, и запрос не достиг пользовательского приложения, Application Insights не имеет никаких данных телеметрии об этом.

Длительность serverresponsetime, вычисляемая Application Insights, не обязательно соответствует времени отклика сервера, наблюдаемого Web Apps. Это связано с тем, что Application Insights учитывает только длительность, когда запрос фактически достигает пользовательского приложения. Если запрос зависает или помещается в очередь в webServer, время ожидания включается в метрики Web Apps, но не в метрики Application Insights.

Дополнительные сведения см. в разделе Включение мониторинга приложений в Azure App Service.

Мы следуйте руководству по стилю Майкрософт для документации по продуктам, опубликованной на платформе Microsoft Learn.

Как правило, мы не добавим дефис после префикса auto.

Дополнительные сведения см. в разделе Что такое автоинструментация для Azure Monitor Application Insights?.

Новые регионы Azure требуют использование строк подключения вместо ключей инструментирования. Connection string определяет ресурс, который требуется связать с данными телеметрии. Он также позволяет изменять конечные точки, которые ресурс использует в качестве назначения для телеметрии. Скопируйте connection string и добавьте его в код приложения или в переменную среды.

Мы рекомендуем использовать строки подключения вместо ключей инструментирования.

Установите APPLICATIONINSIGHTS_CONNECTION_STRING вручную во всех сценариях, когда система не предоставляет его автоматически. Эти сценарии включают, но не ограничиваются, следующими: локальная разработка и .NET-изолированные функции с интеграцией ASP.NET Core. В таких случаях переменная среды гарантирует, что конвейер OpenTelemetry может отправлять данные телеметрии в Application Insights. Дополнительные сведения о настройке строк подключения с помощью переменной среды см. в разделе "Настройка OpenTelemetry" в Application Insights.

Чтобы удовлетворить требования к соответствию региональным данным, используйте региональные конечные точки Application Insights вместо глобальной конечной точки. Глобальная конечная точка не гарантирует, что данные остаются в определенном регионе. Региональные конечные точки помогают гарантировать, что данные телеметрии пользователей в регулируемых областях отправляются только в центры обработки данных в этих регионах.

Чтобы настроить глобальное веб-приложение для соответствия регионам, выполните приведенные действия.

• Создайте один ресурс Application Insights для каждого региона с строгими требованиями соответствия, такими как Европейский союз или United States.
• Создайте другой ресурс Application Insights для пользователей во всех других регионах.
• Настройте приложение для отправки данных телеметрии в соответствующий ресурс Application Insights на основе каждого региона пользователя. Определите регион с помощью таких сигналов, как IP-адрес, метаданные учетной записи или параметры расположения.
• Подключите все ресурсы Application Insights к рабочей области Log Analytics, если требуется единый интерфейс запросов в разных регионах.

Рассмотрим пример.

• Отправка данных пользователей из региона A в ресурс Application Insights региона A с помощью строки подключения региона A.
• Отправьте данные пользователей из региона B в ресурс Region B Application Insights, используя строку подключения региона B.
• Отправьте все остальные данные пользователя в ресурс Application Insights общего назначения, используя другую строку подключения.

На следующей схеме показан пример настройки для глобального веб-приложения:

Дополнительные сведения см. в разделе Строки подключения.

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

• Создание ресурса Application Insights в нужном регионе.
• Повторное создание уникальных настроек из исходного ресурса в новом.
• Обновление приложения с помощью нового ресурса региона connection string.
• Тестирование, чтобы убедиться, что все работает должным образом с новым ресурсом Application Insights.
• Решите сохранить или удалить исходный ресурс Application Insights. Удаление классического ресурса означает потерю всех исторических данных. Если ресурс основан на рабочей области, данные остаются в Log Analytics, что позволяет доступ к историческим данным до истечения срока хранения.

Уникальные кастомизации, которые обычно необходимо вручную создать или обновить для ресурса в новом регионе, включают в себя, но не ограничиваются:

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

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

Дополнительные сведения см. в статье "Создание и настройка ресурсов Application Insights".

Чтобы сообщить о проблемах и предложениях модели данных, используйте наш репозиторий GitHub.

Данные телеметрии PageView содержат URL-адрес и можно проанализировать параметр UTM с помощью функции regex в Kusto.

Иногда эти данные могут быть отсутствуют или неточные, если пользователь или предприятие отключает отправку агента пользователя в параметрах браузера. UA Parser regexes может не включать все сведения об устройстве. Или Application Insights, возможно, не приняли последние обновления.

Это может произойти, если вы используете строковые значения. Только числовые значения работают с пользовательскими измерениями.

Дополнительные сведения см. в статье Модель данных телеметрии Application Insights.

ApplicationInsightsLoggerProvider ведет журналы ILogger и создает на их основе TraceTelemetry. Если объект Exception передается в метод Log в ILogger, вместо ExceptionTelemetry создается TraceTelemetry.

Просмотр телеметрии ILogger

В Azure portal:

1. Перейдите на портал Azure и получите доступ к ресурсу Application Insights.
2. Выберите раздел "Журналы" в Application Insights.
3. Используйте язык запросов Kusto (KQL) для запроса сообщений ILogger, хранящихся в traces таблице. Пример запроса: traces | where message contains "YourSearchTerm".
4. Уточняйте запросы, чтобы фильтровать данные ILogger по серьезности, диапазону времени или определенному содержимому сообщения.

В Visual Studio (локальный отладчик):

1. Запустите приложение в режиме отладки в Visual Studio.
2. Откройте окно средств диагностики во время запуска приложения.
3. На вкладке "События " журналы ILogger отображаются вместе с другими данными телеметрии.
4. Чтобы найти определенные сообщения ILogger, используйте функции поиска и фильтрации в окне средств диагностики.

Если вы предпочитаете всегда отправлять TraceTelemetry, используйте следующий фрагмент кода.

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Application Insights записывает и отправляет журналы ILogger, используя ту же информацию TelemetryConfiguration, которая применяется для всех остальных данных телеметрии. Но есть исключение. По умолчанию TelemetryConfiguration не полностью настраивается при регистрации из Program.cs или Startup.cs. Журналы из этих источников не имеют конфигурации по умолчанию, поэтому они не выполняют все TelemetryInitializer и TelemetryProcessor экземпляры.

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

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Расширение Application Insights в Azure Web Apps использует новый поставщик. Правила фильтрации для вашего приложения можно изменить в файле appsettings.json.

Дополнительные сведения см. в разделе Ведение журнала Insights с помощью .NET.

Профилировщик Java использует Java Flight Recorder (JFR) для профилирования вашего приложения с помощью настраиваемой конфигурации.

Java Flight Recorder (JFR) — это средство для сбора данных профилирования запущенного приложения Java. JFR интегрирован в виртуальную машину Java (JVM) и используется для устранения неполадок с производительностью. Узнайте больше о среде выполнения Java SE JFR.

Профилирование Java — это бесплатная функция с Application Insights. Цены на Azure Monitor Application Insights зависят от затрат на прием.

Данные профилирования, собранные JFR, включают: данные профилирования методов и выполнения, данные о сборке мусора и профили блокировок.

Запись JFR можно просматривать и анализировать с помощью предпочтительного средства, например Java Mission Control (JMC).

"Диагностика производительности и рекомендации" — это новая функция, которая вскоре будет доступна в Application Insights Java. Вы можете зарегистрироваться для предварительной версии этой функции. Запись JFR можно просмотреть с помощью Java Mission Control (JMC).

По запросу профилирование запускается пользователем в режиме реального времени, тогда как автоматическое профилирование выполняется с предварительно настроенными триггерами.

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

Автоматическое профилирование активируется путем достижения порогового значения ресурса.

Агент Java Application Insights в настоящее время поддерживает мониторинг потребления ЦП и памяти. Пороговое значение ЦП настраивается в процентах от всех доступных ядер на машине. Память — это текущее заполнение области памяти Tenured (OldGen) как доля от максимально возможного размера области.

Ознакомьтесь с предварительными требованиями.

Да, с помощью JFR вы можете профилировать виртуальную машину Java, на которой выполняются микрослужбы.

Дополнительные сведения см. в разделе Azure Monitor Application Insights Profiler for Java.

Нет, переопределения выборки теперь доступны для общего пользования (GA) и могут использоваться как с автоинструментацией, так и с ручной инструментализацией.

При использовании автоинструментации обновите файл applicationinsights.json в Azure portal.

Для автоинструментации не требуется ручная загрузка агента. Однако для инструментирования вручную необходимо включить JAR-файл агента Application Insights и файлы конфигурации в пакет развертывания.

Локальная разработка относится к среде, в которой приложение создается или тестируется, например компьютер разработчика или экземпляр Azure Cloud Shell. Сервер приложений относится к веб-серверу, на котором запущено приложение, например, Tomcat 11 в среде App Service Azure. При использовании ручного инструментирования необходимо убедиться, что JAR-файл агента правильно помещается на сервер приложения.

Для автоинструментации можно настроить переопределения выборки через портал Azure. При использовании ручного инструментирования необходимо поместить JAR-файл агента Application Insights в соответствующий каталог и включить файл applicationinsights.json с нужными параметрами выборки.

Дополнительные сведения см. в разделе Переопределение выборки — Azure Monitor Application Insights для Java.

TelemetryClient.trackTrace() является частью классического моста SDK Application Insights, а процессоры логов работают только с новым инструментарием на основе OpenTelemetry.

Дополнительные сведения см. в разделе Телеметрия процессоров (предварительная версия) — Azure Monitor Application Insights для Java.

• Пакет SDK для JavaScript создает файл cookie пользователя в веб-клиенте для определения возвращающихся пользователей и файл cookie сеанса для группировки действий.
• Если на сервере нет клиентского скрипта, вы можете задать файлы cookie на сервере.
• Если один реальный пользователь использует ваш сайт в разных браузерах, в режиме инкогнито или на разных компьютерах, он считается более одного раза.
• Чтобы определить пользователя, выполнившего вход на компьютерах и браузерах, добавьте вызов setAuthenticatedUserContext().

Пакет SDK JavaScript для Application Insights имеет минимальные затраты на веб-сайт. При весе всего 36 КБ в сжатом виде и требующем всего около 15 мс для инициализации, SDK добавляет незначительное время загрузки к вашему веб-сайту. Минимальные компоненты библиотеки быстро загружаются при использовании пакета SDK, а полный скрипт загружается в фоновом режиме.

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

Примеры запуска см. в примерах пакета SDK javaScript для Application Insights.

Мы должны принять необходимые меры, чтобы убедиться, что этот пакет SDK продолжает работать и не прерывает выполнение JavaScript при загрузке более старым браузером. Хотя идеальным решением был бы отказ от поддержки браузеров более ранних поколений, множество крупных клиентов не могут управлять выбором браузера своих пользователей.

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

Полные сведения о поддержке Internet Explorer 8 см. в GitHub.

Да, пакет SDK JavaScript для Application Insights open source. Чтобы просмотреть исходный код или внести свой вклад в project, ознакомьтесь с репозиторием official GitHub.

Для получения дополнительной информации, см. Enable Azure Monitor Application Insights Real User Monitoring.

На стороне сервера должна быть возможность принимать подключения с такими заголовками. В зависимости от конфигурации Access-Control-Allow-Headers на стороне сервера часто необходимо расширить список на стороне сервера, добавив Request-Id, Request-Context и traceparent (распределенный заголовок W3C).

Access-Control-Allow-Headers: "Request-Id", "traceparent", "Request-Context", "<your header>"

Распределенная трассировка может быть отключена в конфигурации.

Нет. Ошибки "502 Плохой шлюз" и "503 Служба недоступна" не всегда фиксируются в Application Insights. Если для мониторинга используется только клиентский JavaScript, это поведение ожидаемо, так как ответ на ошибку возвращается до отрисовки страницы с заголовком HTML, содержащим фрагмент кода JavaScript для мониторинга.

Если ответ 502 или 503 был отправлен с сервера с включенным мониторингом на стороне сервера, ошибки собираются пакетом SDK Application Insights.

Даже если на веб-сервере приложения включен мониторинг на стороне сервера, иногда ошибка 502 или 503 не фиксируется Application Insights. Многие современные веб-серверы не позволяют клиенту напрямую взаимодействовать. Вместо этого они используют такие решения, как обратные прокси-серверы для передачи информации между клиентом и внешними веб-серверами.

В этом сценарии ответ 502 или 503 может быть возвращен клиенту из-за проблемы на обратном прокси-уровне, поэтому он не записывается вне поля Application Insights. Чтобы выявить проблемы на этом уровне, может потребоваться перенаправить журналы из обратного прокси-сервера в Log Analytics и создать настраиваемое правило для проверки ответов 502 или 503. Дополнительные сведения о распространенных причинах ошибок 502 и 503 см. в статье Устранение неполадок HTTP-ошибок "502 Bad Gateway" и "503 Сервис недоступен" в Azure App Service.

Дополнительные сведения см. в статье о конфигурации пакета SDK для JavaScript для Application Insights.

Браузер передает строку агента пользователя в заголовке HTTP запроса. Служба приема Application Insights использует UA Parser для создания полей, отображаемых в таблицах данных и интерфейсах. В результате пользователи Application Insights не могут изменить эти поля.

Иногда эти данные могут быть отсутствуют или неточные, если пользователь или предприятие отключает отправку агента пользователя в параметрах браузера. UA Parser regexes может не включать все сведения об устройстве. Или Application Insights, возможно, не приняли последние обновления.

Дополнительные сведения см. в статье "Включение расширения платформы для пакета SDK JavaScript для Application Insights".

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

Нет. Уведомление о миграции отдельных ресурсов недоступно. Чтобы контролировать, когда и как ваши ресурсы будут перенесены, используйте ручную миграцию.

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

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

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

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

Нет. Все оповещения, панели мониторинга и тесты доступности остаются неизменными и продолжают функционировать после миграции.

Дополнительные сведения см. в разделе "Управляемые рабочие области" в Application Insights.

Чтобы отключить корреляцию телеметрии, используйте correlationHeaderExcludedDomains свойство в конфигурации. Дополнительные сведения см. в разделе ApplicationInsights-node.js.

Чтобы настроить требуемый уровень журнала, который будет использовать Application Insights, используйте APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL переменную среды. Поддерживаемые значения: NONE, ERROR, WARN, INFO, DEBUG, VERBOSE и ALL. Дополнительные сведения см. в разделе ApplicationInsights-node.js.

Дополнительные сведения см. в статье "Мониторинг Node.js служб и приложений с помощью Application Insights".

Список версий и имен пакета SDK размещается в GitHub. Дополнительные сведения см. в разделе SDK Version.

Дополнительные сведения см. в статье Сбор данных телеметрии с помощью OpenTelemetry в Application Insights.

OpenTelemetry — это фреймворк наблюдаемости, нейтральный к поставщикам. API Application Insights отсутствуют в пакете SDK или библиотеках OpenTelemetry. Перед миграцией важно понимать некоторые понятия OpenTelemetry.

• В Application Insights все данные телеметрии управлялись одним TelemetryClient и TelemetryConfiguration. В OpenTelemetry каждый из трех сигналов телеметрии (трассировки, метрики и журналы) имеет собственную конфигурацию. Вы можете вручную создать данные телеметрии с помощью среды выполнения .NET без внешних библиотек. Дополнительные сведения см. в руководствах .NET по распределенной трассировке, метрикам и журналированию.

• Application Insights использовал TelemetryModules для автоматического сбора данных телеметрии вашего приложения. Вместо этого OpenTelemetry использует инструментальные библиотеки для сбора данных телеметрии из определенных компонентов (например, AspNetCore для запросов и HttpClient для зависимостей).

• Application Insights используется TelemetryInitializers для обогащения телеметрии дополнительными сведениями или переопределения свойств. С помощью OpenTelemetry можно написать обработчик для настройки определенного сигнала. Кроме того, многие библиотеки инструментирования OpenTelemetry предлагают Enrich метод настройки телеметрии, создаваемой данным компонентом.

• Application Insights использовал TelemetryProcessors для фильтрации телеметрии. Обработчик OpenTelemetry также можно использовать для применения правил фильтрации по конкретному сигналу.

Инструкции по миграции см. в статье Миграция с пакетов SDK .NET Application Insights на Azure Monitor OpenTelemetry.

Эта таблица сопоставляет типы данных Application Insights с концепциями OpenTelemetry и их реализацией .NET.

Дополнительные сведения см. в следующих документах.

• Основы сбора данных в Azure Monitor Application Insights
• Модель данных телеметрии Application Insights
• Основные понятия OpenTelemetry

Хотя Application Insights предложил несколько вариантов настройки выборки, Azure Monitor Exporter или Azure Monitor Distro предлагают только фиксированную норму выборки. Можно выполнять выборку только для запросов и зависимостей (трассировок OpenTelemetry).

Дополнительные сведения о настройке выборки см. в руководстве «Включение выборки»

В пакете SDK .NET Application Insights используйте процессоры телеметрии для фильтрации и изменения или отмены телеметрии. Инициализаторы телеметрии используются для добавления или изменения настраиваемых свойств. Дополнительные сведения см. в документации Azure Monitor. OpenTelemetry заменяет эти понятия действиями или обработчиками журналов, которые расширяют и фильтруют данные телеметрии.

Фильтрация трассировок

Чтобы фильтровать данные телеметрии в OpenTelemetry, можно реализовать обработчик действий. Этот пример эквивалентен примеру Application Insights для фильтрации данных телеметрии, как описано в документации Azure Monitor. В примере показано, где отфильтровываются неудачные вызовы зависимостей.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

Чтобы использовать этот процессор, необходимо создать TracerProvider и добавить процессор перед AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Фильтрация журналов

Реализации ILogger имеют встроенный механизм для применения фильтрации журналов. Эта фильтрация позволяет управлять журналами, отправленным каждому зарегистрированному поставщику, включая OpenTelemetryLoggerProvider. OpenTelemetry — это псевдоним для OpenTelemetryLoggerProvider, используемый при настройке правил фильтрации.

Следующий пример определяет "Error" в качестве значения по умолчанию LogLevel , а также определяет "Предупреждение" как минимум LogLevel для определяемой пользователем категории. Эти правила, как определено, применяются только к OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

Дополнительные сведения см. в документации OpenTelemetry .NET на журналах.

Добавление пользовательских свойств в трассировку

В OpenTelemetry можно использовать обработчики действий для обогащения данных телеметрии с дополнительными свойствами. Аналогично использованию инициализаторов телеметрии в Application Insights, где можно изменить свойства телеметрии.

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

Ниже приведен пример добавления настраиваемых свойств и переопределения поведения по умолчанию для определенных кодов ответов:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

Чтобы использовать этот процессор, необходимо создать TracerProvider и добавить процессор перед AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Отправка трассировок вручную

Трассировки в Application Insights хранятся как RequestTelemetry и DependencyTelemetry. В OpenTelemetry моделируются трассировки как Span, используя класс Activity.

.NET OpenTelemetry использует классы ActivitySource и Activity для трассировки, которые являются частью среды выполнения .NET. Этот подход отличается, так как реализация .NET интегрирует API трассировки непосредственно в саму среду выполнения. Пакет System.Diagnostics.DiagnosticSource позволяет разработчикам использовать ActivitySource для создания и управления экземплярами Activity. Этот метод позволяет легко добавлять трассировку в .NET приложения без использования внешних библиотек, применяя встроенные возможности экосистемы .NET. Дополнительные сведения см. в пошаговом руководстве по инструментированию распределенной трассировки.

Вот шаги для переноса трассировки вручную:

Телеметрия зависимостей

Application Insights DependencyTelemetry используется для моделирования исходящих запросов. Вот как преобразовать его в OpenTelemetry:

Пример Application Insights:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

Пример OpenTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

Запрос телеметрии

Application Insights RequestTelemetry моделирует входящие запросы. Вот как перенести его в OpenTelemetry:

Пример Application Insights:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

Пример OpenTelemetry:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Отслеживание пользовательских операций

В Application Insights отслеживайте пользовательские операции с помощью методов StartOperation и StopOperation. Это можно сделать с помощью ActivitySource и Activity в .NET OpenTelemetry. Для операций с ActivityKind.Server и ActivityKind.Consumer Azure Monitor Exporter создает RequestTelemetry. Для ActivityKind.Client, ActivityKind.Producerи ActivityKind.Internal, он создает DependencyTelemetry. Дополнительные сведения об отслеживании пользовательских операций см. в документации Azure Monitor. Для дополнительной информации об использовании ActivitySource и Activity в .NET, см. в пошаговых руководствах по инструментированию .NET трассировки распределенных систем.

Ниже приведен пример запуска и остановки действия для пользовательских операций:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Отправка журналов

Журналы в Application Insights хранятся как TraceTelemetry и ExceptionTelemetry.

Телеметрия следов

В OpenTelemetry логирование интегрируется через интерфейс ILogger. Вот как перенести TraceTelemetry:

Пример Application Insights:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

Пример OpenTelemetry:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

Application Insights использует ExceptionTelemetry для журналирования исключений. Вот как выполнить миграцию в OpenTelemetry:

Пример Application Insights:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

Пример OpenTelemetry:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Отправка метрик

Метрики в Application Insights хранятся как MetricTelemetry. В OpenTelemetry метрики моделиируются как Meter из System.Diagnostics.DiagnosticSource пакета.

Application Insights имеет также неагрегированные (TrackMetric()) и предварительно агрегированные (GetMetric().TrackValue()) интерфейсы метрик API. В отличие от OpenTelemetry, Application Insights не имеет понятия Instruments. Application Insights имеет один и тот же API для всех сценариев метрик.

С другой стороны, OpenTelemetry требует, чтобы пользователи сначала выбрали правильный инструмент для сбора метрик на основе фактической семантики метрики. Например, если намерение состоит в том, чтобы подсчитать что-то (например, количество полученных запросов сервера и т. д.), следует использовать OpenTelemetry Counter. Если цель состоит в вычислении различных процентилей (например, значения задержки сервера P99), то следует использовать инструмент OpenTelemetry Histogram. Из-за этого фундаментального различия между Application Insights и OpenTelemetry между ними не производится прямое сравнение.

В отличие от Application Insights, OpenTelemetry не предоставляет встроенные механизмы для обогащения или фильтрации метрик. В Application Insights обработчики телеметрии и инициализаторы могут использоваться для изменения или отмены метрик, но эта возможность недоступна в OpenTelemetry.

Кроме того, OpenTelemetry не поддерживает отправку необработанных метрик напрямую, поскольку отсутствует функциональность, аналогичная TrackMetric(), существующая в Application Insights.

Миграция из Application Insights в OpenTelemetry включает замену всех использований API метрик Application Insights на API OpenTelemetry. Для этого требуется понимание различных инструментов OpenTelemetry и их семантики.

Другие типы телеметрии

CustomEvents

Не поддерживается в OpenTelemetry.

Пример Application Insights:

TelemetryClient.TrackEvent()

Телееметрия доступности

Не поддерживается в OpenTelemetry.

Пример Application Insights:

TelemetryClient.TrackAvailability()

Телеметрия просмотра страницы

Не поддерживается в OpenTelemetry.

Пример Application Insights:

TelemetryClient.TrackPageView()

Мы рекомендуем Azure Monitor OpenTelemetry Exporter для приложений консоли и рабочих служб, которые не включают динамические метрики.

Дополнительные сведения см. в разделе Миграция с пакетов SDK .NET Application Insights на Azure Monitor OpenTelemetry.

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

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

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

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

Нет, образец применяет фиксированную скорость для всех типов телеметрии в трассировке. Запросы, зависимости и другие диапазоны соответствуют тому же проценту выборки. Чтобы применить разные ставки на тип телеметрии, рекомендуется использовать процессоры диапазона OpenTelemetry или (преобразования времени приема)[app-insights-overview.md#telemetry-routing].

Пользовательский дискретизатор Application Insights по умолчанию распространяет решения об отборе проб, используя стандарт W3C Trace Context. Этот стандарт обеспечивает обмен решениями по выборке между службами. Однако, поскольку сэмплер принимает решения о выборке в конце генерации диапазона—после вызова низкоуровневых служб—распространение передает неполные данные о выборке. Это ограничение соответствует спецификации контекста трассировки W3C, но подчиненные службы не могут надежно использовать это распространяемое решение выборки.

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

Существует несколько причин, по которым трассировка может показаться неполной:

• Разные узлы в распределенной системе используют разные механизмы выборки, которые не координируют решения. Например, один узел применяет выборку на основе головы OpenTelemetry, а другой узел применяет выборку через Azure Monitor Custom Sampler.
• Для разных узлов заданы разные частоты выборки, даже если оба они используют один и тот же подход выборки.
• Вы устанавливаете ограничения фильтрации, выборки или частоты в конвейере на стороне службы, а эта конфигурация случайным образом выполняет выборку диапазонов без учета полноты трассировки.

Если один компонент применяет выборку на основе головы без распространения решения выборки (с помощью заголовков контекста трассировки W3C), подчиненные службы независимо отбирают трассировку, что может привести к отклонению диапазонов. В результате некоторые части трассировки не всегда доступны при просмотре в Application Insights.

Выборка приема удаляет только то, что достигает службы, поэтому она не может противодействовать или переопределять пользовательские решения выборки Application Insights. Если оба включены, то эффективная ставка умножается. Например, доля пакета SDK в 20 процентов в сочетании с скоростью приема 50 процентов приводит к примерно 10 процентам хранения данных. Корпорация Майкрософт рекомендует выполнять выборку данных на уровне источника с помощью средства выборки Azure Monitor OpenTelemetry, чтобы сохранить трассировки нетронутыми и предсказуемыми, и использовать выборку данных при потреблении только в качестве резервного варианта.

Дополнительные сведения см. в Выборка в Azure Monitor Application Insights с помощью OpenTelemetry.

Это стандарт с открытым исходным кодом для наблюдения. Дополнительные сведения см. в openTelemetry.

Корпорация Майкрософт инвестирует в OpenTelemetry по следующим причинам:

• Его использование не зависит от поставщика и обеспечивает согласованные API/пакеты SDK на различных языках программирования.
• Со временем мы считаем, что OpenTelemetry позволит Azure отслеживать приложения, написанные на языках за пределами наших поддерживаемых языков.
• Он расширяет типы данных, которые можно собирать с помощью расширенного набора библиотек инструментирования.
• Наборы средств разработки программного обеспечения OpenTelemetry (ПАКЕТЫ SDK), как правило, являются более производительными, чем их предшественники, пакеты SDK классического API Application Insights.
• OpenTelemetry соответствует стратегии Майкрософт по embrace open source.

См. сведения о состоянии OpenTelemetry.

Вы можете подумать о нем как о лёгкой обёртке, которая объединяет все компоненты OpenTelemetry для первоклассного опыта в Azure. Эта оболочка также называется распределением в OpenTelemetry.

Есть несколько преимуществ использования Azure Monitor OpenTelemetry Distro по сравнению с OpenTelemetry от сообщества:

• Сокращение усилий для внедрения
• Поддерживается Microsoft
• Предоставляет функции, характерные для Azure, такие как:
  • Выборка, совместимая с классическими пакетами SDK Application Insights
  • Аутентификация Microsoft Entra
  • Офлайн-хранилище и автоматические повторные попытки
  • Стандартные метрики Application Insights
  • Обнаружение метаданных ресурсов для автоматического заполнения поля Имя облачной роли и Экземпляр облачной роли в различных средах Azure
  • Актуальные метрики

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

• Экспортер протокола OpenTelemetry (OTLP) для одновременной отправки данных во второе место назначения
• Другие библиотеки инструментирования, не включенные в дистрибутив

Поскольку дистрибутив предоставляет дистрибуцию OpenTelemetry, он поддерживает всё, что поддерживает OpenTelemetry. Например, можно добавить дополнительные процессоры телеметрии, экспортеры или библиотеки инструментирования, если OpenTelemetry поддерживает их.

Для языков без поддерживаемого автономного экспортера OpenTelemetry Azure Monitor OpenTelemetry Distro является единственным поддерживаемым в настоящее время способом использования OpenTelemetry с Azure Monitor. Для языков с поддерживаемым автономным экспортером OpenTelemetry можно использовать либо дистрибутив OpenTelemetry Azure Monitor OpenTelemetry, либо соответствующий автономный экспортер OpenTelemetry в зависимости от сценария телеметрии. Дополнительные сведения см. в статье Когда следует использовать экспортер Azure Monitor OpenTelemetry?.

Для новых проектов рекомендуется использовать Azure Monitor OpenTelemetry Distro.

OpenTelemetry предоставляет преимущества по сравнению с пакетами SDK для классического API Application Insights, в том числе:

• Улучшенная стандартизация на разных платформах
• Более широкая экосистема библиотек инструментирования
• Большую гибкость в сборе и обработке данных
• Улучшен нейтралитет поставщика, хотя Azure Monitor OpenTelemetry Distro по-прежнему оптимизирован для Azure.

Если вы используете пакеты SDK для .NET или Node.js Classic API, см. Миграция с пакетов SDK Classic API Application Insights на Azure Monitor OpenTelemetry.

Для ASP.NET Core, Java, Node.jsи Python рекомендуется использовать дистрибутив OpenTelemetry Azure Monitor. Это всего одна строка кода, чтобы начать.

Для всех других сценариев .NET, включая классические ASP.NET, консольные приложения, Windows Forms (WinForms) и т. д., мы рекомендуем использовать экспортер OpenTelemetry .NET Azure Monitor: Azure.Monitor.OpenTelemetry.Exporter.

Для более сложных сценариев телеметрии Python, требующих расширенной настройки, рекомендуется использовать Python Azure Monitor OpenTelemetry Exporter.

Дистрибутив OpenTelemetry для Azure Monitor достиг функционального паритета с набором средств разработки (SDK) для классического API Application Insights.

Последние сведения о возможностях code analysis см. в разделе .NET Profiler и Snapshot Debugger.

Да, но мы не рекомендуем его и Azure не поддерживает его. JavaScript OpenTelemetry оптимизирован для Node.js. Вместо этого рекомендуется использовать пакет SDK JavaScript для Application Insights.

Веб-пакет SDK OpenTelemetry не имеет определенной временной шкалы доступности. Скорее всего, пройдёт несколько лет, прежде чем появится SDK для браузера, который станет равнозначной альтернативой JavaScript SDK для Application Insights.

Веб-песочница OpenTelemetry — это форк, предназначенный для работы с OpenTelemetry в браузере. Пока невозможно отправить данные телеметрии в Application Insights. Пакет SDK не определяет общие события клиента.

Эта практика не является тем, что мы планируем тестировать или поддерживать, хотя наши дистрибутивы позволяют экспортировать на конечную точку OTLP наряду с Azure Monitor.

Это не рекомендуемый вариант. Ознакомьтесь с дополнительными условиями использования для предварительных версий Microsoft Azure.

Некоторые клиенты используют сборщик OpenTelemetry в качестве альтернативы агенту, хотя корпорация Майкрософт официально не поддерживает подход на основе агента для мониторинга приложений. В то же время сообщество open-source внесло вклад в OpenTelemetry Collector Azure Monitor Exporter, который некоторые клиенты используют для отправки данных в Azure Monitor Application Insights. Это не поддерживается корпорацией Майкрософт.

Вы можете попытаться визуализировать необработанные текстовые логи, а не трассировки OpenTelemetry.

В Application Insights таблица Traces хранит необработанные текстовые журналы для диагностических целей. Они помогают определить и сопоставить трассировки, связанные с запросами пользователей, другими событиями и отчетами об исключениях. Однако таблица "Traces" не вносит прямого вклада в представление сквозных транзакций (каскадную диаграмму) в таких средствах визуализации, как Grafana.

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

Чтобы настроить приложение Blazor, сначала определите модель размещения. Blazor Server поддерживает полное инструментирование на основе OpenTelemetry. Blazor WebAssembly выполняется в браузере и поддерживает ограниченное инструментирование с помощью JavaScript.

Нет, на панели мониторинга отображается ограничение в 30 дней.

Ошибка "не найдена" при перемещении или переименовании экземпляра Application Insights.

Чтобы обойти это поведение, удалите панель мониторинга по умолчанию и снова выберите панель мониторинга приложений, чтобы повторно создать новую.

Для получения дополнительной информации см. панель «Обзор Application Insights».

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

• При сбое приложения элементы в памяти теряются.
• Данные телеметрии теряются в случае продолжительных сетевых неполадок. Данные телеметрии сохраняются на локальном диске во время отключения сети или при возникновении проблем с серверной частью Application Insights. Однако элементы, возраст которых превышает 48 часов, удаляются.
• Места на диске для хранения телеметрии в Windows по умолчанию — это %LOCALAPPDATA% или %TEMP%. Эти расположения обычно являются локальными для компьютера. Если приложение переносится физически из одного расположения в другое, все данные телеметрии, хранящиеся в исходном расположении, теряются.
• В Azure Web Apps на Windows место хранения на диске по умолчанию — D:\local\LocalAppData. Это расположение не постоянно. Она удаляется в перезапусках приложений, горизонтальном масштабировании и других таких операциях, что приводит к потере данных телеметрии, хранящихся там. Можно переопределить значение по умолчанию и указать хранилище в постоянное расположение, например в D:\home. Однако такие постоянные размещения обслуживаются удаленными хранилищами и поэтому могут быть медленными.

Хотя это менее вероятно, возможно, что канал может вызвать повторяющиеся элементы телеметрии. Это поведение наблюдается, когда ServerTelemetryChannel повторные попытки происходят из-за сбоя сети или превышения времени ожидания: данные телеметрии доставлены на сервер, но ответ потерян из-за сетевых проблем или истечения времени ожидания.

Хотя имя пакета и пространства имен содержит "WindowsServer", этот канал поддерживается на системах, работающих под управлением других ОС, за исключением следующего. В системах, отличных от Windows, канал по умолчанию не создает локальную папку storage. Необходимо создать локальную папку хранения и настроить канал для её использования. После настройки локального хранилища канал работает одинаково на всех системах.

Пакет SDK хранит элементы телеметрии в локальном хранилище данных во время проблем с сетью или в случае ограничения трафика. Эти данные не шифруются в локальном хранилище.

Для систем Windows пакет SDK автоматически создает временную локальную папку в каталоге %TEMP% или %LOCALAPPDATA% и ограничивает access только администраторам и текущему пользователю.

Для систем, отличных от Windows, пакет SDK не создает локальное хранилище автоматически, поэтому данные по умолчанию не сохраняются локально.

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

Дополнительные сведения см. в разделе "Каналы телеметрии" в Application Insights.

См. сводку по ограничениям.

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

Azure Functions не регистрирует строки запроса URL-адреса.

Дополнительные сведения см. в разделе "Поиск и диагностика".

Возможные причины:

• Все ли другие компоненты инструментированы с помощью Application Insights?
• Они используют последнюю стабильную версию SDK для Application Insights?
• Если эти компоненты являются отдельными ресурсами Application Insights, проверьте наличие access. Если у вас есть доступ и компоненты подключены к последним наборам средств разработки Application Insights, сообщите нам через канал обратной связи, доступный в правом верхнем углу экрана.

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

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

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

В интерфейсе диагностики транзакций отображаются все данные телеметрии в одной операции , которая использует идентификатор операции. По умолчанию пакет SDK для JavaScript в Application Insights создает новую операцию для каждого уникального просмотра страницы. В одностраничном приложении (SPA) создается только одно событие представления страницы, а для всех созданных данных телеметрии используется один идентификатор операции. В результате многие события могут быть сопоставлены с одной и той же операцией.

В этих сценариях можно использовать автоматическое отслеживание маршрутов для автоматического создания новых операций для навигации в SPA. Необходимо включить enableAutoRouteTracking , чтобы представление страницы создавалось при каждом обновлении маршрута URL-адреса (логическое представление страницы). Если вы хотите вручную обновить идентификатор операции, вызовите appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Активация события PageView вручную также сбрасывает идентификатор операции.

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

Если все вызовы были инструментированы, вероятной основной причиной затраченного времени является процесс. Полезным средством диагностики процесса является .NET Profiler.

Эта ошибка означает, что браузеру не удалось вызвать необходимый API или API вернул ответ, указывающий на сбой. Чтобы устранить неполадки в поведении, откройте окно InPrivateбраузера и отключите все запущенные расширения браузера , а затем определите, можно ли воспроизвести поведение портала. Если ошибка портала по-прежнему возникает, попробуйте провести тестирование с другими браузерами или другими компьютерами, изучить dns или другие проблемы, связанные с сетью, на клиентском компьютере, где вызовы API завершаются сбоем. Если ошибка портала продолжается и требует дополнительного изучения, соберите сетевой отчет браузера при воспроизведении неожиданного поведения портала, а затем откройте заявку на поддержку из портала Azure.

Дополнительные сведения см. в статье "Исследование сбоев, производительности и транзакций с помощью Application Insights".

Начальное событие на визуализации отражает только первый раз, когда пользователь отправил просмотр страницы или пользовательское событие в течение сеанса. Если пользователи могут отправлять начальное событие несколько раз в сеансе, то в столбце "Шаг 1 " отображается только поведение пользователей после первого экземпляра начального события, а не всех экземпляров.

Используйте разделитель по параметрам в меню "Изменить":

1. Выберите событие, которое нужно разбить в меню "Событие ".

2. Выберите измерение в меню "Измерение ". Например, если у вас есть событие с именем Button Clicked, попробуйте пользовательское свойство с именем Button Name.

Когорты и фильтры отличаются. Предположим, что у вас есть когорта пользователей из Соединенного Королевства (определенный как предыдущий пример), и вы сравниваете результаты с настройкой фильтра Country or region = United Kingdom:

• Версия с когортой покажет все события пользователей, которые отправили одно или больше событий из Соединенного Королевства в текущем временном диапазоне. Если выполнить разделение по стране или региону, скорее всего, отобразится множество стран и регионов.

• В версии с фильтрами будут показаны только события из Соединенного Королевства. Если вы разделены по стране или региону, вы увидите только Соединенное Королевство.

Вы можете выбрать фильтр даты и зерна, чтобы изменить его. Фильтр доступен на всех вкладках размерности.

Если доступные визуальные представления не дают ответы на все ваши вопросы, вы можете углубиться в данные, которые поступают в книгу HEART. Чтобы выполнить эту задачу, в разделе Monitoring в Application Insights выберите Logs и запросите таблицу customEvents. Некоторые атрибуты Click Analytics содержатся в customDimensions поле.

Ниже показан пример запроса:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Дополнительные сведения о журналах в мониторе Azure см. в статье Azure Обзор журналов мониторинга.

Да. Чтобы узнать, как изменить шаблоны рабочих книг, см. шаблоны рабочих книг Azure.

Дополнительные сведения см. в разделе "Анализ использования" с помощью Application Insights.

Да, конфигурация общая для остальной части веб-приложения.

Получите экземпляр TelemetryClient с помощью внедрения конструктора и вызовите необходимый TrackXXX() метод на нем. Мы не рекомендуем создавать новые экземпляры TelemetryClient. Одиночный экземпляр TelemetryClient уже зарегистрирован в контейнере DependencyInjection, который разделяет TelemetryConfiguration с остальной телеметрией. Создавать новые экземпляры TelemetryClient рекомендуется только в том случае, если вам нужна конфигурация, отличная от настроек для основной части телеметрии.

Visual Studio IDE в настоящее время поддерживает настройку только для приложений ASP.NET/ASP.NET Core. Этот документ обновляется, когда Visual Studio предоставляет поддержку подключения приложений рабочей службы.

Нет. Azure Monitor Application Insights Agent в настоящее время поддерживает только .NET.

Да. Поддержка функций для пакета SDK одинакова на всех платформах, за исключением следующих моментов:

• Счетчики производительности поддерживаются только в Windows, за исключением ЦП или памяти процесса, показанных в динамических метриках.

• Несмотря на то, что ServerTelemetryChannel включен по умолчанию, если приложение работает в Linux или macOS, канал не создает локальную папку storage, чтобы временно сохранять данные телеметрии при возникновении проблем с сетью. Из-за этого ограничения данные телеметрии теряются при наличии временных проблем с сетью или сервером. Чтобы устранить эту проблему, настройте локальную папку для канала:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

Дополнительные сведения см. в разделе Application Insights для приложений рабочей службы (не http-приложений).