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

Статья
06/24/2024

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

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

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

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

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

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

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

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

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

Если веб-приложение выполняется на локальном сервере или виртуальной машине Azure, подключитесь к серверу или виртуальной машине и отправьте одну запись телеметрии в экземпляр службы Application Insights с помощью PowerShell. Если веб-приложение с проблемами отправки телеметрии выполняется в Kudu, выполните следующий сценарий из консоли отладки Kudu PowerShell в 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, и вы можете запросить образец записи с помощью меню ресурсов Logs, устранить неполадки с пакетом 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 марта 31, 2025 г. Прием ключей инструментирования будет и дальше осуществляться, но мы больше не будем предоставлять обновления или поддержку для этой функции. Перейдите на строки подключения, чтобы использовать новые возможности.

Проще всего запустить этот скрипт из среды isE PowerShell в экземпляре масштабируемого набора виртуальных машин Azure или IaaS. Вы также можете скопировать и вставить скрипт в консоль отладки интерфейса Kudu Служба приложений Интерфейс 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.

Поделиться через