Устранение неполадок с отсутствующими данными телеметрии приложений в Azure Monitor Application Insights

  • Статья

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

Действия, которые могут привести к отсутствовать телеметрии

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

Шаги, которые данные телеметрии передаются в конвейере обработки.

Если данные телеметрии приложения не отображаются в портал Azure, причиной могут быть сбои между шагами в конвейере обработки:

  • Пакет SDK или агент Application Insights настроен неправильно и не отправляет данные телеметрии приложения в конечную точку приема.
  • Пакет SDK или агент настроены правильно, но сеть блокирует вызовы к конечной точке приема.
  • Конечная точка приема удаляет или регулирует входящие данные телеметрии.
  • Конвейер приема данных снижает или сильно замедляет данные телеметрии в рамках обработки из-за работоспособности службы.
  • (редко) Log Analytics сталкивается с проблемами работоспособности службы при сохранении записей телеметрии.
  • (редко) Сбой API запроса при api.applicationinsights.io запросе записей из Log Analytics.
  • Портал Azure не удается извлечь или отобразить записи, которые вы пытаетесь просмотреть.

Определение шага путем отправки примера записи телеметрии

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

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

$ProgressPreference = "SilentlyContinue"
Invoke-WebRequest -Uri $url -Method POST -Body $availabilityData -UseBasicParsing

Примечание.

  • Перед выполнением командлета Invoke-WebRequest выполните командлет $ProgressPreference = "SilentlyContinue" .
  • Нельзя использовать -Verbose или -Debug. Вместо этого используйте -UseBasicParsing.

После отправки примера записи телеметрии с помощью PowerShell перейдите на вкладку Журналы Application Insights в портал Azure и проверка, если она появится. Если показан пример записи телеметрии, большая часть конвейера обработки удаляется.

Образец записи телеметрии, правильно сохраненный и отображаемый, означает следующее:

  • На локальном сервере или виртуальной машине есть DNS, который разрешается на правильный IP-адрес.
  • Сеть доставила пример в конечную точку приема без блокировки или удаления.
  • Конечная точка приема приняла пример полезных данных и обработала ее через конвейер приема.
  • Log Analytics правильно сохранила образец записи.
  • На вкладке Журналы портал Azure можно запросить API (api.applicationinsights.io) и отобразить пример записи в портал Azure.

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

В следующих разделах содержатся сведения об отправке примера записи телеметрии с помощью PowerShell или curl.

Скрипт PowerShell для отправки результатов теста доступности

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

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

# Info: Provide either the connection string or ikey for your Application Insights resource
$ConnectionString = ""
$InstrumentationKey = ""
function ParseConnectionString {
param ([string]$ConnectionString)
  $Map = @{}
  foreach ($Part in $ConnectionString.Split(";")) {
     $KeyValue = $Part.Split("=")
     $Map.Add($KeyValue[0], $KeyValue[1])
  }
  return $Map
}
# If ikey is the only parameter supplied, we'll send telemetry to the global ingestion endpoint instead of regional endpoint found in connection strings
If (($InstrumentationKey) -and ("" -eq $ConnectionString)) {
$ConnectionString = "InstrumentationKey=$InstrumentationKey;IngestionEndpoint=https://dc.services.visualstudio.com/"
}
$map = ParseConnectionString($ConnectionString)
$url = $map["IngestionEndpoint"] + "v2/track"
$ikey = $map["InstrumentationKey"]
$lmUrl = $map["LiveEndpoint"]
$time = (Get-Date).ToUniversalTime().ToString("o")
$availabilityData = @"
{
  "data": {
        "baseData": {
            "ver": 2,
            "id": "SampleRunId",
            "name": "Microsoft Support Sample Webtest Result",
            "duration": "00.00:00:10",
            "success": true,
            "runLocation": "Region Name",
            "message": "Sample Webtest Result",
            "properties": {
                "Sample Property": "Sample Value"
                }
        },
        "baseType": "AvailabilityData"
  },
  "ver": 1,
  "name": "Microsoft.ApplicationInsights.Metric",
  "time": "$time",
  "sampleRate": 100,
  "iKey": "$ikey",
  "flags": 0
}
"@
# Uncomment one or more of the following lines to test client TLS/SSL protocols other than the machine default option
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::SSL3
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS11
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS12
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS13
$ProgressPreference = "SilentlyContinue"
Invoke-WebRequest -Uri $url -Method POST -Body $availabilityData -UseBasicParsing

Этот скрипт создает необработанный запрос REST для доставки единого результата теста доступности компоненту Application Insights. При использовании этого скрипта $ConnectionString укажите параметр или $InstrumentationKey .

  • Если указан только параметр строка подключения, данные телеметрии будут отправляться в региональную конечную точку в строка подключения.
  • Если указан только параметр ключа инструментирования (ikey), данные телеметрии будут отправляться в глобальную конечную точку приема.
  • Если указаны параметры строка подключения и ikey, скрипт отправляет данные телеметрии в региональную конечную точку в строка подключения.

Примечание.

  • Проверьте подключение, созданное приложением. Если включить Application Insights в портал Azure, скорее всего, используются строки подключения с региональными конечными точками https://<region>.in.applicationinsights.azure.com. Если конфигурация пакета SDK предоставляет только ключ ikey, вы полагаетесь на глобальную конечную точку . https://dc.applicationinsights.azure.com Обязательно заполните параметр скрипта, соответствующий конфигурации пакета SDK веб-приложения, указав строка подключения или ikey.
  • 31 марта 2025 г. поддержка приема ключей инструментирования прекратится. Прием ключей инструментирования будет продолжать работать, но мы больше не будем предоставлять обновления или поддержку этой функции. Переход на строки подключения , чтобы воспользоваться преимуществами новых возможностей.

Проще всего запустить этот скрипт из среды интегрированной среды сценариев PowerShell на экземпляре масштабируемого набора виртуальных машин IaaS или Azure . Вы также можете скопировать и вставить скрипт в консоль отладки PowerShell интерфейса Kudu Служба приложений, а затем запустить его.

При выполнении скрипта найдите ответ HTTP 200 и просмотрите сведения об ответе. В составе полезных данных JSON ответа ожидаются следующие сведения:

  • Счетчик itemsReceived соответствует itemsAccepted.
  • Конечная точка приема информирует клиента: вы отправили одну запись телеметрии, и мы приняли одну запись телеметрии.

В качестве примера см. следующий снимок экрана:

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

Команда Curl для отправки результатов теста доступности

Если вы используете виртуальные машины Linux, используйте curl вместо PowerShell для отправки аналогичного запроса REST. Необходимо изменить имя узла конечной точки приема, iKey значение и time значения. Конечная точка приема Application Insights не принимает записи старше 48 часов.

Ниже приведены примеры команд curl, которые отправляют один результат теста доступности:

  • Команда Curl для Linux/MacOS:

    curl -H "Content-Type: application/json" -X POST -d '{"data":{"baseData":{"ver":2,"id":"SampleRunId","name":"MicrosoftSupportSampleWebtestResultUsingCurl","duration":"00.00:00:10","success":true,"runLocation":"RegionName","message":"SampleWebtestResult","properties":{"SampleProperty":"SampleValue"}},"baseType":"AvailabilityData"},"ver":1,"name":"Microsoft.ApplicationInsights.Metric","time":"2022-09-01T12:00:00.0000000Z","sampleRate":100,"iKey":"########-####-####-####-############","flags":0}' https://dc.applicationinsights.azure.com/v2.1/track

  • Команда Curl для Windows:

    curl -H "Content-Type: application/json" -X POST -d {\"data\":{\"baseData\":{\"ver\":2,\"id\":\"SampleRunId\",\"name\":\"MicrosoftSupportSampleWebtestResultUsingCurl\",\"duration\":\"00.00:00:10\",\"success\":true,\"runLocation\":\"RegionName\",\"message\":\"SampleWebtestResult\",\"properties\":{\"SampleProperty\":\"SampleValue\"}},\"baseType\":\"AvailabilityData\"},\"ver\":1,\"name\":\"Microsoft.ApplicationInsights.Metric\",\"time\":\"2021-10-05T22:00:00.0000000Z\",\"sampleRate\":100,\"iKey\":\"########-####-####-####-############\",\"flags\":0} https://dc.applicationinsights.azure.com/v2/track

Скрипт PowerShell для отправки записи телеметрии запроса

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

# Info: Provide either the connection string or ikey for your Application Insights resource
$ConnectionString = ""
$InstrumentationKey = ""
function ParseConnectionString {
param ([string]$ConnectionString)
  $Map = @{}
  foreach ($Part in $ConnectionString.Split(";")) {
     $KeyValue = $Part.Split("=")
     $Map.Add($KeyValue[0], $KeyValue[1])
  }
  return $Map
}
# If ikey is the only parameter supplied, we'll send telemetry to the global ingestion endpoint instead of regional endpoint found in connection strings
If (($InstrumentationKey) -and ("" -eq $ConnectionString)) {
$ConnectionString = "InstrumentationKey=$InstrumentationKey;IngestionEndpoint=https://dc.services.visualstudio.com/"
}
$map = ParseConnectionString($ConnectionString)
$url = $map["IngestionEndpoint"] + "v2/track"
$ikey = $map["InstrumentationKey"]
$lmUrl = $map["LiveEndpoint"]
$time = (Get-Date).ToUniversalTime().ToString("o")
$requestData = @"
{
   "data": {
      "baseType": "RequestData",
      "baseData": {
        "ver": 2,
        "id": "22093920382029384",
        "name": "GET /msftsupport/requestdata/",
        "starttime": "$time",
        "duration": "00:00:01.0000000",
        "success": true,
        "responseCode": "200",
        "url": "https://localhost:8080/requestData/sampleurl",
        "httpMethod": "GET"
       }
   },
   "ver": 1,
   "iKey": "$ikey",
   "name": "Microsoft.ApplicationInsights.Request",
   "time": "$time",
   "sampleRate": 100,
   "flags": 0
}
"@
# Uncomment one or more of the following lines to test client TLS/SSL protocols other than the machine default option
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::SSL3
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS11
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS12
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS13
$ProgressPreference = "SilentlyContinue"
Invoke-WebRequest -Uri $url -Method POST -Body $requestData -UseBasicParsing

Устранение неполадок с конфигурацией SSL или TLS

Если приведенные выше скрипты завершаются ошибкой, устраните неполадки с конфигурацией SSL или TLS. Большинству конечных точек приема требуется, чтобы клиенты использовали TLS 1.2 и определенные наборы шифров. В этом случае настройте способ участия PowerShell в качестве клиента в протоколе SSL или TLS. Добавьте следующие фрагменты кода, если необходимо диагностировать безопасный канал как часть подключения между клиентской виртуальной машиной и конечными точками приема.

  • Вариант 1. Укажите, какой протокол SSL или TLS используется PowerShell для подключения к конечной точке приема.

    Раскомментируйте любую из следующих строк, удалив # символ и добавьте их перед командлетом Invoke-WebRequest в скрипте PowerShell для управления протоколом, используемым в тестовом запросе REST:

    # Uncomment one or more of these lines to test TLS/SSL protocols other than the machine default option
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::SSL3
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS11
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS12
# [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS13

  • Вариант 2. Игнорируйте все проблемы с проверкой SSL-сертификата.

    Если у вас есть брандмауэр или прокси-сервер, участвующий в разгрузке SSL-сертификатов, проигнорируйте все проблемы с SSL-сертификатами, добавив следующий фрагмент кода непосредственно перед командлетом Invoke-WebRequest :

    # Ignore mismatched SSL certificate
add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

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

Если вам нужно изменить протокол TLS/SSL по умолчанию, используемый приложением .NET, следуйте инструкциям в статье Рекомендации по безопасности транспортного уровня (TLS) с помощью платформа .NET Framework.

Устранение неполадок при установке или настройке пакета SDK или агента Application Insights

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

Если тестам, выполненным с помощью PowerShell или curl, не удается отправить данные телеметрии в конечную точку приема, проверьте несколько распространенных проблем на стороне клиента, которые могут способствовать возникновению проблемы:

  • DNS в сети не удается разрешить конечную точку приема на правильный IP-адрес.
  • TCP-подключение с сервера приложений к конечной точке приема может быть заблокировано брандмауэрами или устройствами шлюза.
  • Для конечной точки приема, к которому подключается пакет SDK, может потребоваться ПРОТОКОЛ TLS 1.2, но приложение может по умолчанию использовать TLS 1.0 или TLS 1.1.
  • У вас может быть несколько Приватный канал Azure Monitor, влияющих на частную сеть, которые могут перезаписать записи DNS для разрешения конечной точки приема на неправильный частный IP-адрес.

Свяжитесь с нами для получения помощи

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