Compartir a través de

Solución de problemas de telemetría de aplicaciones que faltan en Azure Monitor Application Insights

Este artículo le ayuda a identificar el paso de la canalización de procesamiento que hace que falten datos de telemetría mediante la prueba de la conectividad y la ingesta de telemetría mediante PowerShell o curl.

Azure Portal no puede extraer o representar los registros que está intentando ver

Si el punto de conexión de recopilación de datos de Application Insights está configurado para usar microsoft Entra ID (anteriormente Azure AD) para la autenticación, la aplicación también debe configurarse para autenticarse con el identificador de Microsoft Entra. En este escenario, la aplicación es responsable de la autenticación mediante el identificador de Microsoft Entra. Si la aplicación no está configurada correctamente, se rechaza la telemetría y no aparece en Azure Portal aunque la instrumentación aparezca correcta y la aplicación genere datos de telemetría.

Para configurar la aplicación para que se autentique mediante el identificador de Entra de Microsoft, siga los pasos descritos en Habilitación de la autenticación de Microsoft Entra ID (anteriormente Azure AD).

Pasos que pueden provocar que falten datos de telemetría

En el gráfico siguiente se muestran los pasos en los que la telemetría puede faltar durante la ingesta y el consumo:

Pasos que la telemetría pasa en la canalización de procesamiento.

Si la telemetría de la aplicación no se muestra en Azure Portal, los errores en los pasos de la canalización de procesamiento podrían ser la causa:

  • El SDK o el agente de Application Insights están mal configurados y no envían telemetría de la aplicación al punto de conexión de ingesta.
  • El SDK o el agente se configuran correctamente, pero la red bloquea las llamadas al punto de conexión de ingesta.
  • El punto de conexión de ingesta quita o limita la telemetría entrante.
  • La canalización de ingesta disminuye o ralentiza gravemente la telemetría como parte de su procesamiento debido al estado del servicio.
  • (Poco frecuente) Log Analytics se enfrenta a problemas de mantenimiento del servicio al guardar registros de telemetría.
  • (Poco frecuente) Se produce un error en api.applicationinsights.io la API de consulta al consultar registros de Log Analytics.
  • Otras posibles causas y soluciones se discuten en Solucionar problemas de telemetría de aplicaciones que falta en Azure Monitor Application Insights.

Sugerencia

Los equipos de soporte técnico de Application Insights no pueden ayudar con problemas de red. Al enviar una incidencia de soporte técnico para problemas de red que impiden que Application Insights reciba datos de telemetría, como errores de resolución de DNS, asegúrese de especificar redes de Azure o Azure Private Link en el producto o la descripción del problema en Azure Portal. Esto garantiza que el caso de soporte técnico se enrute correctamente.

Identificación paso mediante el envío de un registro de telemetría de ejemplo

Los problemas de configuración o los problemas transitorios pueden producirse en cualquier lugar del servicio Applications Insights. Para identificar el paso dentro de la canalización de procesamiento que causa síntomas de ningún dato o datos que faltan, envíe un registro de telemetría de ejemplo mediante PowerShell o curl. Para el script de PowerShell o el comando curl, vaya a las secciones siguientes:

Si la aplicación web se ejecuta en un servidor local o una máquina virtual de Azure, conéctese al servidor o a la máquina virtual y envíe un único registro de telemetría a la instancia del servicio Applications Insights mediante PowerShell. Si la aplicación web que tiene problemas para enviar telemetría se ejecuta en Kudu, ejecute el siguiente script desde la consola de depuración de PowerShell de Kudu en Azure Web Apps.

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

Nota:

  • Antes de ejecutar el Invoke-WebRequest cmdlet, emita el $ProgressPreference = "SilentlyContinue" cmdlet .
  • No se puede usar -Verbose ni -Debug. En su lugar, use -UseBasicParsing.

Después de enviar un registro de telemetría de ejemplo mediante PowerShell, vaya a la pestaña Registros de Application Insights en Azure Portal y compruebe si llega. Si se muestra el registro de telemetría de ejemplo, se elimina una gran parte de la canalización de procesamiento.

Un registro de telemetría de ejemplo que se guarda y muestra correctamente significa:

  • El servidor local o la máquina virtual tiene DNS que se resuelve en la dirección IP correcta.
  • La red entregó el ejemplo al punto de conexión de ingesta sin bloquear ni quitar.
  • El punto de conexión de ingesta aceptó la carga de ejemplo y la procesó a través de la canalización de ingesta.
  • Log Analytics guardó correctamente el registro de ejemplo.
  • La pestaña Registros de Azure Portal puede consultar la API (api.applicationinsights.io) y representar el registro de ejemplo en Azure Portal.

Si el registro de ejemplo generado llega a la instancia de Application Insights y puede consultar el registro de ejemplo mediante el menú de recursos Registros , solucione los problemas del SDK o el agente de Application Insights. Ahora puede recopilar registros del SDK, registros de autodiagnóstico o seguimientos del generador de perfiles, según corresponda para la versión del SDK o del agente.

En las secciones siguientes se proporciona información sobre cómo enviar un registro de telemetría de ejemplo mediante PowerShell o curl.

Script de PowerShell para enviar el resultado de la prueba de disponibilidad

Los resultados de las pruebas de disponibilidad son el tipo de telemetría ideal con el que probar. El motivo es que la canalización de ingesta nunca muestrea los resultados de las pruebas de disponibilidad. Si envía un registro de telemetría de solicitud, se podría muestrear cuando ha habilitado el muestreo de ingesta. Comience con un resultado de prueba de disponibilidad de ejemplo y pruebe otros tipos de telemetría según sea necesario.

Este es un script de PowerShell de ejemplo que envía un resultado de prueba de disponibilidad:

# 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

Este script crea una solicitud REST sin procesar para entregar un único resultado de prueba de disponibilidad al componente de Application Insights. Cuando use este script, proporcione el $ConnectionString parámetro o $InstrumentationKey .

  • Si se proporciona únicamente el parámetro de cadena de conexión, la telemetría se envía al punto de conexión regional en la cadena de conexión.
  • Si solo se proporciona el parámetro de clave de instrumentación (ikey), la telemetría se envía al punto de conexión de ingesta global.
  • Si se proporcionan tanto la cadena de conexión como los parámetros ikey, el script envía la telemetría al punto de conexión regional especificado en la cadena de conexión.

Nota:

  • Pruebe la conexión realizada por la aplicación. Si habilita Application Insights en Azure Portal, es probable que confíe en cadena de conexión con puntos de conexión regionales, https://<region>.in.applicationinsights.azure.com. Si la configuración del SDK solo proporciona la clave ikey, se basa en el punto de conexión global, https://dc.applicationinsights.azure.com. Asegúrese de rellenar el parámetro de script que coincida con la configuración del SDK de aplicación web, ya sea proporcionando el cadena de conexión o la clave ikey.
  • El 31 de marzo de 2025 finalizó el soporte para la ingesta de las claves de instrumentación. La ingesta de claves de instrumentación sigue funcionando, pero ya no proporcionamos actualizaciones ni soporte para la funcionalidad. Transición a las cadenas de conexión para aprovechar las nuevas funcionalidades.

Es más fácil ejecutar este script desde el entorno de PowerShell ISE en una instancia de conjunto de escalado de máquinas virtuales de Azure o IaaS. También puede copiar y pegar el script en la consola de depuración de PowerShell de la interfaz kudu de App Service y, a continuación, ejecutarlo.

Cuando se ejecuta el script, busque una respuesta HTTP 200 y revise los detalles de la respuesta. Como parte de la carga JSON de respuesta, se esperan los detalles siguientes:

  • El itemsReceived recuento coincide con .itemsAccepted
  • El punto de conexión de ingesta informa al cliente: envió un registro de telemetría y aceptamos un registro de telemetría.

Consulte la captura de pantalla siguiente como ejemplo:

Código que muestra el número de elementos recibidos y aceptados.

Comando Curl para enviar el resultado de la prueba de disponibilidad

Si ejecuta máquinas virtuales Linux, use curl en lugar de PowerShell para enviar una solicitud REST similar. Debe ajustar el nombre de host del punto de conexión de ingesta, el iKey valor y los time valores. El punto de conexión de ingesta de Application Insights no acepta registros anteriores a 48 horas.

Estos son los comandos curl de ejemplo que envían un único resultado de prueba de disponibilidad:

  • Comando Curl para 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

  • Comando Curl para 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

Script de PowerShell para enviar el registro de telemetría de solicitudes

Para solucionar problemas de telemetría de solicitudes que faltan, use el siguiente script de PowerShell para probar el envío de un único registro de telemetría de solicitud. Este tipo de telemetría es susceptible a la configuración de muestreo de ingesta del lado servidor. Compruebe que el muestreo de ingesta está desactivado para confirmar si el registro de prueba se guarda correctamente.

# 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

Solución de problemas de configuración de SSL o TLS

Si se produce un error en estos scripts, solucione los problemas de configuración de SSL o TLS. La mayoría de los puntos de conexión de ingesta requieren que los clientes usen TLS 1.2 y conjuntos de cifrado específicos. En este caso, ajuste cómo Participa PowerShell como cliente en el protocolo SSL o TLS. Incluya los fragmentos de código siguientes si necesita diagnosticar un canal seguro como parte de la conexión entre la máquina virtual cliente y los puntos de conexión de ingesta.

  • Opción 1: Controlar qué protocolo SSL o TLS usa PowerShell para establecer una conexión con el punto de conexión de ingesta.

    Quite la marca de comentario de cualquiera de las líneas siguientes quitando el # carácter y agréguelos antes del cmdlet en el Invoke-WebRequest script de PowerShell para controlar el protocolo usado en la solicitud REST de prueba:

    # 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

  • Opción 2: Omitir los problemas de validación de certificados SSL.

    Si tiene un firewall o servidor proxy que participa en la descarga de certificados SSL, omita cualquier problema de certificado SSL agregando el siguiente fragmento de código justo antes del Invoke-WebRequest cmdlet:

    # 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

Si la aplicación tiene como valor predeterminado la configuración de TLS predeterminada del sistema o del servidor, cambie esa configuración predeterminada en el Registro en las máquinas Windows. Para más información, consulte Configuración del Registro de seguridad de la capa de transporte (TLS).

Si necesita cambiar el protocolo TLS/SSL predeterminado que usa una aplicación .NET, siga las instrucciones de procedimientos recomendados de seguridad de la capa de transporte (TLS) con .NET Framework.

Solución de problemas de configuración o configuración del SDK o agente de Application Insights

Si el envío de telemetría desde la máquina host de la aplicación mediante PowerShell o curl se realiza correctamente, es probable que falte telemetría debido a problemas de configuración o configuración del SDK o agente de Application Insights. Habilite la supervisión de Application Insights para el host de la aplicación y el lenguaje de programación para comprobar que todas las configuraciones o el código siguen instrucciones y ejemplos adecuados.

Si las pruebas realizadas mediante PowerShell o curl no pueden enviar telemetría al punto de conexión de ingesta, compruebe algunos problemas comunes relacionados con el cliente que pueden contribuir al problema:

  • DNS en la red no puede resolver el punto de conexión de ingesta en la dirección IP correcta.
  • La conexión TCP desde el servidor de aplicaciones al punto de conexión de ingesta puede estar bloqueada por firewalls o dispositivos de puerta de enlace.
  • El punto de conexión de ingesta al que se conecta el SDK puede requerir TLS 1.2, pero la aplicación puede usar TLS 1.0 o TLS 1.1 de forma predeterminada.
  • Es posible que tenga más de una instancia de Private Link de Azure Monitor que afecte a la red privada, lo que puede sobrescribir las entradas DNS para resolver el punto de conexión de ingesta en la dirección IP privada incorrecta.

Solución de problemas de autenticación de Microsoft Entra

En esta sección se proporcionan distintos escenarios de solución de problemas y pasos para resolver problemas de autenticación de Microsoft Entra antes de ponerse en contacto con el soporte técnico de Microsoft.

Errores HTTP de ingesta

El servicio de ingesta devuelve errores específicos independientemente del lenguaje del SDK. El tráfico de red se puede recopilar mediante una herramienta como Fiddler. Asegúrate de filtrar el tráfico al punto de conexión de recepción determinado en la cadena de conexión.

No se admite la autenticación HTTP/1.1 400

Este error muestra que el recurso se configura exclusivamente como solo para Microsoft Entra.

Revise y configure el SDK correctamente porque se envía a la API incorrecta.

Nota:

v2/track no admite el identificador de Entra de Microsoft. Si el SDK está configurado correctamente, la telemetría se envía a v2.1/track.

Se requiere autorización de HTTP/1.1 401

Este error indica que el SDK está configurado correctamente, pero no puede adquirir un token válido. Este error podría indicar que existe un problema que afecta al identificador de Entra de Microsoft.

Identifique las excepciones en los registros del SDK o los errores de red de Azure Identity.

HTTP/1.1 403 no autorizado

Este error significa que el SDK usa credenciales sin permiso para el recurso o la suscripción de Application Insights.

Compruebe el control de acceso para el recurso de Application Insights. Debe asegurarse de que la identidad utilizada por el SDK tenga asignado el rol de Publicador de Métricas de Supervisión.

Solución de problemas específicos del lenguaje

Habilitación de registros de errores

El SDK de .NET de Application Insights emite registros de errores mediante el origen del evento. Para obtener más información sobre la recopilación de registros de origen del evento, visite Solución de problemas cuando no hay datos: recopilación de registros con PerfView.

Si el SDK no obtiene un token, el mensaje de excepción se registra como "No se pudo obtener el token de AAD. Mensaje de error".

  • Last updated on