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

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

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

Из серверных веб-приложений:

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

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

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

  • Трассировка стека
  • Сведения об исключении и сообщение, сопровождающее ошибку
  • Номер строки и столбца с ошибкой
  • 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. Он работает для приложений, размещенных в любом месте, а не только в 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 может автоматически создавать папку хранилища. Порядок предпочтения: ${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{INSTRUMENTATION KEY}. Можно изменить префикс файла, используемый для временного каталога во время выполнения программы.

  Пример узла:

  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='InstrumentationKey=00000000-0000-0000-0000-000000000000',
                            storage_path='/var/tmp/ai-cache')
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. В агенте Application Insights 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 можно удалить с помощью диспетчер пакетов NuGet в Visual Studio.

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

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

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

• 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

  Если в проекте есть файл 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
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           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 для консольных приложений.

Дополнительные сведения см. в статье "Настройка 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": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

Важно отметить, что в следующем примере поставщик 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 на портале Службы приложений. Если расширение установлено, оно отключается при обнаружении уже добавленного пакета SDK. Если включить Application Insights из расширения, то не потребуется устанавливать и обновлять пакет SDK. Но если вы включили Application Insights, следуя инструкциям в этой статье, то достигнете большей гибкости, поскольку:

• Данные телеметрии Application Insights продолжают собираться в:
  • со всеми операционными системами, включая Windows, Linux и Mac;
  • Все режимы публикации, включая автономные или зависящие от фреймворка.
  • Все целевые платформы, включая полную версию .NET Framework.
  • Все варианты размещения, включая веб-приложения, виртуальные машины, 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 можно удалить с помощью диспетчер пакетов NuGet в Visual Studio.

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

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

При добавлении телеметрии 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": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• 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 в вашем коде. Он не включает все необработанные исключения.

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

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

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

Дополнительные сведения см. в разделе "Счетчики для .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 не включает ведение журнала тел ответов, так как это создало бы слишком много данных телеметрии для большинства приложений.

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

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

• Дверь брандмауэра. Разрешите запросы к серверу из длинного и изменяемого списка агентов веб-тестирования.
• Пользовательский код: напишите собственный код для отправки периодических запросов на сервер из интрасети. Для этой цели можно выполнять веб-тесты 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 для результата веб-теста, который потенциально влияет.

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

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

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

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

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

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

  • 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, не обязательно совпадает с временем отклика сервера, наблюдаемым веб-приложениями. Это связано с тем, что Application Insights учитывает только длительность, когда запрос фактически достигает пользовательского приложения. Если запрос зависает или помещается в очередь в WebServer, время ожидания включается в метрики веб-приложения, но не в метрики Application Insights.

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

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

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

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

Если вы хотите использовать пользовательские метрики в Node.js, вручную оснастите приложения с помощью дистрибутива OpenTelemetry для Azure Monitor.

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

Автоинструментация AKS может нарушить работу телеметрии, отправляемой сторонним получателям через SDK OpenTelemetry с открытым исходным кодом.

Автоинструментация AKS предназначена для совместного использования с обоими ручными вариантами инструментирования: классическим пакетом SDK API Application Insights и дистрибутивом OpenTelemetry.

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

См. эту диаграмму, чтобы определить, имеет ли приоритет автоинструментация или ручное инструментирование.

Уязвимости, обнаруженные в дистрибутиве Azure Monitor OpenTelemetry, определяются по приоритету, исправлены и выпущены в следующей версии.

Автоинструментация AKS внедряет последнюю версию дистрибутива OpenTelemetry Azure Monitor в поды приложений каждый раз при изменении или перезапуске развертывания.

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

Эта функция обеспечивает автоинструментацию путем внедрения дистрибутива Azure Monitor OpenTelemetry в поды приложений.

Для Java эта функция интегрирует автономный дистрибутив Azure Monitor OpenTelemetry для Java. Дополнительные сведения о двоичном инструментировании Java см. в нашей документации по дистрибутиву Java.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На портале Azure:

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 использует новый поставщик. Правила фильтрации для вашего приложения можно изменить в файле appsettings.json.

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

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

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

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

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

Запись JFR можно просматривать и анализировать с помощью инструмента по вашему выбору, например Java Mission Control (JMC).

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

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

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

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

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

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

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

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

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

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

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

Локальная разработка относится к среде, в которой приложение создается или тестируется, например компьютер разработчика или экземпляр Azure Cloud Shell. Сервер приложений ссылается на веб-сервер, на котором запущено приложение, например Tomcat 11 в среде службы приложений 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 открытый код. Чтобы просмотреть исходный код или принять участие в проекте, см. официальный репозиторий GitHub.

Дополнительные сведения см. в статье "Включение реального мониторинга пользователей Azure Monitor Application Insights".

На стороне сервера должна быть возможность принимать подключения с такими заголовками. В зависимости от конфигурации 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 плохим шлюзом" и "503 служба недоступна" в службе приложение Azure.

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

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

Иногда эти данные могут быть отсутствуют или неточные, если пользователь или предприятие отключает отправку агента пользователя в параметрах браузера. Синтаксические выражения анализатора UA Parser могут не включать всю информацию об устройстве. Или 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".

Дополнительные сведения см. в статье Сбор данных телеметрии с помощью 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 также можно использовать для применения правил фильтрации по конкретному сигналу.

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

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

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

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

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

В пакете SDK для Application Insights для .NET используйте процессоры телеметрии для фильтрации и изменения или отмены данных телеметрии. Инициализаторы телеметрии используются для добавления или изменения настраиваемых свойств. Дополнительные сведения см. в документации по 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 Monitor" помечает любой 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.

OpenTelemetry .NET использует 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 в OpenTelemetry .NET. Для операций с 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 не имеет понятия "Инструменты". Application Insights имеет один и тот же API для всех сценариев метрик.

С другой стороны, OpenTelemetry требует, чтобы пользователи сначала выбрали правильный инструмент метрик на основе фактической семантики метрики. Например, если намерение состоит в том, чтобы подсчитать что-то (например, количество полученных общих запросов сервера и т. д.), следует использовать счетчик OpenTelemetry. Если намерение состоит в вычислении различных процентилей (например, значения задержки сервера P99), следует использовать инструмент гистограммы OpenTelemetry. Из-за этого фундаментального различия между 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 принимает решения по выборке после создания отслеживаемого фрагмента, а не раньше, поэтому он не следует традиционному подходу на основе начальной точки. Вместо этого она применяет решения выборки в конце формирования диапазона — после завершения его формирования, но перед экспортом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ознакомьтесь с нашей документацией по поддержке для .NET, Java, JavaScript (Node.js) и Python.

Мы рекомендуем использовать дистрибутив Azure Monitor OpenTelemetry для новых проектов, если его возможности соответствуют вашим потребностям мониторинга. OpenTelemetry — это стандартный в отрасли фреймворк, который улучшает наблюдаемость на различных платформах и обеспечивает стандартный подход к сбору телеметрии.

Однако пакеты SDK Application Insights по-прежнему предоставляют определенные возможности, которые еще не полностью автоматизированы в OpenTelemetry, в том числе:

• Автоматическое отслеживание зависимостей — OpenTelemetry поддерживает отслеживание зависимостей, но для некоторых зависимостей требуется дополнительная конфигурация по сравнению с автоматическим отслеживанием, доступным в пакетах SDK Application Insights.
• Пользовательские типы телеметрии, такие как AvailabilityTelemetry и PageViewTelemetry, в OpenTelemetry не имеют прямых эквивалентов. Аналогичные функции можно реализовать с помощью ручного инструментирования.
• Процессоры телеметрии и инициализаторы — OpenTelemetry имеет процессоры и процессоры диапазона, но они не полностью заменяют процессоры телеметрии Application Insights и инициализаторы во всех сценариях.
• Расширенная коллекция метрик . Хотя OpenTelemetry имеет сильную систему метрик, некоторые встроенные метрики из пакетов SDK Application Insights требуют ручной настройки в OpenTelemetry.

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

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

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

Для 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, требующих расширенной настройки, мы рекомендуем использовать экспортер Azure Monitor OpenTelemetry для Python.

На следующей диаграмме описана поддержка функций OpenTelemetry для каждого языка.

Ключ

• ✅ Эта функция доступна всем клиентам с официальной поддержкой.
• ⚠️ Эта функция доступна как общедоступная предварительная версия. Дополнительные условия использования для предварительных версий службы Microsoft Azure.
• ❌ Эта функция недоступна или не применима.

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

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

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

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

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

Ознакомьтесь с обзором OpenTelemetry.

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

OpenCensus является предшественником OpenTelemetry. Корпорация Майкрософт помогла объединить OpenTracing и OpenCensus для создания OpenTelemetry, единого стандарта наблюдаемости для мира. Текущий рекомендуемый для использования в производственной среде Python SDK для Azure Monitor основан на OpenCensus. Корпорация Майкрософт стремится сделать Azure Monitor на основе OpenTelemetry.

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

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

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

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

Дополнительные сведения см. в разделе "Поддержка OpenTelemetry" и "Обратная связь" для Application Insights.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если доступные визуальные представления не дают ответы на все ваши вопросы, вы можете углубиться в данные, которые поступают в книгу HEART. Для этого в разделе "Мониторинг" в Application Insights выберите журналы и запросите таблицу 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 Monitor см. в обзоре журналов Azure Monitor.

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

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

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

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

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

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

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

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

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

  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-приложений).