Preguntas más frecuentes oficiales sobre Application Insights de Azure Monitor. Encuentre respuestas a preguntas sobre el uso de Application Insights con Azure Monitor.
Información general
Cómo instrumentar una aplicación
Para obtener información detallada sobre cómo instrumentar aplicaciones para habilitar Application Insights, consulte los conceptos básicos sobre la recopilación de datos.
¿Cómo uso Application Insights?
Después de habilitar Application Insights mediante la instrumentación de una aplicación, se recomienda primero desprotegerlas métricas en directoy elMapa de aplicación.
¿Qué telemetría recopila Application Insights?
De las aplicaciones web de servidor:
- Solicitudes HTTP.
- Dependencias. Llamadas a bases de datos SQL, llamadas HTTP a servicios externos, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage y Azure Queue Storage.
- Excepciones y seguimientos de pila.
- Contadores de rendimiento: los contadores de rendimiento están disponibles al usar:
- Eventos y métricas personalizados que puede crear mediante código.
- Registros de seguimiento si configura el recopilador adecuado.
Desde páginas web de cliente:
Excepciones no detectadas en la aplicación, incluida información sobre lo siguiente:
- Seguimiento de la pila
- Detalles de la excepción y mensaje que acompaña al error
- Número de línea y columna del error
- Dirección URL en la que se produjo el error
- Las solicitudes de dependencia de red realizadas por la aplicación a través de XMLHttpRequest (XHR) y Fetch (la recopilación Fetch está deshabilitada de forma predeterminada) incluyen información sobre:
- Dirección URL del origen de dependencia
- Comando y método usado para solicitar la dependencia
- Duración de la solicitud
- Código de resultado y estado de éxito de la solicitud
- Identificador (si existe) del usuario que realiza la solicitud
- Contexto de correlación (si existe) en el que se realiza la solicitud
Información del usuario (por ejemplo, ubicación, red, IP)
Información del dispositivo (por ejemplo, explorador, sistema operativo, versión, idioma, modelo)
Información de la sesión
Nota:
En algunas aplicaciones, como aplicaciones de página única (SPA), la duración no siempre se registra y, en esos casos, el valor predeterminado es 0.
Para obtener más información, consulte Recopilación, retención y almacenamiento de datos en Application Insights.
De otros orígenes, si los configura:
¿Cuántos recursos de Application Insights se deben implementar?
Para comprender el número de recursos de Application Insights necesarios para cubrir la aplicación o los componentes entre entornos, vea la Guía de planificación de la implementación de Application Insights.
¿Cómo puedo administrar los recursos de Application Insights mediante PowerShell?
También puede escribir scripts de PowerShell usando el Monitor de recursos de Azure para:
- Crear y actualizar recursos de Application Insights
- Establecer el plan de precios
- Obtener la clave de instrumentación
- Agregue una alerta de métrica.
- Agregar una prueba de disponibilidad.
No puede configurar un informe del explorador de métricas ni configurar la exportación continua.
¿Cómo puedo consultar la telemetría de Application Insights?
Use la API de REST para ejecutar consultas de Log Analytics.
¿Puedo enviar telemetría al portal de Application Insights?
Se recomienda la distribución de OpenTelemetry de Azure Monitor.
El esquema de ingesta y el protocolo de punto de conexión están disponibles públicamente.
¿Cuánto tiempo tarda la recopilación de telemetría?
La mayoría de los datos de Application Insights tienen una latencia de menos de 5 minutos. Algunos datos pueden tardar más, lo que es típico para los archivos de registro más grandes. Consulte el contrato de nivel de servicio de Application Insights.
¿Cómo controla Application Insights la recopilación, retención, almacenamiento y privacidad de datos?
Colección
Application Insights recopila datos de telemetría sobre la aplicación, incluida la telemetría del servidor web, la telemetría de página web y los contadores de rendimiento. Estos datos se pueden usar para supervisar el rendimiento, el estado y el uso de la aplicación. Puede seleccionar la ubicación cuando se crea un nuevo recurso de Application Insights.
Retención y almacenamiento
Los datos se envían a un área de trabajo de Log Analytics de Application Insights. Puede elegir el período de retención para los datos sin procesar, de 30 a 730 días. Los datos agregados se conservan durante 90 días y las instantáneas de depuración se conservan durante 15 días.
Privacidad
Application Insights no controla los datos confidenciales de forma predeterminada. Se recomienda no colocar datos confidenciales en direcciones URL como texto sin formato y asegurarse de que el código personalizado no recopila información personal u otros detalles confidenciales. Durante el desarrollo y las pruebas, compruebe los datos enviados en las ventanas de salida de depuración del IDE y del explorador.
Para obtener información archivada, consulte Recopilación, retención y almacenamiento de datos en Application Insights.
¿Qué es el modelo de precios de Application Insights?
Application Insights se factura a través del área de trabajo de Log Analytics en la que se ingieren los datos de registro. El plan de tarifa predeterminado de Pago por uso de Log Analytics incluye 5 GB al mes de la asignación de datos gratis por cuenta de facturación. Obtenga más información sobre las opciones de precios de los registros de Azure Monitor.
¿Existen cargos por transferencia de datos entre una aplicación web de Azure y Application Insights?
- Si la aplicación web de Azure se hospeda en un centro de datos donde hay un punto de conexión de recopilación de Application Insights, no se produce ningún cargo.
- Si no hay ningún punto de conexión de recopilación en el centro de datos host, se le cobran los cargos salientes de Azure de la telemetría de la aplicación.
Esta respuesta depende de la distribución de nuestros puntos de conexión, no de dónde se hospeda el recurso de Application Insights.
¿Incurriré en costes de red si mi recurso de Application Insights supervisa un recurso Azure (es decir, un productor de telemetría) en una región diferente?
Sí, se puede incurrir en costes de red adicionales que variarán en función de la región de la que proceda la telemetría y hacia dónde se dirija. Consulte los precios del ancho de banda de Azure para obtener más información.
Si ve cargos inesperados o costos elevados en Application Insights, esta guía puede ayudarle. Abarca causas comunes, como un gran volumen de telemetría, picos de ingesta de datos y muestreo mal configurado. Es especialmente útil si está solucionando problemas relacionados con los picos de costos, el volumen de telemetría, el muestreo no funciona, los límites de datos, la ingesta alta o la facturación inesperada. Para empezar, consulte Solución de problemas de ingesta de datos elevados en Application Insights.
¿Qué versiones de TLS se admiten?
Application Insights usa seguridad de la capa de transporte (TLS) 1.2 y 1.3.
Importante
El 1 de marzo de 2025, Azure retirará las versiones heredadas de TLS en todos los servicios. En ese momento, Application Insights ya no admite TLS 1.0, TLS 1.1 y los conjuntos de cifrado TLS 1.2/1.3 heredados y curvas elípticas enumeradas.
Para consultar cualquier pregunta general sobre el problema de TLS heredado, vea Solución de problemas de TLS y Compatibilidad con TLS en Azure Resource Manager.
¿Dónde puedo obtener más información sobre Application Insights?
Para más información, consulte Introducción a Application Insights.
API de Application Insights para eventos y métricas personalizados
¿Por qué me faltan datos de telemetría?
Ambos TelemetryChannels perderán la telemetría almacenada en búfer si no se libera antes de que una aplicación se cierre.
Para evitar la pérdida de datos, vacíe TelemetryClient cuando se cierre una aplicación.
Para más información, consulte Vaciado de datos.
¿Qué excepciones pueden Track_() llamadas producidas?
Ninguno. No es necesario agruparlas en cláusulas try-catch. Si el SDK encuentra problemas, registrará los mensajes en la salida de la consola de depuración y, si los mensajes pasan, en la Búsqueda de diagnóstico.
¿Hay una API de REST para obtener datos desde el portal?
Sí, la API de acceso a datos. Otras formas de extraer datos incluyen Power BI en recurso basado en área de trabajo.
¿Por qué se omiten mis llamadas a las API de métricas y eventos personalizados?
El SDK de Application Insights no es compatible con la instrumentación automática. Si la instrumentación automática está habilitada, se omitirán las llamadas a Track()
y otras API de métricas y eventos personalizados.
Desactive la instrumentación automática en el portal de Azure en la pestaña de Application Insights de la página de App Service o establezca ApplicationInsightsAgent_EXTENSION_VERSION
en disabled
.
¿Por qué los recuentos de los gráficos de búsqueda y métrica no son iguales?
El muestreo reduce el número de elementos de telemetría (como solicitudes y eventos personalizados) que se envían desde su aplicación al portal. En la búsqueda, ve el número de elementos recibidos. En los gráficos de métrica que muestran un recuento de eventos, ve el número de eventos originales que se han producido.
Cada elemento que se transmite lleva una propiedad itemCount
que muestra cuántos eventos originales representa ese elemento. Para ver el muestreo en funcionamiento, puede ejecutar esta consulta en Log Analytics:
requests | summarize original_events = sum(itemCount), transmitted_events = count()
¿Cómo puedo establecer una alerta sobre un evento?
Las alertas de Azure son solo sobre métricas. Cree una métrica personalizada que cruce un umbral de valor cada vez que se produzca el evento. A continuación, establezca una alerta sobre la métrica. Recibirá una notificación cada vez que la métrica cruce el umbral en cualquier dirección. No recibirá una notificación hasta el primer cruce, independientemente de si el valor inicial es alto o bajo. Siempre hay una latencia de unos minutos.
¿Dónde puedo obtener más información sobre la API de Application Insights para eventos y métricas personalizados?
Para más información, consulte API de Application Insights para eventos y métricas personalizados.
Implementación del agente de Application Insights para servidores locales
¿Application Insights Agent admite instalaciones de proxy?
Sí. Hay varias formas de descargar Application Insights Agent:
- Si el equipo tiene acceso a internet, puede incorporarlo en la Galería de PowerShell mediante los parámetros
-Proxy
. - Puede descargar manualmente el módulo e instalarlo en el equipo o usarlo directamente.
Cada una de estas opciones se describe en las instrucciones detalladas.
¿El agente de Application Insights admite aplicaciones ASP.NET Core?
Sí. En Application Insights Agent 2.0.0 y versiones posteriores, se admiten aplicaciones de ASP.NET Core hospedadas en IIS.
¿Cómo se puede comprobar que la habilitación se realizó correctamente?
Puede usar el cmdlet Get-ApplicationInsightsMonitoringStatus para comprobar que se ha habilitado correctamente.
Use Live Metrics para determinar rápidamente si la aplicación está enviando telemetría.
También puede usar Log Analytics para enumerar todos los roles en la nube que están enviando actualmente telemetría:
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
¿Cómo puedo lograr el acceso directo de proxy?
Para lograr el acceso directo del proxy, configure un proxy de nivel de máquina o un proxy de nivel de aplicación. Consulte DefaultProxy.
Ejemplo de Web.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
</defaultProxy>
</system.net>
¿Dónde puedo obtener más información sobre la implementación del agente de Application Insights para servidores locales?
Para más información, consulte Implementación del agente de Application Insights para servidores locales.
Soporte técnico de TLS
Determinar si la retirada de TLS le afecta
Application Insights y Azure Monitor no controlan la versión de TLS que se usa para las conexiones HTTPS. La versión de TLS depende del sistema operativo y del entorno de tiempo de ejecución en el que se ejecuta la aplicación.
Para confirmar la versión de TLS en uso:
- Revise la documentación del sistema operativo y del entorno de ejecución o del marco de trabajo.
- Póngase en contacto con el equipo de soporte técnico adecuado si necesita más ayuda. No abra una solicitud de soporte técnico con Application Insights.
Compatibilidad de lenguaje y tiempo de ejecución de ejemplo con TLS 1.2+
Las versiones siguientes incluyen compatibilidad integrada con TLS 1.2 o posterior:
- .NET / .NET Core: .NET Framework 4.6.2 o posterior, y todas las versiones de .NET Core
- Java: actualización 161 de Java 8 (8u161) o posterior
- Python: distribuciones de Python compiladas con OpenSSL 1.0.1 o posterior
- Node.js: Node.js versión 10 o posterior
Compatibilidad de sistema operativo de ejemplo con TLS 1.2+
Los siguientes sistemas operativos incluyen compatibilidad integrada con TLS 1.2 o superior:
- Windows: Windows 8, Windows Server 2012 y versiones posteriores
- Linux: la mayoría de las distribuciones modernas de Linux que usan OpenSSL 1.0.1 o posterior
¿Cómo puedo asegurarme de que mis recursos no se ven afectados?
Para evitar interrupciones del servicio, cada punto de conexión remoto (incluidas las solicitudes dependientes) con el que interactúa el recurso debe admitir al menos una combinación de la misma versión de protocolo, conjunto de cifrado y curva elíptica mencionada anteriormente. Si el punto de conexión remoto no admite la configuración de TLS necesaria, debe actualizarse con compatibilidad con alguna combinación de la configuración tls posterior a la desuso.
Después del 1 de mayo de 2025, ¿cuál es el comportamiento de los recursos afectados?
Los recursos de Application Insights afectados dejan de ingerir datos y no pueden acceder a los componentes de aplicación necesarios. Como resultado, algunas características dejan de funcionar.
¿Qué componentes afecta la depreciación?
La desuso de la seguridad de la capa de transporte (TLS) detallada en este documento solo debe afectar al comportamiento después del 1 de mayo de 2025. Para más información sobre las operaciones CRUD, consulte Compatibilidad con TLS de Azure Resource Manager. Este recurso proporciona más detalles sobre la compatibilidad y las escalas de tiempo de desuso de TLS.
¿Dónde puedo obtener compatibilidad con seguridad de la capa de transporte (TLS)?
Para ver cualquier pregunta general sobre el problema de TLS heredado, consulte Solución de problemas de TLS.
¿Dónde puedo obtener más información sobre la compatibilidad con TLS en Application Insights?
Para más información, consulte Compatibilidad con TLS.
ASP.NET
¿Cómo puedo desinstalar el SDK?
Para quitar Application Insights, debe eliminar los paquetes NuGet y las referencias de la API en tu aplicación. Puede desinstalar paquetes NuGet mediante el Administrador de paquetes NuGet en Visual Studio.
- Si la recopilación de seguimiento está habilitada, desinstale primero el paquete Microsoft.ApplicationInsights.TraceListener mediante el Administrador de paquetes NuGet, pero no quite ninguna dependencia.
- Desinstale el paquete Microsoft.ApplicationInsights.Web y quite sus dependencias mediante el Administrador de paquetes NuGet y sus opciones de desinstalación dentro del Control de opciones del Administrador de paquetes NuGet.
- Para quitar completamente Application Insights, compruebe y elimine manualmente el código o los archivos agregados junto con cualquier llamada API que haya agregado en el proyecto. Para más información, consulte ¿Qué se crea automáticamente al agregar el SDK de Application Insights?.
¿Qué se crea automáticamente al agregar el SDK de Application Insights?
Cuando agrega Application Insights al proyecto, crea archivos y agrega código a algunos de sus archivos. Simplemente desinstalar los paquetes NuGet no siempre elimina los archivos y el código. Para quitar completamente Application Insights, debe comprobar y eliminar manualmente el código o los archivos agregados junto con cualquier llamada API que haya agregado en el proyecto.
Al agregar Telemetría de Application Insights a un proyecto ASP.NET de Visual Studio, se agregan los siguientes archivos:
- ApplicationInsights.config.
- AiHandleErrorAttribute.cs
Se agregan automáticamente los siguientes fragmentos de código:
[Nombre del proyecto].csproj
<ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
Packages.config
<packages> ... <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" /> <package id="System.Buffers" version="4.4.0" targetFramework="net472" /> <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" /> <package id="System.Memory" version="4.5.3" targetFramework="net472" /> <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" /> <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" /> ... </packages>
Layout.cshtml
Si el proyecto tiene un archivo Layout.cshtml, se agrega el código siguiente.
<head> ... <script type = 'text/javascript' > var appInsights=window.appInsights||function(config) { function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} } var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t }({ instrumentationKey:'00000000-0000-0000-0000-000000000000' }); window.appInsights=appInsights; appInsights.trackPageView(); </script> ... </head>
ConnectedService.json
{ "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider", "Version": "16.0.0.0", "GettingStartedDocument": { "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413" } }
FilterConfig.cs
public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added }
¿Cómo puedo deshabilitar la correlación de telemetría?
Para deshabilitar la correlación de telemetría en la configuración, consulte <ExcludeComponentCorrelationHttpHeadersOnDomains>
en Application Insights para aplicaciones de consola.
¿Dónde puedo obtener más información sobre el uso de Application Insights con ASP.NET?
Para obtener más información, consulte Configuración de Application Insights para el sitio web de ASP.NET.
Aplicaciones de ASP.NET Core
¿Application Insights admite ASP.NET Core 3.1?
ASP.NET Core 3.1 ya no es compatible con Microsoft.
El SDK de Application Insights para ASP.NET Core versión 2.8.0 y Visual Studio 2019 o posterior se pueden usar con aplicaciones de ASP.NET Core 3.1.
¿Cómo puedo realizar un seguimiento de la telemetría que no se recopila automáticamente?
Obtenga una instancia de TelemetryClient
mediante inyección del constructor y llame al método TrackXXX()
necesario en ella. No se recomienda crear nuevas instancias TelemetryClient
o TelemetryConfiguration
en una aplicación de ASP.NET Core. Una instancia singleton de TelemetryClient
ya está registrada en el contenedor DependencyInjection
, que comparte TelemetryConfiguration
con el resto de los datos de telemetría. Cree una nueva instancia de TelemetryClient
solo si requiere una configuración que sea independiente del resto de la telemetría.
En el ejemplo siguiente se muestra cómo realizar el seguimiento de más datos de telemetría desde un controlador.
using Microsoft.ApplicationInsights;
public class HomeController : Controller
{
private TelemetryClient telemetry;
// Use constructor injection to get a TelemetryClient instance.
public HomeController(TelemetryClient telemetry)
{
this.telemetry = telemetry;
}
public IActionResult Index()
{
// Call the required TrackXXX method.
this.telemetry.TrackEvent("HomePageRequested");
return View();
}
}
Para obtener más información acerca de la creación de informes de datos personalizados en Application Insights, consulte la referencia de la API de métricas personalizadas de Application Insights. Se puede usar un enfoque similar para el envío de métricas personalizadas a Application Insights mediante GetMetric API.
¿Cómo puedo capturar el cuerpo de la solicitud y la respuesta en mi telemetría?
ASP.NET Core tiene compatibilidad integrada para registrar información de solicitud y respuesta HTTP (incluido el cuerpo) mediante ILogger
. Se recomienda aprovechar esto. Esto puede exponer información de identificación personal (PII) en telemetría y puede hacer que los costos (costos de rendimiento y facturación de Application Insights) aumenten significativamente, de modo que conviene evaluar detenidamente los riesgos antes de usarlo.
¿Cómo puedo personalizar la colección de registros de ILogger?
La configuración predeterminada de Application Insights es capturar solo advertencia y registros más graves.
Capture información y registros menos graves cambiando la configuración de registro para el proveedor de Application Insights como se indica a continuación.
{
"Logging": {
"LogLevel": {
"Default": "Information"
},
"ApplicationInsights": {
"LogLevel": {
"Default": "Information"
}
}
},
"ApplicationInsights": {
"ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
}
}
Es importante tener en cuenta que el ejemplo siguiente no hará que el proveedor de Application Insights capture los registros Information
. No lo captura porque el SDK agrega un filtro de registro predeterminado que indica a ApplicationInsights
que capture solo los registros Warning
y los registros más graves. Application Insights requiere una invalidación explícita.
{
"Logging": {
"LogLevel": {
"Default": "Information"
}
}
}
Para más información, consulte Configuración de ILogger.
Algunas plantillas de Visual Studio usan el método de extensión UseApplicationInsights() en IWebHostBuilder para habilitar Application Insights. ¿Es este uso aún válido?
El método de extensión UseApplicationInsights()
todavía es compatible, pero está marcado como obsoleto desde la versión 2.8.0 y posteriores del SDK de Application Insights. Se elimina en la próxima versión principal del SDK. Para habilitar la telemetría de Application Insights, use AddApplicationInsightsTelemetry()
, ya que proporciona sobrecargas para controlar cierta configuración. Además, en las aplicaciones ASP.NET Core 3.X, services.AddApplicationInsightsTelemetry()
es la única manera de habilitar Application Insights.
Estoy implementando mi aplicación de ASP.NET Core en Web Apps. ¿Debo habilitar la extensión de Application Insights desde Web Apps?
Si está instalado el SDK en tiempo de compilación, como se muestra en este artículo, no es necesario habilitar la extensión de Application Insights desde el portal de App Service. Si la extensión está instalada, se retirará cuando detecte que el SDK ya está agregado. Si habilita Application Insights desde la extensión, no tiene que instalar ni actualizar el SDK. Pero si habilita Application Insights siguiendo las instrucciones de este artículo, tendrá más flexibilidad porque:
- La telemetría de Application Insights seguirá funcionando en:
- Todos los sistemas operativos, incluidos Windows, Linux y Mac.
- Todos los modos de publicación, incluidos los independientes o dependientes del marco.
- Todas las plataformas de destino, incluida la versión completa de .NET Framework.
- Todas las opciones de hospedaje, incluidos contenedores, Web Apps, máquinas virtuales, Linux, AKS y hospedaje independiente de Azure.
- Todas las versiones de .NET Core, incluidas las versiones preliminares.
- Puede ver datos de telemetría localmente cuando depure desde Visual Studio.
- Puede realizar un seguimiento de telemetría personalizada adicional mediante la API
TrackXXX()
. - Tiene control total sobre la configuración.
¿Puedo habilitar la supervisión de Application Insights mediante herramientas como el agente de Application Insights para Azure Monitor (anteriormente, Monitor de estado v2)?
Sí. En Application Insights Agent 2.0.0-beta1 y versiones posteriores, se admiten aplicaciones de ASP.NET Core hospedadas en IIS.
¿Se admiten todas las características si ejecuto mi aplicación en Linux?
Sí. La compatibilidad de características para el SDK es la misma en todas las plataformas, con las siguientes excepciones:
- El SDK recopila contadores de eventos en Linux, ya que los contadores de rendimiento solo se admiten en Windows. La mayoría de las métricas son las mismas.
¿Se admite este SDK para los servicios de trabajo?
No. En su lugar, use Application Insights para aplicaciones de servicio de trabajo (aplicaciones no HTTP) para servicios de trabajo.
¿Cómo puedo desinstalar el SDK?
Para quitar Application Insights, debe eliminar los paquetes NuGet y las referencias de la API en tu aplicación. Puede desinstalar paquetes NuGet mediante el Administrador de paquetes NuGet en Visual Studio.
Nota:
Estas instrucciones sirven para desinstalar el SDK de ASP.NET Core. Si necesita desinstalar el SDK de ASP.NET, consulte ¿Cómo puedo desinstalar el SDK de ASP.NET?.
- Desinstale el paquete Microsoft.ApplicationInsights.AspNetCore utilizando el Administrador de paquetes NuGet.
- Para quitar completamente Application Insights, compruebe y elimine manualmente el código o los archivos agregados junto con cualquier llamada API que haya agregado en el proyecto. Para obtener más información, consulte ¿Qué se crea al agregar el SDK de Application Insights?.
¿Qué se crea al agregar el SDK de Application Insights?
Cuando agrega Application Insights al proyecto, crea archivos y agrega código a algunos de sus archivos. Solo desinstalar los paquetes NuGet no siempre eliminará los archivos y el código. Para quitar completamente Application Insights, debe comprobar y eliminar manualmente el código o los archivos agregados junto con cualquier llamada API que haya agregado en el proyecto.
Al agregar Telemetría de Application Insights a un proyecto de plantilla de ASP.NET Core de Visual Studio, se agrega el siguiente código:
[Nombre del proyecto].csproj
<PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" /> </ItemGroup> <ItemGroup> <WCFMetadata Include="Connected Services" /> </ItemGroup>
Appsettings.json
"ApplicationInsights": { "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000" }
ConnectedService.json
{ "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider", "Version": "16.0.0.0", "GettingStartedDocument": { "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432" } }
Startup.cs
public void ConfigureServices(IServiceCollection services) { services.AddRazorPages(); services.AddApplicationInsightsTelemetry(); // This is added }
¿Cómo puedo deshabilitar la correlación de telemetría?
Para deshabilitar la correlación de telemetría en el código, consulte <ExcludeComponentCorrelationHttpHeadersOnDomains>
en Application Insights para aplicaciones de consola.
¿Dónde puedo obtener más información sobre el uso de Application Insights para aplicaciones ASP.NET Core?
Para más información, consulte Application Insights para ASP.NET Core.
contadores de rendimiento de ASP.NET
¿En qué se diferencian la tasa de excepciones y las métricas de excepciones?
-
Exception rate
: la tasa de excepciones es un contador de rendimiento del sistema. El CLR cuenta todas las excepciones controladas y no controladas que se producen, y divide el total de un intervalo de muestreo entre la duración del intervalo. El SDK de Application Insights recopila este resultado y lo envía al portal. -
Exceptions
: la métrica de Excepciones cuenta los informes deTrackException
recibidos a través del portal en el intervalo de muestreo del gráfico. Incluye solo las excepciones controladas en las que escribe llamadasTrackException
en el código. No incluye todas las excepciones no controladas.
¿Dónde puedo obtener más información sobre ASP.NET contadores de rendimiento?
Para obtener más información, consulte Contadores de .NET en Application Insights.
contadores de eventos ASP.NET
¿Puedo ver los contadores de eventos en Live Metrics?
Live Metrics no muestra EventCounters. Para ver la telemetría, use el explorador de métricas o el análisis.
Después de habilitar Application Insights desde el portal de Azure Web App, ¿por qué no puedo ver los contadores de eventos?
La extensión de Application Insights para ASP.NET Core aún no admite esta característica.
¿Dónde puedo obtener más información sobre ASP.NET contadores de eventos?
Para obtener más información, consulte Contadores de .NET en Application Insights.
Máquinas virtuales de Azure y conjuntos de escalado de máquinas virtuales
¿Cómo puedo deshabilitar la supervisión del lado cliente para aplicaciones de ASP.NET Core?
La supervisión del lado cliente está habilitada de manera predeterminada para las aplicaciones de ASP.NET Core. Si desea deshabilitarla, defina una variable de entorno en el servidor con la siguiente información:
-
Nombre:
APPINSIGHTS_JAVASCRIPT_ENABLED
-
Valor:
false
¿Dónde puedo obtener más información sobre el uso de Application Insights para máquinas virtuales de Azure y conjuntos de escalado de máquinas virtuales?
Para más información, consulte Application Insights para máquinas virtuales de Azure y conjuntos de escalado de máquinas virtuales.
Seguimiento de dependencias
¿Qué método usa el recopilador automático de dependencias para informar las llamadas fallidas a las dependencias?
Las llamadas de dependencia con errores tienen el campo success
establecido en False. El módulo DependencyTrackingTelemetryModule
no notifica ExceptionTelemetry
. El modelo de datos completo para la dependencia se describe en Modelo de datos de telemetría de Application Insights.
¿Cómo calculo la latencia de ingesta para mi telemetría de dependencia?
Use este código:
dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp
| extend TimeIngested = ingestion_time()
Cómo determino la hora en la que se inició la llamada de dependencia?
En la vista de consulta de Log Analytics, timestamp
representa el momento en que se inició la llamada a TrackDependency(), que se produjo inmediatamente después de recibir la respuesta de la llamada de dependencia. Para calcular la hora de inicio de la llamada de dependencia, debería tomar timestamp
y restar el duration
registrado de la llamada de dependencia.
¿Incluye el seguimiento de dependencias en Application Insights los cuerpos de respuesta de registro?
El seguimiento de dependencias en Application Insights no incluye cuerpos de respuesta de registro, ya que generaría demasiada telemetría para la mayoría de las aplicaciones.
¿Dónde puedo obtener más información sobre el seguimiento de dependencias en Application Insights?
Para obtener más información, consulte Seguimiento de dependencias.
Pruebas de disponibilidad
¿Puedo ejecutar pruebas de disponibilidad en un servidor de intranet?
Las pruebas de disponibilidad se ejecutan en puntos de presencia que se distribuyen en todo el mundo. Hay dos soluciones:
- Puerta de firewall: permitir solicitudes al servidor desde la lista larga y modificable de agentes de prueba web.
-
Código personalizado: escribir su propio código para enviar solicitudes periódicas a su servidor desde dentro de la intranet. Con este fin, puede ejecutar pruebas web de Visual Studio. El evaluador puede enviar los resultados a Application Insights mediante la API
TrackAvailability()
.
¿Cuál es la cadena del agente de usuario para las pruebas de disponibilidad?
La cadena del agente de usuario es Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)
¿Dónde puedo obtener más información sobre las pruebas de disponibilidad de Application Insights?
Para obtener más información, consulte Pruebas de disponibilidad.
Compatibilidad de TLS con pruebas de disponibilidad
¿Cómo afecta la desuso al comportamiento de la prueba web?
Las pruebas de disponibilidad actúan como un cliente distribuido en cada una de las ubicaciones de prueba web admitidas. Cada vez que se ejecuta una prueba web, el servicio de prueba de disponibilidad intenta ponerse en contacto con el punto de conexión remoto definido en la configuración de prueba web. Se envía un mensaje de Hello de TLS Client que contiene toda la configuración de TLS admitida actualmente. Si el punto de conexión remoto comparte una configuración TLS común con el cliente de prueba de disponibilidad, el protocolo de enlace TLS se realiza correctamente. De lo contrario, se produce un error en la prueba web con un error de protocolo de enlace TLS.
¿Cómo se valida la configuración de TLS que admite un punto de conexión remoto?
Hay varias herramientas disponibles para probar qué configuración de TLS admite un punto de conexión. Una manera sería seguir el ejemplo detallado en esta página. Si el punto de conexión remoto no está disponible a través de la red pública de Internet, debe asegurarse de validar la configuración de TLS admitida en el punto de conexión remoto desde una máquina que tenga acceso para llamar al punto de conexión.
Nota:
Para conocer los pasos necesarios para habilitar la configuración de TLS necesaria en el servidor web, es mejor ponerse en contacto con el equipo que posee la plataforma de hospedaje en la que se ejecuta el servidor web si no se conoce el proceso.
Después del 1 de mayo de 2025, ¿cuál será el comportamiento de la prueba web para las pruebas afectadas?
No hay ningún tipo de excepción en el que todos los errores de protocolo de enlace TLS afectados por este desuso se presentarían a sí mismos. Sin embargo, la excepción más común con la que la prueba web empezaría a producir errores sería The request was aborted: Couldn't create SSL/TLS secure channel
. También debería poder ver los errores relacionados con TLS en el Paso de solución de problemas Transporte de TLS para el resultado de la prueba web que podría verse afectado.
¿Puedo ver qué configuración de TLS está usando actualmente mi prueba web?
La configuración de TLS negociada durante una ejecución de prueba web no se puede ver. Siempre que el punto de conexión remoto admita la configuración de TLS común con pruebas de disponibilidad, no se debería ver ningún impacto después del desuso.
¿Qué componentes afecta el desuso en el servicio de prueba de disponibilidad?
El desuso de TLS detallado en este documento solo debe afectar al comportamiento de ejecución de las pruebas de disponibilidad en la web después del 1 de mayo de 2025. Para más información sobre cómo interactuar con el servicio de prueba de disponibilidad para las operaciones CRUD, consulte Compatibilidad con TLS de Azure Resource Manager. Este recurso proporciona más detalles sobre la compatibilidad y las escalas de tiempo de desuso de TLS.
¿Dónde puedo obtener compatibilidad con TLS?
Para ver cualquier pregunta general sobre el problema de TLS heredado, consulte Solución de problemas de TLS.
¿Dónde puedo obtener más información sobre la compatibilidad de TLS con las pruebas de disponibilidad?
Para más información, consulte Configuraciones de TLS admitidas.
Supervisión en Azure App Service para aplicaciones .NET, Node.js, Python y Java
¿Qué modifica Application Insights en mi proyecto?
Los detalles dependen del tipo de proyecto. La siguiente lista es un ejemplo de una aplicación web.
Agrega archivos al proyecto:
- ApplicationInsights.config
- ai.js
Instala paquetes NuGet:
- API de Application Insights: la API principal
- API de Application Insights para aplicaciones web: se utiliza para enviar telemetría desde el servidor
- API de Application Insights para aplicaciones JavaScript: se usa para enviar la telemetría del cliente
Incluye ensamblados en paquetes:
- Microsoft.ApplicationInsights
- Microsoft.ApplicationInsights.Platform
Inserta elementos en:
- Web.config
- packages.config
Inserte fragmentos de código en el código de cliente y servidor para inicializarlos con el identificador de recursos de Application Insights. Por ejemplo, en una aplicación MVC, el código se inserta en la página principal Views/Shared/_Layout.cshtml. Solo en el contexto de nuevos proyectos, puede agregar manualmente Application Insights a un proyecto existente.
¿Cuál es la diferencia entre las métricas estándar de Application Insights y las métricas de Azure App Service?
Application Insights recopila datos de telemetría de las solicitudes que se enviaron a la aplicación. Si el error se produjo en Web Apps o en el servidor web, y la solicitud no llegó a la aplicación de usuario, Application Insights no tendrá ningún dato de telemetría sobre él.
La duración de serverresponsetime
calculada por Application Insights no coincidirá necesariamente con el tiempo de respuesta del servidor observado por Web Apps. Esto se debe a que Application Insights solo cuenta la duración cuando la solicitud llega realmente a la aplicación de usuario. Si la solicitud se bloquea o se pone en cola en el servidor web, ese tiempo de espera se incluirá en las métricas de Web Apps, pero no en las métricas de Application Insights.
¿Dónde puedo obtener más información sobre la supervisión en Azure App Service para aplicaciones .NET, Node.js, Python y Java?
Para más información, consulte Habilitación de la supervisión de aplicaciones en Azure App Service.
Instrumentación automática
¿Debería escribirse con guion en el término "autoinstrumentación"?
Seguimos la Guía de estilo de Microsoft para la documentación de productos publicada en la plataforma Microsoft Learn.
En general, no se incluye un guión después del prefijo "auto".
¿Dónde puedo obtener más información sobre la autoinstrumentación?
Para más información, consulte ¿Qué es la implementación automática para Application Insights de Azure Monitor?.
Inserción automática para Azure Kubernetes Service
¿Admite Azure Kubernetes Service (AKS) la implementación automática de métricas personalizadas?
Si quiere métricas personalizadas en Node.js, instrumente manualmente las aplicaciones con la distribución OpenTelemetry de Azure Monitor.
Java permite métricas personalizadas con autoinstrumentación. Puede recopilar métricas personalizadas actualizando el código y habilitando esta característica. Si el código ya tiene métricas personalizadas, se transfieren cuando se habilita la autoinstrumentación.
¿Funciona la autoinstrumentación de AKS con aplicaciones instrumentadas mediante un SDK de OpenTelemetry de software de código abierto (OSS)?
La instrumentación automática de AKS puede interrumpir la telemetría enviada a terceros por un SDK de OpenTelemetry de OSS.
¿La autoinstrumentación de AKS puede coexistir con la instrumentación manual?
La instrumentación automática de AKS está diseñada para coexistir con ambas opciones de instrumentación manual: el SDK de API clásica de Application Insights y la distribución de OpenTelemetry.
Siempre evita los datos duplicados y garantiza que las métricas personalizadas funcionen.
Consulte este gráfico para determinar cuándo tiene prioridad la implementación automática o la instrumentación manual.
Lenguaje | Precedencia |
---|---|
Node.js. | Instrumentación manual |
Java | Instrumentación automática |
¿Cómo puedo asegurarme de que uso las versiones más recientes y seguras de la distribución de OpenTelemetry de Azure Monitor?
Las vulnerabilidades detectadas en la distribución OpenTelemetry de Azure Monitor se priorizan, se corrigen y se publican en la siguiente versión.
La instrumentación automática AKS inserta la versión más reciente de la distribución OpenTelemetry de Azure Monitor en los pods de la aplicación cada vez que se cambia o se reinicia la implementación.
La distribución de OpenTelemetry puede ser vulnerable a las implementaciones que no se cambian ni reinician durante largos períodos de tiempo. Por este motivo, se recomienda actualizar o reiniciar implementaciones semanalmente para asegurarse de que se usa una versión reciente de la distribución.
¿Cómo puedo obtener más información sobre la distribución openTelemetry de Azure Monitor?
Esta característica logra la instrumentación automática mediante la inserción de la distribución de OpenTelemetry de Azure Monitor en pods de aplicación.
Para Java, esta característica integra la distribución de OpenTelemetry de Azure Monitor independiente para Java. Consulte nuestra documentación de distribución de Java para obtener más información sobre el binario de instrumentación de Java.
Para Node.js, insertamos un binario de instrumentación automática basado en nuestra distribución OpenTelemetry de Azure Monitor para Node.js. Para obtener más información, consulte Node.js documentación de distribución. Tenga en cuenta que no tenemos una autoinstrución independiente para Node.js por lo que nuestra documentación de distribución está orientada a la instrumentación manual. Puede omitir los pasos de configuración basados en código relacionados con la instrumentación manual. Sin embargo, todo lo demás de nuestra documentación de distribución, como la configuración predeterminada, las configuraciones de variables de entorno, etc. son aplicables a esta característica.
¿Dónde puedo obtener más información sobre la instalación automática para AKS?
Para obtener más información, consulte Autoinstrumentación para AKS.
Cadenas de conexión
¿Es necesario usar cadenas de conexión en las nuevas regiones de Azure?
Las nuevas regiones de Azure requieren el uso de cadenas de conexión en lugar de claves de instrumentación. Una cadena de conexión identifica el recurso al que quiere asociar los datos de telemetría. También permite modificar los puntos de conexión que usa el recurso como destino de la telemetría. Copie la cadena de conexión y agregarla al código de la aplicación o a una variable de entorno.
¿Debo usar cadenas de conexión o claves de instrumentación?
Se recomienda usar cadenas de conexión en lugar de claves de instrumentación.
¿Cuándo es necesario establecer la variable de entorno?
Establezca manualmente APPLICATIONINSIGHTS_CONNECTION_STRING
en todos los escenarios en los que el sistema no lo proporcione automáticamente. Estos escenarios incluyen, pero no se limitan a: desarrollo local y funciones aisladas de .NET mediante la integración de ASP.NET Core. En estos casos, la variable de entorno garantiza que la canalización de OpenTelemetry pueda enviar telemetría a Application Insights. Para obtener más información sobre cómo configurar cadenas de conexión con una variable de entorno, consulte Configuración de OpenTelemetry en Application Insights.
¿Cómo instrumento una aplicación web global para cumplir los requisitos de cumplimiento de datos regionales?
Para cumplir los requisitos de cumplimiento de datos regionales, use puntos de conexión regionales de Application Insights en lugar del punto de conexión global. El punto de conexión global no garantiza que los datos permanezcan dentro de una región específica. Los puntos de conexión regionales ayudan a garantizar que la telemetría de los usuarios de áreas reguladas solo se envíe a los centros de datos de esas regiones.
Para configurar la aplicación web global para el cumplimiento regional:
- Cree un recurso de Application Insights por región con requisitos de cumplimiento estrictos, como la Unión Europea o los Estados Unidos.
- Cree otro recurso de Application Insights para los usuarios de todas las demás regiones.
- Configure la aplicación para enviar telemetría al recurso de Application Insights adecuado en función de la región de cada usuario. Determine la región mediante señales como la dirección IP, los metadatos de la cuenta o la configuración de ubicación.
- Conecte todos los recursos de Application Insights a un área de trabajo de Log Analytics si necesita una experiencia de consulta unificada entre regiones.
Por ejemplo:
- Envíe datos de los usuarios de la región A al recurso de Application Insights de la región A mediante la cadena de conexión de la región A.
- Envíe datos de los usuarios de la región B al recurso de Application Insights de la región B mediante la cadena de conexión de la región B.
- Envíe todos los demás datos de usuario a un recurso de Application Insights de uso general mediante una cadena de conexión diferente.
Importante
El uso del punto de conexión global no garantiza el cumplimiento regional. Para cumplir los requisitos de residencia de datos, use siempre puntos de conexión específicos de la región y enrute la telemetría en función de la región del usuario.
En el diagrama siguiente se muestra un ejemplo de configuración para una aplicación web global:
¿Dónde puedo obtener más información sobre las cadenas de conexión en Application Insights?
Para obtener más información, consulte Cadenas de conexión.
Creación y configuración de recursos de Application Insights
¿Cómo se mueven los recursos de Application Insights a una nueva región?
No se admite la transferencia de recursos existentes de Application Insights entre regiones y no se pueden migrar datos históricos a una nueva región. La solución alternativa implica:
- Creación de un nuevo recurso de Application Insights en la región deseada.
- Volver a crear las personalizaciones únicas del recurso original en el nuevo.
- Actualizar la aplicación con la cadena de conexión del recurso de la nueva región.
- Probar para asegurarse de que todo funcione según lo previsto con el nuevo recurso de Application Insights.
- Decida conservar o eliminar el recurso original de Application Insights. La eliminación de un recurso clásico significa perder todos los datos históricos. Si el recurso estuviera basado en el área de trabajo, los datos permanecerán en Log Analytics, permitiendo el acceso a datos históricos hasta que expire el período de retención.
Las personalizaciones únicas que normalmente deben volver a crearse o actualizarse manualmente para el recurso en la nueva región incluyen, entre otras, las siguientes:
- Vuelva a crear paneles y libros de trabajo personalizados.
- Vuelva a crear o actualizar el ámbito de cualquier alerta de registro/métrica personalizada.
- Vuelva a crear una alerta de disponibilidad.
- Vuelva a crear las opciones de configuración de control de acceso basado en rol de Azure personalizadas necesarias para que los usuarios puedan acceder al nuevo recurso.
- Replique la configuración que implique el muestreo de ingesta, la retención de datos, el límite diario y la habilitación de métricas personalizadas. Estas opciones de configuración se controlan mediante el panel Uso y costos estimados.
- Cualquier integración que se base en claves de API, como anotaciones de versión y canal de control seguro de métricas en tiempo real. Debe generar nuevas claves de API y actualizar la integración asociada.
- La exportación continua en los recursos clásicos ha de configurarse de nuevo.
- La configuración de diagnóstico en los recursos basados en el área de trabajo ha de volver a definirse.
¿Puedo usar providers('Microsoft.Insights', 'components').apiVersions[0] en mis implementaciones de Azure Resource Manager?
No recomendamos usar este método para rellenar la versión de la API. La versión más reciente puede representar versiones preliminares, que podrían contener cambios importantes. Incluso con versiones más recientes que no son de versión preliminar, las versiones de API no siempre son compatibles con versiones anteriores con las plantillas existentes. En algunos casos, es posible que la versión de la API no esté disponible para todas las suscripciones.
¿Dónde puedo obtener más información sobre cómo crear y configurar recursos de Application Insights?
Para más información, consulte Creación y configuración de recursos de Application Insights.
Modelo de datos de telemetría
¿Cómo puedo notificar problemas y sugerencias de esquema o modelo de datos?
Para informar de problemas del esquema o del modelo de datos y proporcionar sugerencias, use el repositorio de GitHub.
¿Cómo medirías el impacto de una campaña de supervisión?
La telemetría PageView incluye la dirección URL y puedes analizar el parámetro UTM mediante una función regex en Kusto.
Ocasionalmente, estos datos podrían faltar o ser inexactos si el usuario o la empresa deshabilita el envío de un agente de usuario en la configuración del explorador. Es posible que las expresiones regulares del analizador de UA no incluyan toda la información del dispositivo. O bien, es posible que Application Insights no haya adoptado las actualizaciones más recientes.
¿Por qué una medición personalizada se realiza correctamente pero no aparece el registro?
Esto puede ocurrir si usa valores de cadena. Solo los valores numéricos funcionan con medidas personalizadas.
¿Dónde puedo obtener más información sobre el modelo de datos de telemetría?
Para más información, consulte Modelo de datos de telemetría de Application Insights.
Registro con .NET
¿Qué tipo de datos de telemetría de Application Insights se generan a partir de los registros de ILogger? ¿Dónde puedo ver los registros de ILogger en Application Insights?
ApplicationInsightsLoggerProvider
captura registros de ILogger
y crea TraceTelemetry
a partir de estos. Si se pasa un objeto Exception
al método Log
en ILogger
, se crea ExceptionTelemetry
en lugar de TraceTelemetry
.
Visualización de la telemetría de ILogger
En el Portal de Azure:
- Vaya a Azure Portal y acceda al recurso de Application Insights.
- Seleccione la sección Registros dentro de Application Insights.
- Use el lenguaje de consulta Kusto (KQL) para consultar los mensajes ILogger almacenados en la tabla
traces
. Ejemplo de consulta:traces | where message contains "YourSearchTerm"
. - Refine las consultas para filtrar los datos de ILogger por gravedad, intervalo de tiempo o contenido de mensaje específico.
En Visual Studio (depurador local):
- Ejecute la aplicación en modo de depuración en Visual Studio.
- Abra la ventana Herramientas de diagnóstico mientras se ejecuta la aplicación.
- En la pestaña Eventos, los registros de ILogger aparecen junto con otros datos de telemetría.
- Para buscar mensajes ILogger específicos, use las características de búsqueda y filtro en la ventana Herramientas de diagnóstico.
Si prefiere enviar TraceTelemetry
siempre, use este fragmento de código:
builder.AddApplicationInsights(
options => options.TrackExceptionsAsExceptionTelemetry = false);
¿Por qué algunos registros de ILogger no tiene las mismas propiedades que otros?
Application Insights captura y envía los registros de ILogger
usando la misma información de TelemetryConfiguration
que se usa para los demás datos de telemetría. Sin embargo, hay una excepción. De manera predeterminada, TelemetryConfiguration
no se ha configurado por completo al registrarse desde Program.cs o Startup.cs. Los registros de estos lugares no tienen la configuración predeterminada, por lo que no se ejecutan todas las instancias de TelemetryInitializer
y TelemetryProcessor
.
Estoy usando el paquete independiente Microsoft.Extensions.Logging.ApplicationInsights y quiero registrar manualmente más datos de telemetría personalizados. ¿Cómo debo hacerlo?
Cuando se usa el paquete independiente, TelemetryClient
no se inserta en el contenedor de inserción de dependencias (DI). Debe crear una instancia de TelemetryClient
y usar la misma configuración que el proveedor del registrador, tal y como se muestra en el siguiente código. Este requisito garantiza que se use la misma configuración para todos los datos de telemetría personalizados y los datos de telemetría de ILogger
.
public class MyController : ApiController
{
// This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
private readonly TelemetryClient _telemetryClient;
private readonly ILogger _logger;
public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
{
_telemetryClient = new TelemetryClient(options.Value);
_logger = logger;
}
}
Nota:
Si utiliza el paquete Microsoft.ApplicationInsights.AspNetCore
para habilitar Application Insights, modifique este código para obtener TelemetryClient
directamente en el constructor.
No tengo instalado el SDK y uso la extensión Web Apps de Azure para habilitar Application Insights para mis aplicaciones de ASP.NET Core. ¿Cómo uso el nuevo proveedor?
La extensión de Application Insights en Azure Web Apps usa el nuevo proveedor. Puede modificar las reglas de filtrado en el archivo appsettings.json para la aplicación.
¿Dónde puedo obtener más información sobre el registro con .NET?
Para más información, consulte Registro de Application Insights con .NET.
Generador de perfiles de Java
¿Qué es la generación de perfiles de Java de Application Insights de Azure Monitor?
Java Profiler utiliza Java Flight Recorder (JFR) para generar perfiles su aplicación utilizando una configuración personalizada.
¿Qué es Java Flight Recorder?
Java Flight Recorder (JFR) es una herramienta para recopilar datos de generación de perfiles de una aplicación Java en ejecución. JFR se integra en el entorno de Máquina virtual Java (JVM) y se usa para solucionar problemas de rendimiento. Obtenga más información sobre Java SE JFR Runtime.
¿Cuáles son las implicaciones en términos de cuotas de licencia o precios de habilitar la generación de perfiles de Java de Application Insights?
La generación de perfiles de Java es una característica gratuita que se incluye con Application Insights. Los precios de Application Insights de Azure Monitor se basan en el costo de ingesta.
¿Qué información de generación de perfiles de Java se recopila?
Entre los datos de generación de perfiles que recopila JFR se incluyen los siguientes: datos de generación de perfiles de métodos y ejecuciones, datos de recolección de elementos no utilizados y perfiles de bloqueo.
¿Cómo puedo usar la generación de perfiles de Java de Application Insights y visualizar los datos?
Los registros de JFR se puede ver y analizar con su herramienta preferida, como por ejemplo Java Mission Control (JMC).
¿Se proporcionan recomendaciones de corrección y diagnóstico de rendimiento con la generación de perfiles de Java de Application Insights?
"Recomendaciones y diagnósticos de rendimiento" es una nueva característica que está disponible como diagnósticos de Java de Application Insights. Puede registrarse para obtener la versión preliminar de esta característica. Los registros de JFR se puede ver con Java Mission Control (JMC).
¿Cuál es la diferencia entre la generación de perfiles de Java a petición y automática en Application Insights?
La generación de perfiles a petición la desencadena el usuario en tiempo real, mientras que la generación de perfiles automática se lleva a cabo con desencadenadores preconfigurados.
Use Generar perfiles ahora para la opción de generación de perfiles a petición. Generar perfiles ahora genera perfiles inmediatamente de todos los agentes adjuntos a la instancia de Application Insights.
La creación automática de perfiles se desencadena al alcanzar un umbral de recursos.
¿Qué desencadenadores de generación de perfiles de Java puedo configurar?
Actualmente, el agente de Java de Application Insights admite la supervisión del consumo de CPU y memoria. El umbral de CPU se configura como un porcentaje de todos los núcleos disponibles en la máquina. La memoria es la ocupación de la región de memoria de antigüedad (OldGen) actual con respecto al tamaño máximo posible de la región.
¿Cuáles son los requisitos previos necesarios para habilitar la generación de perfiles de Java?
Revise los requisitos previos.
¿Puedo usar la generación de perfiles de Java para una aplicación de microservicios?
Sí, puede generar perfiles de un entorno JVM que ejecute microservicios mediante JFR.
¿Dónde puedo obtener más información sobre Java Profiler?
Para más información, consulte Azure Monitor Application Insights Profiler para Java.
Invalidaciones de muestreo: Application Insights para Java
¿Es necesario usar la instrumentación manual para habilitar invalidaciones de muestreo?
No, las invalidaciones de muestreo ahora están disponibles con carácter general (GA) y se pueden usar con la instrumentación automática y la instrumentación manual.
¿Cómo se configuran las invalidaciones de muestreo al usar Azure App Service con la implementación automática?
Si usa la autoinstrumentación, actualice el archivo applicationinsights.json
en el portal de Azure.
¿Es necesario cargar manualmente el archivo del agente de Application Insights para invalidaciones de muestreo?
Para la instrumentación automática, no se requiere la carga manual de un agente. Sin embargo, para la instrumentación manual, todavía debe incluir el archivo JAR del agente de Application Insights y los archivos de configuración en el paquete de implementación.
¿Cuál es la diferencia entre "desarrollo local" y "servidor de aplicaciones" en el contexto de la instrumentación manual?
El desarrollo local hace referencia al entorno en el que se está compilando o probando la aplicación, como una máquina del desarrollador o una instancia de Azure Cloud Shell. El servidor de aplicaciones hace referencia al servidor web que ejecuta la aplicación, como Tomcat 11 en un entorno de Azure App Service. Al usar la instrumentación manual, debe asegurarse de que el archivo JAR del agente se coloca correctamente en el servidor de aplicaciones.
Si uso una instancia de Azure App Service con un entorno de ejecución de Java (por ejemplo, Tomcat 11), ¿cómo se configuran las invalidaciones de muestreo?
Para la implementación automática, puede configurar invalidaciones de muestreo a través de Azure Portal. Si usa la instrumentación manual, debe colocar el ARCHIVO JAR del agente de Application Insights en el directorio adecuado e incluir el archivo applicationinsights.json con la configuración de muestreo deseada.
¿Dónde puedo obtener más información sobre las invalidaciones de muestreo?
Para más información, consulte Reemplazos de muestreo: Azure Monitor Application Insights para Java.
Procesadores de telemetría
¿Por qué el procesador de registros no procesa los archivos de registro mediante TelemetryClient.trackTrace()?
TelemetryClient.trackTrace() forma parte del puente del SDK clásico de Application Insights y los procesadores de registro solo funcionan con la nueva instrumentación basada en OpenTelemetry.
¿Dónde puedo obtener más información sobre los procesadores de telemetría?
Para más información, consulte Procesadores de telemetría (versión preliminar): Azure Monitor Application Insights para Java.
SDK de JavaScript
¿Qué son los recuentos de usuarios y sesiones?
- El SDK de JavaScript establece una cookie de usuario en el cliente web para identificar los usuarios que vuelven y una cookie de sesión para agrupar las actividades.
- Si no hay ningún script de cliente, puede establecer cookies en el servidor.
- Si un usuario real usa su sitio en diferentes navegadores, o mediante la navegación privada o de incógnito, o en diferentes máquinas, se cuenta más de una vez.
- Para identificar la información de inicio de sesión de un usuario en todas las máquinas y exploradores, agregue una llamada a setAuthenticatedUserContext().
¿Qué es el rendimiento o la sobrecarga del SDK de JavaScript?
El SDK de JavaScript de Application Insights tiene una sobrecarga mínima en el sitio web. Gracias a su tamaño comprimido con gzip de 36 KB y a los aproximadamente 15 ms que tarda en inicializarse, el SDK agrega una cantidad insignificante de tiempo de carga a su sitio web. Los componentes mínimos de la biblioteca se cargan rápidamente al usar el SDK y el script completo se descarga en segundo plano.
Además, mientras el script se descarga desde la red CDN, se pone en cola todo el seguimiento de la página, por lo que no se pierde ningún telemetría durante todo el ciclo de vida de la página. Este proceso de instalación proporciona a la página un sistema de análisis sencillo, invisible para los usuarios.
¿Qué exploradores son compatibles con el SDK de JavaScript?
![]() |
![]() |
![]() |
![]() |
![]() |
---|---|---|---|---|
Chrome (última versión) ✔ | Firefox (última versión) ✔ | v3.x: IE 9+ y Microsoft Edge ✔ v2.x: IE 8+ Compatible y Microsoft Edge ✔ |
Opera (última versión) ✔ | Safari (última versión) ✔ |
¿Dónde puedo encontrar ejemplos de código para el SDK de JavaScript?
Para ver ejemplos ejecutables, consulte Ejemplos del SDK de JavaScript para Application Insights.
¿Cuál es la compatibilidad de ES3/Internet Explorer 8 con el SDK de JavaScript?
Es necesario tomar las medidas necesarias para asegurarse de que este SDK continúa "funcionando" y no interrumpe la ejecución de JavaScript cuando se carga con un explorador más antiguo. Resultaría idóneo no admitir exploradores más antiguos, pero numerosos clientes no pueden controlar qué exploradores eligen usar sus usuarios finales.
Esta afirmación no significa que solo admitamos el conjunto de características común más bajo. Es necesario mantener la compatibilidad con el código ES3. Es necesario agregar nuevas características de manera que no interrumpan el análisis de JavaScript para ES3, y que se agreguen como característica opcional.
Consulte GitHub para ver información completa sobre la compatibilidad con Internet Explorer 8.
¿El SDK de JavaScript es de código abierto?
Sí, el SDK de JavaScript para Application Insights es de código abierto. Para ver el código fuente o para contribuir al proyecto, visite el repositorio oficial de GitHub.
¿Dónde puedo obtener más información sobre el SDK de JavaScript?
Para más información, consulte Habilitación de la supervisión real de usuarios de Application Insights de Azure Monitor.
Configuración del SDK de JavaScript
¿Cómo puedo actualizar la configuración del servidor de terceros para el SDK de JavaScript?
El lado servidor debe ser capaz de aceptar conexiones que tengan esos encabezados. En función de la configuración de Access-Control-Allow-Headers
en el lado servidor, a menudo es necesario ampliar la lista del lado servidor mediante la adición manual de Request-Id
, Request-Context
y traceparent
(encabezado distribuido de W3C).
Access-Control-Allow-Headers: Request-Id
, traceparent
, Request-Context
, <your header>
¿Cómo puedo deshabilitar el seguimiento distribuido para el SDK de JavaScript?
El seguimiento distribuido se puede deshabilitar en la configuración.
¿Application Insights captura siempre las respuestas HTTP 502 y 503?
No. Application Insights no siempre captura los errores "502 Puerta de enlace no válida" y "503 Servicio no disponible". Si solo se usa JavaScript del lado cliente para la supervisión, este comportamiento sería el esperado, ya que la respuesta de error se devuelve antes que la página que contiene el encabezado HTML con el fragmento de código de JavaScript de supervisión que se está representando.
Si la respuesta 502 o 503 se ha enviado desde un servidor con la supervisión del lado servidor habilitada, el SDK de Application Insights recopila los errores.
Incluso con la supervisión del lado servidor habilitada en el servidor web de una aplicación, a veces Application Insights no captura un error 502 o 503. Muchos servidores web modernos no permiten que un cliente se comunique directamente. En lugar de ellos, emplean soluciones como los servidores proxy inversos para pasar información entre el cliente y los servidores web front-end.
En este escenario, se puede devolver una respuesta 502 o 503 a un cliente por una incidencia en la capa de proxy inverso, de modo que no sería capturado de inmediato por Application Insights. Para ayudar a detectar problemas en esta capa, es posible que tenga que reenviar registros desde el proxy inverso a Log Analytics y crear una regla personalizada para buscar respuestas 502 o 503. Para obtener más información sobre las causas comunes de los errores 502 y 503, consulte Solución de errores de HTTP de "502 Puerta de enlace no válida" y "503 Servicio no disponible" en Azure App Service.
¿Dónde puedo obtener más información sobre la configuración del SDK de JavaScript?
Para más información, consulte Configuración del SDK de JavaScript de Application Insights.
Extensiones de marco de JavaScript
¿Cómo genera Application Insights la información del dispositivo (explorador, sistema operativo, idioma, modelo)?
El explorador pasa la cadena del Agente de usuario en el encabezado HTTP de la solicitud. El servicio de ingesta de Application Insights utiliza UA Parser para generar los campos que se ven en las tablas de datos y en las experiencias de usuario. Como resultado, los usuarios de Application Insights no pueden cambiar estos campos.
Ocasionalmente, estos datos podrían faltar o ser inexactos si el usuario o la empresa deshabilita el envío de un agente de usuario en la configuración del explorador. Es posible que las expresiones regulares del analizador de UA no incluyan toda la información del dispositivo. O bien, es posible que Application Insights no haya adoptado las actualizaciones más recientes.
¿Dónde puedo obtener más información sobre las extensiones de marco de JavaScript?
Para obtener más información, consulte Habilitación de una extensión de marco para el SDK de JavaScript de Application Insights.
Áreas de trabajo administradas
¿Es necesario actualizar scripts o automatización que hagan referencia a recursos clásicos?
No. Las plantillas de ARM y las llamadas API existentes siguen funcionando. Al intentar crear un recurso clásico, se crea en su lugar un recurso basado en el área de trabajo con un área de trabajo administrada.
¿Se me notifica antes de migrar mi recurso?
No. La notificación de migraciones de recursos individuales no está disponible. Para controlar cuándo y cómo se migran los recursos, use la migración manual.
¿Cuánto tarda el proceso de migración?
Las migraciones individuales suelen completarse en menos de dos minutos. La implementación completa tiene lugar en varias semanas en todas las regiones.
¿Cómo puedo saber si se migra un recurso?
Después de la migración, el recurso vincula a un área de trabajo de Log Analytics en la página Información general. El aviso de retirada clásico se quita y el libro de retiradas ya no enumera el recurso.
¿Cambiará la facturación después de la migración?
Los costos suelen ser similares. Application Insights basado en el área de trabajo permite ahorrar costos, por lo que recomendamos revisar los planes de precios.
Si está en un modelo de facturación heredado, revise la documentación de precios para obtener más información.
¿Se pierden alertas o pruebas de disponibilidad durante la migración?
No. Todas las alertas, paneles y pruebas de disponibilidad permanecen intactas y siguen funcionando después de la migración.
¿Dónde puedo obtener más información sobre las áreas de trabajo administradas?
Para más información, consulte Áreas de trabajo administradas en Application Insights.
Node.js.
¿Cómo puedo deshabilitar la correlación de telemetría?
Para deshabilitar la correlación de telemetría, use la propiedad correlationHeaderExcludedDomains
en la configuración. Para obtener más información, consulte ApplicationInsights-node.js.
¿Cómo puedo configurar el nivel de registro deseado?
Para configurar el nivel de registro deseado que usará Application Insights, use la APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL
variable de entorno.
Los valores admitidos son NONE, ERROR, WARN, INFO, DEBUG, VERBOSE y ALL.
Para obtener más información, consulte ApplicationInsights-node.js.
¿Dónde puedo obtener más información sobre la supervisión de Node.js servicios y aplicaciones con Application Insights?
Para más información, consulte Supervisión de los servicios y aplicaciones de Node.js con Application Insights.
Azure Monitor OpenTelemetry
¿Dónde se puede encontrar una lista de las versiones del SDK de Application Insights y sus nombres?
En GitHub se hospeda una lista de versiones y nombres del SDK. Para obtener más información, consulta Versión del SDK.
¿Dónde puedo obtener más información sobre OpenTelemetry?
Para más información, consulte Recopilación de telemetría con OpenTelemetry en Application Insights.
Migración desde los SDK de Application Insights para .NET a OpenTelemetry de Azure Monitor
¿Cómo se asignan las API del SDK a los conceptos de OpenTelemetry?
OpenTelemetry es un marco de observabilidad independiente del proveedor. No hay ninguna API de Application Insights en el SDK ni las bibliotecas de OpenTelemetry. Antes de realizar la migración, es importante comprender algunos de los conceptos de OpenTelemetry.
En Application Insights, toda la telemetría se administra mediante una sola instancia de
TelemetryClient
yTelemetryConfiguration
. En OpenTelemetry, cada una de las tres señales de telemetría (seguimientos, métricas y registros) tiene su propia configuración. Puede crear manualmente la telemetría desde el runtime de .NET sin bibliotecas externas. Para más información, vea las guías de .NET sobre seguimiento distribuido, métricas y registro.En Application Insights se usaba
TelemetryModules
para recopilar datos de telemetría automáticamente para la aplicación. En su lugar, OpenTelemetry usa bibliotecas de instrumentación para recopilar datos de telemetría de componentes específicos (como AspNetCore para las solicitudes y HttpClient para las dependencias).En Application Insights se usaba
TelemetryInitializers
para enriquecer la telemetría con información adicional o para invalidar las propiedades. Con OpenTelemetry, puede escribir un procesador para personalizar una señal específica. Además, muchas bibliotecas de instrumentación de OpenTelemetry ofrecen un métodoEnrich
para personalizar la telemetría generada por ese componente específico.En Application Insights se usaba
TelemetryProcessors
para filtrar la telemetría. También se puede usar un procesador de OpenTelemetry para aplicar reglas de filtrado a una señal específica.
¿Cómo se asignan los tipos de telemetría de Application Insights a OpenTelemetry?
En esta tabla se asignan los tipos de datos de Application Insights a los conceptos de OpenTelemetry y sus implementaciones de .NET.
Tabla de Azure Monitor | Tipo de datos de Application Insights | Tipo de datos de OpenTelemetry | Implementación de .NET |
---|---|---|---|
customEvents | EventTelemetry | No disponible | No disponible |
customMetrics | MetricTelemetry | Métricas | System.Diagnostics.Metrics.Meter |
dependencias | DependencyTelemetry | Intervalos (cliente, interno, consumidor) | System.Diagnostics.Activity |
excepciones | ExceptionTelemetry | Excepciones | System.Exception |
solicitudes | RequestTelemetry | Intervalos (servidor, productor) | System.Diagnostics.Activity |
Huellas | RastreoTelemetría | Registros | Microsoft.Extensions.Logging.ILogger |
Huellas | RastreoTelemetría | Span Events | System.Diagnostics.ActivityEvent |
En los documentos siguientes se proporciona más información.
¿Cómo se relacionan los conceptos de muestreo de Application Insights con OpenTelemetry?
Aunque Application Insights ofrecía muchas opciones para configurar el muestreo, el exportador de Azure Monitor o la distribución de Azure Monitor solo ofrece muestreo de frecuencia fija. Solo se pueden muestrear las solicitudes y las dependencias (trazas de OpenTelemetry).
Para obtener ejemplos de código en los que se detalla cómo configurar el muestreo, vea nuestra guía Habilitación del muestreo
¿Cómo se integran los procesadores de telemetría y los inicializadores con OpenTelemetry?
En el SDK de .NET de Application Insights, se usan procesadores de telemetría para filtrar y modificar o descartar la telemetría. Use inicializadores de telemetría para agregar o modificar propiedades personalizadas. Para más información, vea la documentación de Azure Monitor. OpenTelemetry reemplaza estos conceptos por procesadores de actividad o registro, que enriquecen y filtran la telemetría.
Filtrado de seguimientos
Para filtrar los datos de telemetría en OpenTelemetry, puede implementar un procesador de actividad. Este ejemplo es equivalente al de Application Insights para filtrar los datos de telemetría, como se describe en la documentación de Azure Monitor. En el ejemplo se muestra dónde se filtran las llamadas de dependencia fallidas.
using System.Diagnostics;
using OpenTelemetry;
internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (!OKtoSend(activity))
{
activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
}
}
private bool OKtoSend(Activity activity)
{
return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
}
}
Para usar este procesador, debe crear una instancia de TracerProvider
y agregar el procesador antes de AddAzureMonitorTraceExporter
.
using OpenTelemetry.Trace;
public static void Main()
{
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddProcessor(new SuccessfulDependencyFilterProcessor())
.AddAzureMonitorTraceExporter()
.Build();
}
Filtrado de registros
Las implementaciones de ILogger
tienen un mecanismo integrado para aplicar el filtrado de registros. Este filtrado le permite controlar los registros que se envían a cada proveedor registrado, incluido OpenTelemetryLoggerProvider
. "OpenTelemetry" es el alias de OpenTelemetryLoggerProvider
, que se usa para configurar reglas de filtrado.
En el ejemplo siguiente se define "Error" como la instancia de LogLevel
predeterminada y también se define "Warning" como la instancia de LogLevel
mínima para una categoría definida por el usuario. Estas reglas, tal y como se definen, solo se aplican a OpenTelemetryLoggerProvider
.
builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);
Para más información, lea la documentación de .NET de OpenTelemetry sobre registros.
Adición de propiedades personalizadas a seguimientos
En OpenTelemetry, puede usar procesadores de actividad para enriquecer los datos de telemetría con más propiedades. Es similar al uso de inicializadores de telemetría en Application Insights, donde puede modificar las propiedades de telemetría.
De manera predeterminada, el exportador de Azure Monitor marca cualquier solicitud HTTP con un código de respuesta de 400 o superior como error. Pero si quiere tratar 400 como correcto, puede agregar un procesador de actividad enriquecedor que establezca la actividad como correcta y agregue una etiqueta para incluir más propiedades de telemetría. Es similar a agregar o modificar propiedades mediante un inicializador en Application Insights, como se describe en la documentación de Azure Monitor.
Este es un ejemplo de cómo agregar propiedades personalizadas e invalidar el comportamiento predeterminado para determinados códigos de respuesta:
using System.Diagnostics;
using OpenTelemetry;
/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (activity.Kind == ActivityKind.Server)
{
int responseCode = GetResponseCode(activity);
if (responseCode >= 400 && responseCode < 500)
{
// If we set the Success property, the SDK won't change it
activity.SetStatus(ActivityStatusCode.Ok);
// Allow to filter these requests in the portal
activity.SetTag("Overridden400s", "true");
}
// else leave the SDK to set the Success property
}
}
private int GetResponseCode(Activity activity)
{
foreach (ref readonly var tag in activity.EnumerateTagObjects())
{
if (tag.Key == "http.response.status_code" && tag.Value is int value)
{
return value;
}
}
return 0;
}
}
Para usar este procesador, debe crear una instancia de TracerProvider
y agregar el procesador antes de AddAzureMonitorTraceExporter
.
using OpenTelemetry.Trace;
public static void Main()
{
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource("Company.Product.Name")
.AddProcessor(new MyEnrichingProcessor())
.AddAzureMonitorTraceExporter()
.Build();
}
¿Cómo se realiza el seguimiento manual de la telemetría mediante OpenTelemetry?
Envío de seguimientos: manual
Las trazas en Application Insights se almacenan como RequestTelemetry
y DependencyTelemetry
. En OpenTelemetry, las trazas se modelan como Span
mediante la clase Activity
.
OpenTelemetry .NET usa las clases ActivitySource
y Activity
para el seguimiento, que forman parte del runtime de .NET. Este enfoque es único porque la implementación de .NET integra la API de seguimiento directamente en el propio runtime. El paquete System.Diagnostics.DiagnosticSource
permite a los desarrolladores usar ActivitySource
para crear y administrar instancias de Activity
. Este método proporciona una manera perfecta de agregar seguimiento a aplicaciones de .NET sin depender de bibliotecas externas, mediante la aplicación de las funcionalidades integradas del ecosistema de .NET. Para obtener información detallada, consulte los tutoriales de instrumentación de seguimiento distribuido.
A continuación se muestra cómo migrar el seguimiento manual:
Nota:
En Application Insights, el nombre del rol y la instancia del rol se pueden establecer en un nivel de telemetría individual. No obstante, con el exportador de Azure Monitor, no se puede personalizar en un nivel de telemetría individual. El nombre y la instancia de rol se extraen del recurso de OpenTelemetry y se aplican en todos los datos de telemetría. Lea este documento para más información: Establecimiento del nombre y la instancia de rol en la nube.
DependencyTelemetry
Application Insights DependencyTelemetry
se usa para modelar las solicitudes salientes. Aquí se muestra cómo convertirlo en OpenTelemetry:
Ejemplo de Application Insights:
DependencyTelemetry dep = new DependencyTelemetry
{
Name = "DependencyName",
Data = "https://www.example.com/",
Type = "Http",
Target = "www.example.com",
Duration = TimeSpan.FromSeconds(10),
ResultCode = "500",
Success = false
};
dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);
Ejemplo de OpenTelemetry:
var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(resourceBuilder)
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
activity?.SetTag("url.full", "https://www.example.com/");
activity?.SetTag("server.address", "www.example.com");
activity?.SetTag("http.request.method", "GET");
activity?.SetTag("http.response.status_code", "500");
activity?.SetTag("customprop1", "custom value1");
activity?.SetStatus(ActivityStatusCode.Error);
activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}
RequestTelemetry
Application Insights RequestTelemetry
modela las solicitudes entrantes. Aquí se muestra cómo migrarlo a OpenTelemetry:
Ejemplo de Application Insights:
RequestTelemetry req = new RequestTelemetry
{
Name = "RequestName",
Url = new Uri("http://example.com"),
Duration = TimeSpan.FromSeconds(10),
ResponseCode = "200",
Success = true,
Properties = { ["customprop1"] = "custom value1" }
};
req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);
Ejemplo de OpenTelemetry:
var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(resourceBuilder)
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
activity?.SetTag("url.scheme", "https");
activity?.SetTag("server.address", "www.example.com");
activity?.SetTag("url.path", "/");
activity?.SetTag("http.response.status_code", "200");
activity?.SetTag("customprop1", "custom value1");
activity?.SetStatus(ActivityStatusCode.Ok);
}
Seguimiento de operaciones personalizadas
En Application Insights, el seguimiento de las operaciones personalizadas se realiza mediante los métodos StartOperation
y StopOperation
. En OpenTelemetry .NET se logra mediante ActivitySource
y Activity
. Para las operaciones con ActivityKind.Server
y ActivityKind.Consumer
, el exportador de Azure Monitor genera RequestTelemetry
. Para ActivityKind.Client
, ActivityKind.Producer
y ActivityKind.Internal
, genera DependencyTelemetry
. Para más información sobre el seguimiento de operaciones personalizadas, vea la documentación de Azure Monitor. Para más información sobre el uso de ActivitySource
y Activity
en .NET, vea los tutoriales de instrumentación de seguimiento distribuido de .NET.
Este es un ejemplo de cómo iniciar y detener una actividad para las operaciones personalizadas:
using System.Diagnostics;
using OpenTelemetry;
var activitySource = new ActivitySource("Company.Product.Name");
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
activity?.SetTag("customTag", "customValue");
// Perform your custom operation logic here
// No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}
Envío de registros
En Application Insights, los registros se almacenan como TraceTelemetry
y ExceptionTelemetry
.
RastreoTelemetría
En OpenTelemetry, el registro se integra mediante la interfaz ILogger
. Aquí te mostramos cómo migrar TraceTelemetry
:
Ejemplo de Application Insights:
TraceTelemetry traceTelemetry = new TraceTelemetry
{
Message = "hello from tomato 2.99",
SeverityLevel = SeverityLevel.Warning,
};
traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);
Ejemplo de OpenTelemetry:
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var loggerFactory = LoggerFactory.Create(builder => builder
.AddOpenTelemetry(logging =>
{
logging.SetResourceBuilder(resourceBuilder);
logging.AddAzureMonitorLogExporter();
}));
// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();
// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);
internal static partial class LoggerExtensions
{
[LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
public static partial void FoodPrice(this ILogger logger, string name, double price);
}
ExceptionTelemetry
En Application Insights se usa ExceptionTelemetry
para registrar excepciones. Aquí se muestra cómo realizar la migración a OpenTelemetry:
Ejemplo de Application Insights:
ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
SeverityLevel = SeverityLevel.Error
};
exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);
Ejemplo de OpenTelemetry:
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var loggerFactory = LoggerFactory.Create(builder => builder
.AddOpenTelemetry(logging =>
{
logging.SetResourceBuilder(resourceBuilder);
logging.AddAzureMonitorLogExporter();
}));
// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();
try
{
// Simulate exception
throw new Exception("Test exception");
}
catch (Exception ex)
{
// Emit exception: This uses the logger instance to write a new exception
logger?.LogError(ex, "An error occurred");
}
Envío de métricas
En Application Insights, las métricas se almacenan como MetricTelemetry
. En OpenTelemetry, las métricas se modelan como Meter
desde el paquete System.Diagnostics.DiagnosticSource
.
Application Insights tiene API de métricas sin agregación previa (TrackMetric()
) y con agregación previa (GetMetric().TrackValue()
). A diferencia de OpenTelemetry, Application Insights no tiene ninguna noción de instrumentos. Application Insights tiene la misma API para todos los escenarios de métricas.
En OpenTelemetry, por otro lado, es necesario que los usuarios primero elijan el instrumento de métrica correcto en función de la semántica real de la métrica. Por ejemplo, si la intención es contar algo (como el número de solicitudes de servidor totales recibidas, etc.), se debe usar el Contador de OpenTelemetry. Si la intención es calcular varios percentiles (como el valor P99 de latencia del servidor), se debe usar el instrumento Histograma de OpenTelemetry. Debido a esta diferencia fundamental entre Application Insights y OpenTelemetry, no se realiza ninguna comparación directa entre los dos.
A diferencia de Application Insights, OpenTelemetry no proporciona mecanismos integrados para enriquecer o filtrar métricas. En Application Insights, se pueden usar procesadores de telemetría e inicializadores para modificar o descartar métricas, pero esta funcionalidad no está disponible en OpenTelemetry.
Además, OpenTelemetry no admite el envío de métricas en estado bruto directamente, ya que no hay ningún equivalente a la funcionalidad de TrackMetric()
que se encuentra en Application Insights.
La migración de Application Insights a OpenTelemetry implica reemplazar todos los usos de la API de métricas de Application Insights por la API de OpenTelemetry. Es necesario comprender los distintos instrumentos de OpenTelemetry y su semántica.
Sugerencia
El histograma es el equivalente más versátil y más cercano a la API GetMetric().TrackValue()
de Application Insights. Puede reemplazar las API de métricas de Application Insights por el Histograma para lograr el mismo propósito.
Otros tipos de telemetría
Eventos Personalizados
No se admite en OpenTelemetry.
Ejemplo de Application Insights:
TelemetryClient.TrackEvent()
AvailabilityTelemetry
No se admite en OpenTelemetry.
Ejemplo de Application Insights:
TelemetryClient.TrackAvailability()
PageViewTelemetry
No se admite en OpenTelemetry.
Ejemplo de Application Insights:
TelemetryClient.TrackPageView()
¿Puedo obtener métricas en tiempo real de las aplicaciones de consola y de servicio de trabajo?
Se recomienda el exportador de OpenTelemetry de Azure Monitor para aplicaciones de servicio de trabajo y de consola, que no incluyen métricas dinámicas.
¿Dónde puedo obtener más información sobre la migración de SDK de Application Insights de .NET a OpenTelemetry?
Para más información, consulte Migración de SDK de Application Insights de .NET a OpenTelemetry de Azure Monitor.
Muestreo de OpenTelemetry
¿La muestra personalizada de Application Insights está basada en la cola?
La muestra personalizada de Application Insights toma decisiones de muestreo después de la creación del seguimiento, en lugar de antes, por lo que no sigue un enfoque tradicional basado en la cabecera. En su lugar, aplica decisiones de muestreo al final de la generación de intervalos, una vez completado el intervalo, pero antes de la exportación.
Aunque este comportamiento se parece al muestreo basado en la cola de algunas maneras, la muestra no espera a recopilar varios intervalos del mismo seguimiento antes de decidir. En su lugar, usa un hash del identificador de seguimiento para ayudar a garantizar la integridad del seguimiento.
Este enfoque equilibra la completitud del rastreo y la eficacia, y evita el mayor costo asociado al muestreo completo basado en cola.
Para tomar decisiones de muestreo basadas en el resultado de un seguimiento completo (por ejemplo, determinar si se produjo un error en cualquier intervalo dentro del seguimiento), se requiere el muestreo de cola completo en un agente o recopilador de nivel inferior. Esta funcionalidad no se admite actualmente, pero puede solicitarla como una nueva característica a través del Centro de opiniones.
¿Cómo se compara el sampler personalizado de Application Insights con el muestreo basado en encabezados o colas de OpenTelemetry?
Método de muestreo | Punto de decisión | Puntos destacados | Debilidades |
---|---|---|---|
Basado en la cabecera | Antes de que se inicie un intervalo | Baja latencia, sobrecarga mínima | Puede muestrear seguimientos deseados, incluidos los errores |
Basado en la cola | Después de que los intervalos se almacenen en búfer en función de los umbrales de tiempo o volumen | Permite criterios altamente selectivos para el muestreo de trazas | Mayor costo y retraso de procesamiento agregado |
Muestra personalizada de App Insights | Fin de la generación de intervalos | Equilibra la completitud del rastro con la eficacia. | Obligatorio para la compatibilidad de Live Metrics y api clásica |
¿Puedo muestrear dependencias, solicitudes u otros tipos de telemetría a diferentes tasas?
No, la muestra aplica una tasa uniforme a todos los tipos de telemetría de un seguimiento. Las solicitudes, dependencias y otros intervalos siguen el mismo porcentaje de muestreo. Para aplicar diferentes tasas por tipo de telemetría, considera la posibilidad de usar procesadores de intervalos de OpenTelemetry o (transformaciones en tiempo de ingesta)[opentelemetry-overview.md#telemetry-routing].
¿Cómo propaga el muestreo personalizado de Application Insights las decisiones de muestreo?
El muestreador personalizado de Application Insights propaga las decisiones de muestreo mediante el estándar de contexto de seguimiento de W3C de forma predeterminada. Este estándar permite que las decisiones de muestreo fluyan entre los servicios. Sin embargo, dado que la muestra toma decisiones de muestreo al final de la generación de intervalos, después de la llamada a los servicios de bajada, la propagación incluye información de muestreo incompleta. Esta limitación cumple con la especificación de contexto de seguimiento de W3C, pero los servicios de bajada no pueden usar de forma confiable esta decisión de muestreo propagada.
¿El muestreador personalizado de Application Insights respeta las decisiones de muestreo de los servicios ascendentes?
No, el sampler personalizado de Application Insights siempre toma una decisión de muestreo independiente, incluso si el servicio ascendente usa el mismo algoritmo de muestreo. Las decisiones de muestreo de los servicios ascendentes, incluidas las que usan encabezados de contexto de seguimiento de W3C, no influyen en la decisión del servicio de bajada. Sin embargo, realiza un muestreo basado en un hash del identificador de seguimiento para garantizar la completitud del seguimiento. Para mejorar la coherencia y reducir la posibilidad de que haya seguimientos rotos, configure todos los componentes del sistema para usar el mismo muestreo y la misma frecuencia de muestreo.
¿Por qué algunos seguimientos aparecen incompletos incluso cuando se usa el sampler personalizado de Application Insights?
Hay varias razones por las que los seguimientos pueden aparecer incompletos:
- Los distintos nodos de un sistema distribuido usan diferentes enfoques de muestreo que no coordinan las decisiones. Por ejemplo, un nodo aplica el muestreo basado en encabezado de OpenTelemetry y otro nodo aplica el muestreo a través del muestreador personalizado de Azure Monitor.
- Los distintos nodos se establecen en diferentes velocidades de muestreo, incluso si ambos usan el mismo enfoque de muestreo.
- Se establecen límites de filtrado, muestreo o velocidad en la canalización del lado del servicio, y esta configuración muestrea aleatoriamente los intervalos sin tener en cuenta la integridad de la traza.
Si un componente aplica el muestreo basado en la cabecera sin propagar la decisión de muestreo (mediante cabeceras de contexto de seguimiento de W3C), los servicios de bajada muestrean el seguimiento de forma independiente, lo que puede dar lugar a intervalos descartados. Como resultado, algunas partes del seguimiento no siempre están disponibles cuando se ven en Application Insights.
¿Dónde puedo obtener más información sobre el muestreo de OpenTelemetry?
Para más información, consulte Muestreo en Application Insights de Azure Monitor con OpenTelemetry.
Soporte técnico y comentarios de OpenTelemetry
¿Qué es OpenTelemetry?
Es un estándar de código abierto para la observabilidad. Obtenga más información en OpenTelemetry.
¿Por qué Microsoft Azure Monitor invierte en OpenTelemetry?
Microsoft está invirtiendo en OpenTelemetry por las siguientes razones:
- Es neutral con respecto a los proveedores y proporciona API y SDK coherentes en todos los idiomas.
- Con el tiempo, creemos que OpenTelemetry permitirá a los clientes de Azure Monitor observar las aplicaciones escritas en lenguajes más allá de los lenguajes admitidos.
- Expande los tipos de datos que puede recopilar a través de un amplio conjunto de bibliotecas de instrumentación.
- Los kits de desarrollo de software (SDK) de OpenTelemetry tienden a ser más eficaces a escala que sus predecesores, los SDK de Application Insights.
- OpenTelemetry se alinea con la estrategia de Microsoft para adoptar el código abierto.
¿Cuál es el estado de OpenTelemetry?
Ver el Estado de OpenTelemetry.
¿Qué es la distribución de OpenTelemetry de Azure Monitor?
Puede considerarlo como un contenedor fino que agrupa todos los componentes de OpenTelemetry para una experiencia de primera clase en Azure. Este contenedor también se denomina una distribución en OpenTelemetry.
¿Por qué debería usar la distribución de OpenTelemetry de Azure Monitor?
El uso de la Distribución de OpenTelemetry de Azure Monitor tiene varias ventajas sobre la OpenTelemetry nativa de la comunidad:
- Reduce el esfuerzo de habilitación
- Compatible con Microsoft
- Incorpora características específicas de Azure como:
- Compatibilidad de muestreo con los SDK de Application Insights clásicos
- Autenticación de Microsoft Entra
- Almacenamiento sin conexión y reintentos automáticos
- Statsbeat
- Métricas estándar de Application Insights
- Detección de metadatos de recursos para rellenar automáticamente el Nombre del rol en la nube y la Instancia de rol en la nube en varios entornos de Azure
- Live Metrics
Siguiendo el espíritu de OpenTelemetry, diseñamos la distribución para que sea abierta y ampliable. Por ejemplo, puede agregar:
- Un exportador de OpenTelemetry Protocol (OTLP) y enviar a un segundo destino simultáneamente
- Otras bibliotecas de instrumentación no incluidas en la distribución
Dado que la distribución proporciona una distribución de OpenTelemetry, la distribución admite cualquier cosa compatible con OpenTelemetry. Por ejemplo, puede agregar más procesadores de telemetría, exportadores o bibliotecas de instrumentación, si OpenTelemetry los admite.
Nota:
La distribución establece el tomador de muestras en una toma personalizada de frecuencia fija para Application Insights. Puede cambiar esto a un muestreador diferente, pero al hacerlo, podría deshabilitar algunas de las capacidades incluidas en la Distro. Para más información sobre el muestreador admitido, consulte la sección Habilitar muestreo de Configurar OpenTelemetry de Azure Monitor.
En el caso de los lenguajes sin un exportador de OpenTelemetry independiente compatible, la distribución de OpenTelemetry de Azure Monitor es la única manera admitida actualmente para usar OpenTelemetry con Azure Monitor. En el caso de los idiomas con un exportador de OpenTelemetry independiente compatible, tiene la opción de usar la distribución de OpenTelemetry de Azure Monitor o el exportador de OpenTelemetry independiente adecuado en función del escenario de telemetría. Para más información, consulte ¿Cuándo debo usar el exportador de OpenTelemetry de Azure Monitor?.
¿Cómo puedo probar la Distribución de OpenTelemetry de Azure Monitor?
Consulte nuestros documentos de habilitación para .NET, Java, JavaScript (Node.js) y Python.
¿Debería usar OpenTelemetry o el SDK de Application Insights?
Se recomienda usar la distribución openTelemetry de Azure Monitor para los nuevos proyectos cuando sus funcionalidades se alinean con sus necesidades de supervisión. OpenTelemetry es un marco estándar del sector que mejora la observabilidad multiplataforma y proporciona un enfoque estandarizado para la recopilación de telemetría.
Sin embargo, los SDK de Application Insights siguen proporcionando ciertas funcionalidades que aún no están totalmente automatizadas en OpenTelemetry, entre las que se incluyen:
- Seguimiento automático de dependencias: OpenTelemetry admite el seguimiento de dependencias, pero algunas dependencias requieren una configuración adicional en comparación con el seguimiento automático disponible en los SDK de Application Insights.
- Los tipos de telemetría personalizados, como
AvailabilityTelemetry
yPageViewTelemetry
: OpenTelemetry no tiene equivalentes directos. Se puede implementar una funcionalidad similar a través de la instrumentación manual. - Procesadores de telemetría e inicializadores: OpenTelemetry tiene procesadores y procesadores de intervalos, pero no reemplazan completamente los procesadores e inicializadores de telemetría de Application Insights en todos los escenarios.
- Recopilación de métricas extendidas: aunque OpenTelemetry tiene un sistema de métricas seguros, algunas métricas integradas de los SDK de Application Insights requieren una configuración manual en OpenTelemetry.
OpenTelemetry también proporciona ventajas sobre los SDK de Application Insights, entre los que se incluyen:
- Mejor estandarización entre plataformas
- Un ecosistema más amplio de bibliotecas de instrumentación
- Mayor flexibilidad en la recopilación y el procesamiento de datos
- Se ha mejorado la neutralidad del proveedor, aunque la distribución de OpenTelemetry de Azure Monitor todavía está optimizada para Azure.
La integración de OpenTelemetry de Azure Monitor evoluciona continuamente y Microsoft sigue mejorando sus funcionalidades. Si está considerando una transición, evalúe cuidadosamente si OpenTelemetry cumple actualmente los requisitos de observabilidad o si el SDK de Application Insights sigue siendo el mejor adecuado para sus necesidades.
¿Cuándo debo usar el exportador OpenTelemetry de Azure Monitor?
Para ASP.NET Core, Java, Node.js y Python, se recomienda usar la distribución de OpenTelemetry de Azure Monitor. Es una línea de código para empezar.
Para todos los demás escenarios de .NET, incluidos los ASP.NET clásicos, las aplicaciones de consola, Windows Forms (WinForms), etc., se recomienda usar el exportador de OpenTelemetry de Azure Monitor de .NET: Azure.Monitor.OpenTelemetry.Exporter
.
Para escenarios de telemetría de Python más complejos que requieren configuración avanzada, se recomienda usar el Exportador de OpenTelemetry de Azure Monitor de Python.
¿Cuál es el estado actual de las características de la Distribución de OpenTelemetry de Azure Monitor?
En el gráfico siguiente, se desglosa la compatibilidad de características de OpenTelemetry para cada lenguaje.
Característica | .RED | Node.js. | Pitón | Java |
---|---|---|---|---|
Seguimiento distribuido | ✅ | ✅ | ✅ | ✅ |
Métricas personalizadas | ✅ | ✅ | ✅ | ✅ |
Métricas estándar | ✅ | ✅ | ✅ | ✅ |
Muestreo de frecuencia fija | ✅ | ✅ | ✅ | ✅ |
Almacenamiento sin conexión y reintentos automáticos | ✅ | ✅ | ✅ | ✅ |
Informes de excepciones | ✅ | ✅ | ✅ | ✅ |
Recopilación de registros | ✅ | ⚠️ | ✅ | ✅ |
Eventos personalizados | ⚠️ | ⚠️ | ⚠️ | ✅ |
Autenticación de Microsoft Entra | ✅ | ✅ | ✅ | ✅ |
Métricas dinámicas | ✅ | ✅ | ✅ | ✅ |
Filtrado de métricas dinámicas | ✅ | ❌ | ❌ | ❌ |
Detección del contexto de recursos para VM/VMSS y App Service | ✅ | ❌ | ✅ | ✅ |
Detección del contexto de recursos para Azure Kubernetes Service (AKS) y Azure Functions | ❌ | ❌ | ❌ | ✅ |
Eventos de pruebas de disponibilidad generados mediante la API de seguimiento de disponibilidad | ❌ | ❌ | ❌ | ✅ |
Filtrar solicitudes, dependencias, registros y excepciones por identificador de usuario anónimo y origen sintético | ❌ | ❌ | ❌ | ✅ |
Filtrar las dependencias, los registros y las excepciones por nombre de la operación | ❌ | ❌ | ❌ | ✅ |
muestreo adaptable | ❌ | ❌ | ❌ | ✅ |
Generador de perfiles de .NET | ⚠️ | ❌ | ❌ | ⚠️ |
Depurador de instantáneas | ❌ | ❌ | ❌ | ❌ |
clave
- ✅ Esta característica está disponible para todos los clientes con soporte técnico formal.
- ⚠ Esta característica está disponible como versión preliminar pública. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.
- ❌ Esta característica no está disponible o no es aplicable.
¿Se puede usar OpenTelemetry para exploradores web?
Sí, pero no se recomienda y Azure no lo admite. OpenTelemetry JavaScript está altamente optimizado para Node.js. En su lugar, se recomienda usar el SDK de JavaScript para Application Insights.
¿Cuándo podemos esperar que el SDK de OpenTelemetry esté disponible para su uso en navegadores web?
El SDK web de OpenTelemetry no tiene una escala de tiempo de disponibilidad determinada. Es probable que falten varios años para que exista un SDK para navegadores que sea una alternativa viable al SDK de JavaScript Application Insights.
¿Puedo probar hoy OpenTelemetry en un explorador web?
El espacio aislado web de OpenTelemetry es una bifurcación diseñada para que OpenTelemetry funcione en un explorador. Todavía no es posible enviar telemetría a Application Insights. El SDK no define eventos de cliente generales.
¿Es compatible ejecutar Application Insights junto con agentes de la competencia como AppDynamics, DataDog y NewRelic?
Esta práctica no es algo que tengamos previsto probar o admitir, aunque nuestras distribuciones le permiten exportar a un punto de conexión OTLP junto con Azure Monitor de manera simultánea.
¿Puedo usar funcionalidades de previsualización en entornos de producción?
Esta opción no se recomienda. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.
¿Cuál es la diferencia entre la instrumentación manual y la automática?
Consulte la Introducción a OpenTelemetry.
¿Puedo usar OpenTelemetry-Collector?
Algunos clientes usan OpenTelemetry Collector como alternativa con agente, aunque Microsoft todavía no admite oficialmente un enfoque basado en agente para la supervisión de aplicaciones. Mientras tanto, la comunidad de código abierto contribuyó con un exportador de Azure Monitor de OpenTelemetry Collector que algunos clientes usan para enviar datos a Application Insights de Azure Monitor. Microsoft no admite esto.
¿Cuál es la diferencia entre OpenCensus y OpenTelemetry?
OpenCensus es el precursor de OpenTelemetry. Microsoft ayudó a juntar OpenTracing y OpenCensus para crear OpenTelemetry, un único estándar de observabilidad para el mundo. El SDK de Python recomendado para producción actual para Azure Monitor se basa en OpenCensus. Microsoft se ha comprometido a hacer que Azure Monitor se base en OpenTelemetry.
En Grafana, por qué veo "Estado 500. ¿No se pueden visualizar eventos de seguimiento mediante el visualizador de seguimiento"?
Podría intentar visualizar registros de texto sin formato en lugar de seguimientos de OpenTelemetry.
En Application Insights, la tabla 'Traces' almacena registros de texto sin procesar con fines de diagnóstico. Ayudan a identificar y correlacionar seguimientos asociados a solicitudes de usuario, otros eventos e informes de excepciones. Sin embargo, la tabla "Seguimientos" no contribuye directamente a la vista de transacciones de un extremo a otro (gráfico en cascada) en herramientas de visualización como Grafana.
Con la creciente adopción de prácticas nativas de la nube, hay una evolución en la recopilación de telemetría y la terminología. OpenTelemetry se convirtió en un estándar para recopilar e instrumentar datos de telemetría. En este contexto, el término "Rastros" adquirió un nuevo significado. En lugar de los registros sin procesar, "Seguimientos" en OpenTelemetry hacen referencia a una forma más completa y estructurada de telemetría que incluye intervalos, que representan unidades de trabajo individuales. Estos intervalos son cruciales para construir vistas de transacciones detalladas, lo que permite una mejor supervisión y diagnóstico de aplicaciones nativas de la nube.
¿Cómo debo instrumentar Blazor Apps?
Para instrumentar una aplicación Blazor, primero identifique el modelo de hospedaje. Blazor Server admite instrumentación completa basada en OpenTelemetry. Blazor WebAssembly se ejecuta en el explorador y admite instrumentación limitada a través de JavaScript.
¿Dónde puedo obtener más información sobre el soporte técnico y los comentarios de OpenTelemetry?
Para más información, consulte Soporte técnico y comentarios de OpenTelemetry para Application Insights.
Panel de información general
¿Puedo mostrar datos de más de 30 días?
No. Actualmente, hay un límite de 30 días para los datos que se pueden mostrar en un panel.
Veo un error de "recurso no encontrado" en el panel.
Si mueve o cambia el nombre de la instancia de Application Insights, se puede producir un error de "recurso no encontrado".
Para solucionar este comportamiento, elimine el panel predeterminado y seleccione nuevamente Panel de la aplicación para volver a crear uno nuevo.
¿Dónde puedo obtener más información sobre el panel información general?
Para obtener más información, consulte Panel de información general de Application Insights.
Canales de telemetría
¿El canal de Application Insights garantiza la entrega de los datos de telemetría? Si no es así, ¿cuáles son los escenarios en los que se pueden perder los datos de telemetría?
La respuesta corta es que ninguno de los canales integrados ofrece una garantía de tipo de transacción de entrega de telemetría al back-end. El canal ServerTelemetryChannel
es más avanzado comparado con InMemoryChannel
en lo que respecta a la entrega confiable, pero solo hace un intento de mejor esfuerzo para enviar la telemetría. Aún así, igualmente se pueden perder datos de telemetría en diversas situaciones, incluidos los escenarios comunes siguientes:
- Los elementos en la memoria se pierden cuando se bloquea la aplicación.
- Los datos de telemetría se pierden durante largos períodos de problemas de red. Los datos de telemetría se almacenan en el disco local durante las interrupciones de red o cuando se producen problemas con el back-end de Application Insights. Sin embargo, se descartan los elementos anteriores a 48 horas.
- Las ubicaciones predeterminadas del disco en las que se almacenan datos de telemetría en Windows son %LOCALAPPDATA% o %TEMP%. Normalmente, estas ubicaciones se encuentran en el entorno local de la máquina. Si la aplicación se migra físicamente desde una ubicación a otra, se pierde cualquier telemetría almacenada en la ubicación original.
- En Azure Web Apps en Windows, la ubicación de almacenamiento en disco predeterminada es D:\local\LocalAppData. Esta ubicación no se conserva. Se borra cuando se realizan reinicios de la aplicación, escalados horizontales y otras operaciones similares, lo que da lugar a la pérdida de cualquier telemetría almacenada. Puede reemplazar el valor predeterminado y especificar el almacenamiento en una ubicación persistente como D:\home. Sin embargo, dado que estas ubicaciones persistentes las proporciona el almacenamiento remoto, pueden ser lentas.
Aunque es menos probable, también es posible que el canal pueda generar elementos de telemetría duplicados. Este comportamiento se produce cuando ServerTelemetryChannel
hace reintentos debido a errores de red o tiempo de espera, cuando la telemetría se entregó al back-end, pero la respuesta se perdió debido a problemas de red o hubo un tiempo de espera.
¿ServerTelemetryChannel funciona en sistemas distintos de Windows?
Aunque el nombre de su paquete y el espacio de nombres incluye "WindowsServer", este canal se admite en sistemas distintos de Windows, con la siguiente excepción. En los sistemas distintos de Windows, el canal no crea una carpeta de almacenamiento local de forma predeterminada. Debe crear una carpeta de almacenamiento local y configurar el canal para que la use. Una vez configurado el almacenamiento local, el canal funciona del mismo modo en todos los sistemas.
Nota:
Con la versión 2.15.0-beta3 y superior, ahora se crea automáticamente almacenamiento local para Linux, Mac y Windows. En el caso de sistemas que no son Windows, el SDK creará automáticamente una carpeta de almacenamiento local basada en la siguiente lógica:
-
${TMPDIR}
: si está establecida la variable de entorno${TMPDIR}
, se usa esta ubicación. -
/var/tmp
: si la ubicación anterior no existe, se prueba/var/tmp
. -
/tmp
: si las dos ubicaciones anteriores no existen, se pruebatmp
. - Si no existe ninguna de esas ubicaciones, no se crea almacenamiento local y todavía se requiere configuración manual. Para obtener información completa sobre la implementación, consulte este repositorio de GitHub.
¿El SDK crea almacenamiento local temporal? ¿Se cifran los datos en el almacenamiento?
El SDK almacena elementos de telemetría en el almacenamiento local cuando se producen problemas de red o hay una limitación. Estos datos no se cifran localmente.
En el caso de los sistemas Windows, el SDK crea automáticamente una carpeta temporal local en el directorio %LOCALAPPDATA% o %TEMP% y restringe el acceso solo a los administradores y al usuario actual.
Para los sistemas que distintos de Windows, no se crea ningún almacenamiento local automáticamente mediante el SDK, por lo que no se almacena ningún dato localmente de forma predeterminada.
Nota:
Con la versión 2.15.0-beta3 y superior, ahora se crea automáticamente almacenamiento local para Linux, Mac y Windows.
Puede crear un directorio de almacenamiento usted mismo y configurar el canal para que lo utilice. En este caso, es su responsabilidad asegurarse de que se protege el directorio. Obtenga más información sobre la protección de datos y la privacidad.
¿Dónde puedo obtener más información sobre los canales de telemetría?
Para más información, consulte Canales de telemetría en Application Insights.
Búsqueda de transacciones
¿Qué cantidad de datos se conserva?
Consulte Resumen de límites.
¿Cómo puedo ver datos POST en mis solicitudes de servidor?
Aunque no registramos los datos POST automáticamente, puede usar TrackTrace o llamadas de registro. Coloque los datos POST en el parámetro de mensaje. No puede filtrar por el mensaje de la misma forma que con las propiedades, pero el límite de tamaño es mayor.
¿Por qué mi búsqueda de funciones de Azure no devuelve ningún resultado?
Azure Functions no registra cadenas de consulta de dirección URL.
¿Dónde puedo obtener más información sobre la búsqueda de transacciones?
Para obtener más información, consulte Búsqueda de transacciones y diagnósticos.
Diagnósticos de transacciones
¿Por qué veo un único componente en el gráfico y los demás componentes solo se muestran como dependencias externas sin detalles?
Posibles razones:
- ¿Existen otros componentes instrumentados con Application Insights?
- ¿Usa la versión más reciente y estable de SDK de Application Insights?
- Si estos componentes son recursos independientes de Application Insights, valide que tiene acceso. Si tiene acceso y los componentes se instrumentan con el SDK más reciente de Application Insights, háganoslo saber mediante el canal de comentarios en la parte superior derecha.
Veo filas duplicadas para las dependencias. ¿Es normal este comportamiento?
Actualmente, se está mostrando la llamada de dependencia de salida de forma independiente de la solicitud entrante. Por lo general, las dos llamadas son idénticas y solo difiere el valor de duración debido al recorrido de ida y vuelta de la red. El icono inicial y los distintos estilos de las barras de duración le ayudan a diferenciarlos. ¿Le resulta confusa esta presentación de los datos? Envíenos sus comentarios.
¿Qué hay de los desfases temporales entre las instancias de los diferentes componentes?
Las escalas de tiempo se ajustan para los desfases temporales en el gráfico de transacciones. Puede ver las marcas de tiempo exactas en el panel de detalles o con Log Analytics.
¿Por qué faltan en la nueva experiencia la mayoría de las consultas de elementos relacionadas?
Este comportamiento es por diseño. Todos los elementos relacionados, en todos los componentes, están disponibles en el lado izquierdo (en las secciones superior e inferior). La nueva experiencia tiene dos elementos relacionados que no se tratan en el lado izquierdo: todos los datos de telemetría de los cinco minutos anteriores y posteriores a este evento y la escala de tiempo del usuario.
¿Hay alguna manera de ver menos eventos por transacción cuando uso el SDK de JavaScript de Application Insights?
La experiencia de diagnóstico de transacciones muestra todos los datos de telemetría en una sola operación que comparte un id. de operación. De forma predeterminada, el SDK de Application Insights crea una operación para cada vista de página única. En una aplicación de página única (SPA), solo se genera un evento de vista de página y se usa un id. de operación único para todos los datos de telemetría generados. Como resultado, muchos eventos se pueden poner en correlación con la misma operación.
En estos escenarios, puede usar el seguimiento automático de rutas para crear automáticamente nuevas operaciones para la navegación en la aplicación de página única. Debe activar enableAutoRouteTracking para que se genere una vista de página cada vez que se actualice la ruta URL (se produce la vista de página lógica). Si desea actualizar manualmente el id. de operación, llame a appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId()
. Al desencadenar manualmente un evento PageView, también se restablecerá el id. de operación.
¿Por qué las duraciones de los detalles de la transacción no se suman a la duración de la solicitud de nivel superior?
El tiempo que no se explica en el gráfico de Gantt es el tiempo que no está cubierto por una dependencia con seguimiento. Esta incidencia puede producirse porque las llamadas externas no se instrumentaron, ya sea de forma automática o manual. También se puede producir porque el tiempo necesario estaba en proceso, en vez de debido a una llamada externa.
Si se han instrumentado todas las llamadas, la causa principal probable del tiempo empleado es en proceso. Una herramienta útil para diagnosticar el proceso es el .NET Profiler.
¿Qué ocurre si veo el mensaje "Error al recuperar datos" al navegar por Application Insights en Azure Portal?
Este error indica que el explorador no pudo llamar a una API necesaria o que la API devolvió una respuesta de error. Para solucionar problemas del comportamiento, abra una ventana inPrivate del explorador y deshabilite las extensiones del explorador que se ejecutan; después, identifique si todavía puede reproducir el comportamiento del portal. Si el error del portal todavía se produce, inténtelo con otros exploradores u otras máquinas, investigue DNS u otros problemas relacionados con la red desde el equipo cliente en el que se producen errores en las llamadas API. Si el error del portal continúa y necesita más investigación, recopile un seguimiento de red del explorador al reproducir el comportamiento inesperado del portal y, a continuación, abra un caso de soporte técnico desde Azure Portal.
¿Dónde puedo obtener más información sobre el diagnóstico de transacciones?
Para obtener más información, consulte Búsqueda de transacciones y diagnósticos.
Análisis del uso
¿Representa el evento inicial la primera vez que el evento aparece en una sesión o en cualquier momento que aparezca en una sesión?
El evento inicial de la visualización solo representa la primera vez que un usuario envía esa vista de página o evento personalizado durante una sesión. Si los usuarios pueden enviar el evento inicial varias veces en una sesión, la columna Paso 1 solo muestra el comportamiento de los usuarios después de la primera instancia del evento inicial, no todas las instancias.
Algunos de los nodos de mi visualización tienen un nivel demasiado alto. ¿Cómo puedo conseguir nodos más detallados?
Use las opciones de Dividir por en el menú Editar:
Seleccione el evento que desea analizar en el menú Evento.
Seleccione una dimensión en el menú Dimensión. Por ejemplo, si tiene un evento denominado Clic en botón, pruebe una propiedad personalizada denominada Nombre de botón.
Definí una cohorte de usuarios de un país o región concretos. Cuando comparo esta cohorte en la herramienta Usuarios con establecer un filtro en ese país o región, ¿por qué veo resultados diferentes?
Las cohortes y los filtros son diferentes. Suponga que tiene una cohorte de usuarios del Reino Unido (definida como el ejemplo anterior) y compara sus resultados con configurar el filtro Country or region = United Kingdom
:
La versión de cohorte muestra todos los eventos de los usuarios que enviaron uno o varios eventos desde el Reino Unido en el intervalo de tiempo actual. Si se divide según el país o región, probablemente vea muchos países y regiones.
La versión de filtros solo muestra los eventos del Reino Unido. Si se divide según el país o región, solo se verá el Reino Unido.
¿Cómo puedo ver los datos en diferentes niveles (diarios, mensuales o semanales)?
Puede seleccionar el filtro Grano de fecha para cambiar el grano. El filtro está disponible en todas las pestañas de dimensiones.
¿Cómo puedo acceder a los conocimientos de mi aplicación que no están disponibles en los libros de trabajo HEART?
Puede consultar en detalle los datos que alimentan el libro HEART si los objetos visuales no responden a todas sus preguntas. Para realizar esta tarea, en la sección Supervisión de Application Insights, seleccione Registros y consulte la customEvents
tabla. Algunos atributos de Click Analytics están incluidos en el campo customDimensions
.
Aquí se muestra una consulta de ejemplo:
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
Para obtener más información sobre los registros de Azure Monitor, vaya a la página Introducción a los registros de Azure Monitor.
¿Puedo editar elementos visuales en el libro de trabajo?
Sí. Para obtener información sobre cómo editar plantillas de libro de trabajo, consulte Plantillas de libros de trabajo de Azure.
¿Dónde puedo obtener más información sobre el análisis de uso?
Para más información, consulte Análisis de uso con Application Insights.
Aplicaciones de servicio de trabajo
¿Qué paquete debo usar?
Escenario de aplicación de .NET Core | Paquete |
---|---|
Sin HostedServices | WorkerService |
Con HostedServices | AspNetCore (no WorkerService) |
Con HostedServices, con supervisión solo de HostedServices | WorkerService (escenario poco frecuente) |
¿Pueden los HostedServices dentro de una aplicación de .NET Core que usa el paquete AspNetCore tener TelemetryClient inyectado en ellos?
Sí, la configuración se comparte con el resto de la aplicación web.
¿Cómo puedo realizar un seguimiento de la telemetría que no se recopila automáticamente?
Obtenga una instancia de TelemetryClient
mediante inyección del constructor y llame al método TrackXXX()
necesario en ella. No se recomienda crear nuevas TelemetryClient
instancias. Una instancia singleton de TelemetryClient
ya está registrada en el contenedor DependencyInjection
, que comparte TelemetryConfiguration
con el resto de los datos de telemetría. Se recomienda crear una nueva instancia TelemetryClient
solo si se necesita una configuración independiente del resto de los datos de telemetría.
¿Puedo usar el IDE de Visual Studio para incorporar Application Insights a un proyecto de servicio de trabajo?
La incorporación del IDE de Visual Studio se admite actualmente solo para aplicaciones ASP.NET/ASP.NET Core. Este documento se actualizará cuando Visual Studio libere soporte para la incorporación de aplicaciones de Servicio de Trabajador.
¿Puedo habilitar la supervisión de Application Insights mediante herramientas como el agente de Application Insights para Azure Monitor (anteriormente, Monitor de estado v2)?
No. Actualmente, el agente de Azure Monitor Application Insights solo admite .NET.
¿Se admiten todas las características si ejecuto mi aplicación en Linux?
Sí. La compatibilidad de características para el SDK es la misma en todas las plataformas, con las siguientes excepciones:
Los contadores de rendimiento solo se admiten en Windows, con excepción de la CPU o memoria de procesos que se muestran en las métricas dinámicas.
Aunque el objeto
ServerTelemetryChannel
está habilitado de forma predeterminada, si la aplicación se ejecuta en Linux o macOS, el canal no crea automáticamente una carpeta de almacenamiento local para mantener los datos de telemetría temporalmente si hay problemas de red. Debido a esta limitación, la telemetría se pierde cuando hay problemas temporales de red o del servidor. Para solucionar este problema, configure una carpeta local para el canal:using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel; public void ConfigureServices(IServiceCollection services) { // The following will configure the channel to use the given folder to temporarily // store telemetry items during network or Application Insights server issues. // User should ensure that the given folder already exists // and that the application has read/write permissions. services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"}); services.AddApplicationInsightsTelemetryWorkerService(); }
¿Dónde puedo obtener más información sobre las aplicaciones de Worker Service?
Para obtener más información, consulte Application Insights for Worker Service applications (non-HTTP applications).