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

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

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

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

• HTTP-запросы.
• Зависимости, такие как SQL, HTTP, Azure Cosmos DB, Azure Table Storage, Хранилище BLOB-объектов Azure и вызовы Хранилище очередей Azure.
• Исключения и трассировки стека.
• Метрики времени выполнения из поддерживаемого инструментирования.
• Пользовательские события и метрики, которые вы отправляете с помощью пользовательской телеметрии OpenTelemetry, JavaScript SDK или Click Analytics.
• Журналы трассировки при настройке соответствующего сборщика.

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

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

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

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

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

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

  Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контекст

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

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

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

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

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

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

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

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

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

TLS

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

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

Если подключение к Azure потеряно или регулируется, поддерживаемые экспортеры OpenTelemetry и текущие пакеты SDK могут буферировать данные телеметрии локально и повторить попытку. Сведения о текущем поведении OpenTelemetry см. в статье "Автономное хранилище" и автоматические повторные попытки. Параметры буферизации браузера см. в конфигурации пакета SDK для JavaScript.

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

• Дистрибутив Azure Monitor OpenTelemetry
• Автоинструментация (автоматическое инструментирование)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.NET

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

Java

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

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

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

Node.js

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

Python

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

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

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

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.

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

Для пользовательских событий браузера используйте SDK JavaScript Application Insights или Click Analytics. Для пользовательских событий на стороне сервера используйте настраиваемые события OpenTelemetry.

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

Для текущих приложений .NET настройте коллекцию журналов с помощью OpenTelemetry и стандартной конфигурации .NET ведения журнала. Используйте Logging:LogLevel в appsettings.json для выбора уровней журналов приложений, и настройки экспорта журналов OpenTelemetry как часть настройки Azure Monitor OpenTelemetry. См. статью "Включить OpenTelemetry" с помощью Application Insights и изменить данные телеметрии.

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

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

Сведения о текущем инструментировании ASP.NET Core см. в разделе Включение OpenTelemetry с помощью Application Insights.

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

Сведения о текущих рекомендациях по метрикам см. в разделе "Метрики" в Application Insights.

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

Мониторинг службы приложений без изменений кода в настоящее время не поддерживает эту функцию для ASP.NET Core.

Сведения о текущих рекомендациях по метрикам см. в разделе "Метрики" в Application Insights.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не строго. Один ресурс Application Insights может получать данные телеметрии браузера из JavaScript SDK Application Insights и данные телеметрии на стороне сервера, отправляемые с аутентифицированной загрузкой, когда локальная проверка подлинности остается включенной для приема данных в браузере. Для телеметрии на стороне сервера можно использовать аутентифицированный прием Microsoft Entra, а для приема OTLP с использованием сборщика OpenTelemetry требуется аутентификация Microsoft Entra. Не нужно избегать OpenTelemetry или OTLP исключительно потому, что приложение также собирает данные телеметрии браузера.

Основное исключение заключается в том, что при отключении локальной проверки подлинности в ресурсе Application Insights необходимо использование аутентификации Microsoft Entra для всех операций ввода данных. В этой конфигурации пакет SDK JavaScript не может аутентифицироваться непосредственно из браузера, и поток телеметрии из браузера может прекратиться. Для телеметрии браузера в этом сценарии используйте отдельный ресурс телеметрии браузера с включенной локальной проверкой подлинности или маршрутизацией телеметрии браузера с помощью шаблона прокси-сервера с проверкой подлинности. Для получения дополнительной информации смотрите Телеметрия аутентифицированного браузера с использованием строк подключения.

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

Отдельный ресурс телеметрии браузера поможет вам:

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

Балансируйте эти преимущества с дополнительными издержками на управление несколькими ресурсами, включая дополнительные строки подключения, назначения RBAC, конфигурацию и проведение анализа взаимодействия между ресурсами. Сквозная корреляция по-прежнему может работать в нескольких ресурсах Application Insights, когда пользователь имеет доступ к соответствующим ресурсам. Дополнительные сведения см. в разделе "Карта приложений " и "Диагностика транзакций".

Приватный канал и аутентификация приёма данных — это отдельные механизмы управления. Приватный канал включает управление сетевым доступом к ресурсам Azure Monitor. Аутентификация Microsoft Entra управляет, разрешено ли удостоверением прием телеметрии. Не используйте Приватный канал в качестве замены для проверки подлинности приема и не рассматривайте разделение ресурсов как требование для приема на стороне сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Записи журнала OpenTelemetry хранятся в traces таблице в журналах Application Insights. Чтобы просмотреть их на портале Azure, откройте ресурс Application Insights, выберите Logs и запросите таблицу traces.

Пример запроса: traces | where message contains "YourSearchTerm".

Для текущих приложений .NET настройте коллекцию журналов с помощью OpenTelemetry и стандартной конфигурации .NET ведения журнала. Используйте Logging:LogLevel в appsettings.json для выбора уровней журналов приложений, и настройки экспорта журналов OpenTelemetry как часть настройки Azure Monitor OpenTelemetry. См. статью "Включить OpenTelemetry" с помощью Application Insights и изменить данные телеметрии.

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

Для существующего инструментирования отправьте пользовательские данные телеметрии с помощью API OpenTelemetry или дистрибутива Azure Monitor OpenTelemetry. Примеры см. в разделе Сбор пользовательской телеметрии.

Сведения о текущем инструментировании .NET см. в разделе Включение OpenTelemetry с помощью Application Insights.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пакет 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 открытый код. Чтобы просмотреть исходный код или внести свой вклад в project, ознакомьтесь с репозиторием official GitHub.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для текущего инструментирования ознакомьтесь с корреляцией распределенной трассировки и телеметрии. Сведения о телеметрии браузера JavaScript см. в разделе конфигурации пакета SDK для JavaScript.

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

Сведения о текущем инструментировании Node.js см. в разделе "Включить OpenTelemetry" с помощью Application Insights.

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

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

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

Используйте API OpenTelemetry и API-интерфейсы ведения журнала или метрик для конкретного языка. Примеры см. в разделе Сбор пользовательской телеметрии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Его использование не зависит от поставщика и обеспечивает согласованные API/пакеты SDK на различных языках программирования.
• Со временем мы считаем, что OpenTelemetry позволит Azure отслеживать приложения, написанные на языках за пределами наших поддерживаемых языков.
• Он расширяет типы данных, которые можно собирать с помощью расширенного набора библиотек инструментирования.
• Комплекты средств разработки программного обеспечения OpenTelemetry предназначены для масштабируемой и нейтральной к поставщикам телеметрии высокого уровня производительности.
• OpenTelemetry соответствует стратегии Майкрософт по embrace открытый код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Экспортеры и пакеты SDK OpenTelemetry обычно используют приблизительную доставку. Данные телеметрии могут быть потеряны, если приложение падает, процесс завершается до экспорта ожидающих данных телеметрии, хранилище недоступно или сбои сети и служб продолжаются за пределы установленных пределов повторных попыток. Сведения о текущем поведении OpenTelemetry см. в статье "Автономное хранилище" и автоматические повторные попытки.

Некоторые текущие экспортеры и пакеты SDK могут создавать временное локальное хранилище во время проблем с сетью или регулирования. Локальное временное хранилище не шифруется Application Insights, поэтому обеспечьте защиту любого настраиваемого каталога. Сведения о текущем поведении OpenTelemetry см. в статье "Автономное хранилище" и автоматические повторные попытки.

Сведения о текущем поведении повторных попыток и хранения OpenTelemetry см. в разделе "Конфигурация OpenTelemetry".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для текущих приложений служб рабочих процессов используйте экспортер или дистрибутив Azure Monitor OpenTelemetry. См. раздел "Включить OpenTelemetry" с помощью Application Insights.

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

Для пользовательских событий браузера используйте SDK JavaScript Application Insights или Click Analytics. Для пользовательских событий на стороне сервера используйте настраиваемые события OpenTelemetry.

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

Поддержка функций зависит от языка, среды размещения и пути инструментирования. Для текущей поддержки начните с включения OpenTelemetry с Application Insights и соответствующей статьи конфигурации для конкретного языка.

Сведения о инструментировании текущей рабочей службы см. в разделе Enable OpenTelemetry with Application Insights.