Eventos
Compilación de Intelligent Apps
17 mar, 21 - 21 mar, 10
Únase a la serie de reuniones para crear soluciones de inteligencia artificial escalables basadas en casos de uso reales con compañeros desarrolladores y expertos.
Regístrese ahoraEste explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
El SDK de Application Insights para el servicio Worker es un nuevo SDK que es más adecuado para realizar cargas de trabajo que no son HTTP, como mensajería, tareas en segundo plano y aplicaciones de consola. Este tipo de aplicaciones no tienen la noción de una solicitud HTTP entrante como una aplicación web ASP.NET/ASP.NET Core tradicional. Por este motivo, no se admite el uso de paquetes de Application Insights para aplicaciones ASP.NET o ASP.NET Core.
Precaución
Se recomienda la Distribución de OpenTelemetry de Azure Monitor para nuevas aplicaciones o clientes para potenciar Application Insights de Azure Monitor. La Distribución de OpenTelemetry de Azure Monitor ofrece una funcionalidad y experiencia similares al SDK de Application Insights. Es posible migrar desde el SDK de Application Insights usando las guías de migración para .NET, Node.js, y Python, pero todavía estamos trabajando para agregar unas pocas características más para la compatibilidad con versiones anteriores.
El nuevo SDK no recopila telemetría por sí mismo. En su lugar, ofrece en otros recopiladores automáticos de Application Insights conocidos, como DependencyCollector, PerfCounterCollector y ApplicationInsightsLoggingProvider. Este SDK expone métodos de extensión en IServiceCollection
para habilitar y configurar la recopilación de telemetría.
El SDK de Application Insights para el servicio de trabajo es más adecuado para aplicaciones sin HTTP, independientemente de dónde y cómo se ejecuten. Si la aplicación se está ejecutando y tiene conectividad de red a Azure, se pueden recopilar datos de telemetría. La supervisión de Application Insights se admite siempre y cuando .NET Core sea compatible. Este paquete se puede usar en el recién incorporado servicio Worker de .NET Core, en las tareas en segundo plano de ASP.NET Core y aplicaciones de consola como .NET Core/.NET Framework).
Debe tener una cadena de conexión de Application Insights válida. Esta cadena es necesaria para enviar los datos de telemetría a Application Insights. Si necesita crear un nuevo recurso de Application Insights para obtener un cadena de conexión, consulte Cadenas de conexión.
Nota
El 31 de marzo de 2025 finalizará la compatibilidad con la ingesta de claves de instrumentación. La ingesta de claves de instrumentación seguirá funcionando, pero la característica ya no recibirá actualizaciones ni soporte técnico. Transición a las cadenas de conexión para aprovechar las nuevas funcionalidades.
Instale el paquete Microsoft.ApplicationInsights.WorkerService en la aplicación.
En el siguiente fragmento de código se muestran los cambios que se agregarán al archivo .csproj
del proyecto:
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
</ItemGroup>
Configure la cadena de conexión en la APPLICATIONINSIGHTS_CONNECTION_STRING
variable de entorno o en la configuración (appsettings.json
).
Recupere una instancia de ILogger
o de TelemetryClient
del contenedor de inserción de dependencias (DI) mediante una llamada a serviceProvider.GetRequiredService<TelemetryClient>();
o mediante la inserción de constructores. Esta etapa establece la configuración de TelemetryConfiguration
y los módulos de recopilación automática.
Las instrucciones concretas para cada tipo de aplicación se indican en las secciones siguientes.
El ejemplo completo se comparte en el sitio web de NuGet.
Cree un proyecto de servicio Worker mediante la nueva plantilla de proyecto de Visual Studio o la línea de comandos dotnet new worker
.
Añada el paquete Microsoft.ApplicationInsights.WorkerService a la aplicación.
Agregue services.AddApplicationInsightsTelemetryWorkerService();
al método CreateHostBuilder()
en su clase Program.cs
, como en este ejemplo:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<Worker>();
services.AddApplicationInsightsTelemetryWorkerService();
});
Modifique su Worker.cs
según el ejemplo siguiente:
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
public class Worker : BackgroundService
{
private readonly ILogger<Worker> _logger;
private TelemetryClient _telemetryClient;
private static HttpClient _httpClient = new HttpClient();
public Worker(ILogger<Worker> logger, TelemetryClient tc)
{
_logger = logger;
_telemetryClient = tc;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
using (_telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
_logger.LogWarning("A sample warning message. By default, logs with severity Warning or higher is captured by Application Insights");
_logger.LogInformation("Calling bing.com");
var res = await _httpClient.GetAsync("https://bing.com");
_logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
_telemetryClient.TrackEvent("Bing call event completed");
}
await Task.Delay(1000, stoppingToken);
}
}
}
Configure la cadena de conexión.
Nota
Se recomienda especificar la cadena de conexión en la configuración. En el siguiente ejemplo de código se muestra cómo especificar una cadena de conexión en appsettings.json
. Asegúrese de que appsettings.json
se copia en la carpeta raíz de la aplicación durante la publicación.
{
"ApplicationInsights":
{
"ConnectionString" : "InstrumentationKey=00000000-0000-0000-0000-000000000000;"
},
"Logging":
{
"LogLevel":
{
"Default": "Warning"
}
}
}
De manera alternativa, puede configurar la cadena de conexión en la APPLICATIONINSIGHTS_CONNECTION_STRING
variable de entorno.
Por lo general, APPLICATIONINSIGHTS_CONNECTION_STRING
especifica la cadena de conexión para las aplicaciones implementadas en Web Apps como trabajos web.
Nota
Una cadena de conexión especificada en el código tiene prioridad sobre la variable de entorno APPLICATIONINSIGHTS_CONNECTION_STRING
, que tiene prioridad sobre otras opciones.
En este documento, se describe cómo crear tareas en segundo plano en una aplicación ASP.NET Core.
El ejemplo completo se comparte en esta página de GitHub.
Instale el paquete Microsoft.ApplicationInsights.WorkerService en la aplicación.
Agregue services.AddApplicationInsightsTelemetryWorkerService();
al método ConfigureServices()
, como en este ejemplo:
public static async Task Main(string[] args)
{
var host = new HostBuilder()
.ConfigureAppConfiguration((hostContext, config) =>
{
config.AddJsonFile("appsettings.json", optional: true);
})
.ConfigureServices((hostContext, services) =>
{
services.AddLogging();
services.AddHostedService<TimedHostedService>();
// connection string is read automatically from appsettings.json
services.AddApplicationInsightsTelemetryWorkerService();
})
.UseConsoleLifetime()
.Build();
using (host)
{
// Start the host
await host.StartAsync();
// Wait for the host to shutdown
await host.WaitForShutdownAsync();
}
}
A continuación se encuentra el código para TimedHostedService
, donde reside la lógica de la tarea en segundo plano:
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
public class TimedHostedService : IHostedService, IDisposable
{
private readonly ILogger _logger;
private Timer _timer;
private TelemetryClient _telemetryClient;
private static HttpClient httpClient = new HttpClient();
public TimedHostedService(ILogger<TimedHostedService> logger, TelemetryClient tc)
{
_logger = logger;
this._telemetryClient = tc;
}
public Task StartAsync(CancellationToken cancellationToken)
{
_logger.LogInformation("Timed Background Service is starting.");
_timer = new Timer(DoWork, null, TimeSpan.Zero,
TimeSpan.FromSeconds(1));
return Task.CompletedTask;
}
private void DoWork(object state)
{
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
using (_telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
_logger.LogWarning("A sample warning message. By default, logs with severity Warning or higher is captured by Application Insights");
_logger.LogInformation("Calling bing.com");
var res = httpClient.GetAsync("https://bing.com").GetAwaiter().GetResult();
_logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
_telemetryClient.TrackEvent("Bing call event completed");
}
}
}
Configure la cadena de conexión.
Use el mismo appsettings.json
del ejemplo anterior del servicio de trabajo .NET.
Como se mencionó al principio de este artículo, el nuevo paquete se puede usar para habilitar la telemetría de Application Insights, incluso desde una aplicación de consola normal. Este paquete es para netstandard2.0
, por lo que se puede usar para aplicaciones de consola en .NET Core o una versión superior, y en .NET Framework o una versión superior.
El ejemplo completo se comparte en esta página de GitHub.
Instale el paquete Microsoft.ApplicationInsights.WorkerService en la aplicación.
Modifique Program.cs como se muestra en el ejemplo siguiente:
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.WorkerService;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using System;
using System.Net.Http;
using System.Threading.Tasks;
namespace WorkerSDKOnConsole
{
class Program
{
static async Task Main(string[] args)
{
// Create the DI container.
IServiceCollection services = new ServiceCollection();
// Being a regular console app, there is no appsettings.json or configuration providers enabled by default.
// Hence instrumentation key/ connection string and any changes to default logging level must be specified here.
services.AddLogging(loggingBuilder => loggingBuilder.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>("Category", LogLevel.Information));
services.AddApplicationInsightsTelemetryWorkerService((ApplicationInsightsServiceOptions options) => options.ConnectionString = "InstrumentationKey=<instrumentation key here>");
// To pass a connection string
// - aiserviceoptions must be created
// - set connectionstring on it
// - pass it to AddApplicationInsightsTelemetryWorkerService()
// Build ServiceProvider.
IServiceProvider serviceProvider = services.BuildServiceProvider();
// Obtain logger instance from DI.
ILogger<Program> logger = serviceProvider.GetRequiredService<ILogger<Program>>();
// Obtain TelemetryClient instance from DI, for additional manual tracking or to flush.
var telemetryClient = serviceProvider.GetRequiredService<TelemetryClient>();
var httpClient = new HttpClient();
while (true) // This app runs indefinitely. Replace with actual application termination logic.
{
logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
// Replace with a name which makes sense for this operation.
using (telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
logger.LogWarning("A sample warning message. By default, logs with severity Warning or higher is captured by Application Insights");
logger.LogInformation("Calling bing.com");
var res = await httpClient.GetAsync("https://bing.com");
logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
telemetryClient.TrackEvent("Bing call event completed");
}
await Task.Delay(1000);
}
// Explicitly call Flush() followed by sleep is required in console apps.
// This is to ensure that even if application terminates, telemetry is sent to the back-end.
telemetryClient.Flush();
Task.Delay(5000).Wait();
}
}
}
Esta aplicación de consola también usa el mismo valor predeterminado TelemetryConfiguration
. Se puede personalizar de la misma manera que los ejemplos de secciones anteriores.
Ejecute la aplicación. Los trabajos de todos los ejemplos anteriores realizan una llamada HTTP cada segundo a bing.com y también emiten algunos registros mediante ILogger
. Estas líneas se incluyen dentro de la llamada StartOperation
de TelemetryClient
, que se usa para crear una operación. En este ejemplo, RequestTelemetry
se denomina "operation".
Application Insights recopila estos registros de ILogger, con una gravedad de Advertencia o superior de forma predeterminada, y las dependencias. Se correlacionan con RequestTelemetry
con una relación de elementos primarios y secundarios. La correlación también funciona a través de límites de proceso/red. Por ejemplo, si la llamada se realizó a otro componente supervisado, se correlacionará también con este elemento primario.
Esta operación personalizada de RequestTelemetry
puede considerarse como el equivalente de una solicitud web de entrada en una aplicación web típica. No es necesario usar una operación, pero se adapta mejor al modelo de datos de correlación de Application Insights.
RequestTelemetry
actúa como la operación primaria y cada telemetría generada dentro de la iteración del trabajo es tratada como lógicamente perteneciente a la misma operación.
Este enfoque también garantiza que toda la telemetría generada (automática y manual) tendrá el mismo operation_id
. Dado que el muestreo se basa en operation_id
, el algoritmo de muestreo mantiene o quita toda la telemetría de una sola iteración.
En las siguientes secciones se enumera toda la telemetría que Application Insights recopila automáticamente.
Live metrics se puede usar para comprobar rápidamente si la supervisión de aplicaciones con Application Insights está configurada correctamente. La telemetría puede tardar unos minutos en aparecer en Azure Portal, pero el panel de métricas dinámicas muestra el uso de CPU del proceso en ejecución casi en tiempo real. También puede mostrar otros tipos de telemetría, como las solicitudes, las dependencias y los seguimientos.
Los registros emitidos a través de ILogger
con la gravedad Advertencia o superior se capturan automáticamente. Para cambiar este comportamiento,es preciso debe invalidar explícitamente la configuración de registro del proveedor ApplicationInsights
, como se muestra en el código siguiente. La siguiente configuración permite que Application Insights capture todos los registros Information
y los registros más graves.
{
"Logging": {
"LogLevel": {
"Default": "Warning"
},
"ApplicationInsights": {
"LogLevel": {
"Default": "Information"
}
}
}
}
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 obtener más información, siga la documentación de ILogger a fin de personalizar los niveles de registro que captura Application Insights.
La recopilación de dependencias está habilitada de manera predeterminada. En el artículo Seguimiento de dependencias en Application Insights se explican las dependencias que se recopilan automáticamente y que también contienen pasos para realizar el seguimiento manual.
EventCounterCollectionModule
está habilitado de forma predeterminada y recopila un conjunto predeterminado de contadores de las aplicaciones de .NET. En el tutorial de EventCounter se muestra el conjunto de contadores recopilado de manera predeterminada. También tiene instrucciones sobre cómo personalizar la lista.
Aunque el SDK recopila automáticamente la telemetría tal y como se explica, en la mayoría de los casos debe enviar telemetría adicional a Application Insights. La manera recomendada de realizar el seguimiento de esta telemetría adicional consiste en obtener una instancia de TelemetryClient
a partir de la inserción de dependencias y llamar después a uno de los métodos TrackXXX()
de la API admitidos. Otro caso de uso típico es el seguimiento personalizado de las operaciones. Este enfoque se muestra en los ejemplos de trabajo anteriores.
El TelemetryConfiguration
predeterminado que usa el SDK del servicio Worker es similar a la configuración automática que se usa en una aplicación ASP.NET o ASP.NET Core, menos los enriquecedores de telemetría que sirven para enriquecer la telemetría de HttpContext
.
Puede personalizar el SDK de Application Insights para el servicio de trabajo para cambiar la configuración predeterminada. Es posible que los usuarios de los SDK de Application Insights para ASP.NET estén familiarizados con el cambio de configuración mediante el uso de la inserción de dependencias incorporada de ASP.NET Core. El SDK del servicio Worker también se basa en principios similares. Realice casi todos los cambios de configuración en la sección ConfigureServices()
mediante una llamada a los métodos adecuados en IServiceCollection
, tal como se detalla en la siguiente sección.
Nota
Al usar este SDK, no se admite el cambio de la configuración mediante la modificación de TelemetryConfiguration.Active
y los cambios no se reflejan.
Puede modificar algunos ajustes de configuración comunes pasando de ApplicationInsightsServiceOptions
a AddApplicationInsightsTelemetryWorkerService
, como se muestra en este ejemplo:
using Microsoft.ApplicationInsights.WorkerService;
public void ConfigureServices(IServiceCollection services)
{
var aiOptions = new ApplicationInsightsServiceOptions();
// Disables adaptive sampling.
aiOptions.EnableAdaptiveSampling = false;
// Disables live metrics (also known as QuickPulse).
aiOptions.EnableQuickPulseMetricStream = false;
services.AddApplicationInsightsTelemetryWorkerService(aiOptions);
}
El ApplicationInsightsServiceOptions
en este SDK está en el espacio de nombres Microsoft.ApplicationInsights.WorkerService
en lugar de en Microsoft.ApplicationInsights.AspNetCore.Extensions
el SDK de ASP.NET Core.
En la tabla siguiente, se presentan los ajustes más utilizados en ApplicationInsightsServiceOptions
.
Configuración | Descripción | Valor predeterminado |
---|---|---|
EnableQuickPulseMetricStream | Habilitar o deshabilitar la característica de métricas dinámicas. | Verdadero |
EnableAdaptiveSampling | Habilitar o deshabilitar el muestreo adaptable. | Verdadero |
EnableHeartbeat | Habilitar o deshabilitar la característica de latidos, que envía periódicamente (cada 15 minutos de forma predeterminada) una métrica personalizada denominada "HeartBeatState" con información sobre el runtime, como la versión de .NET y el entorno de Azure, si procede. | Verdadero |
AddAutoCollectedMetricExtractor | Habilitar o deshabilitar el extractor de AutoCollectedMetrics, que es un procesador de telemetría que envía métricas previamente agregadas sobre las solicitudes o dependencias antes de que tenga lugar el muestreo. | True |
EnableDiagnosticsTelemetryModule | Habilitar o deshabilitar DiagnosticsTelemetryModule . Si se deshabilita, se omitirá la siguiente configuración: EnableHeartbeat , EnableAzureInstanceMetadataTelemetryModule y EnableAppServicesHeartbeatTelemetryModule . |
True |
Consulte los valores configurables en ApplicationInsightsServiceOptions
para obtener la lista más actualizada.
El SDK de Application Insights para el servicio de trabajo admite el muestreo de tipo fijo y el muestreo adaptable. El muestreo adaptable está habilitado de forma predeterminada. El muestreo se puede deshabilitar mediante la opción EnableAdaptiveSampling
en ApplicationInsightsServiceOptions.
Para configurar otras opciones de muestreo, puede usar el siguiente ejemplo:
using Microsoft.ApplicationInsights.AspNetCore.Extensions;
using Microsoft.ApplicationInsights.Extensibility;
var builder = WebApplication.CreateBuilder(args);
builder.Services.Configure<TelemetryConfiguration>(telemetryConfiguration =>
{
var telemetryProcessorChainBuilder = telemetryConfiguration.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
// Using adaptive sampling
telemetryProcessorChainBuilder.UseAdaptiveSampling(maxTelemetryItemsPerSecond: 5);
// Alternately, the following configures adaptive sampling with 5 items per second, and also excludes DependencyTelemetry from being subject to sampling:
// telemetryProcessorChainBuilder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5, excludedTypes: "Dependency");
});
builder.Services.AddApplicationInsightsTelemetryWorkerService(new ApplicationInsightsServiceOptions
{
EnableAdaptiveSampling = false,
});
var app = builder.Build();
Para obtener más información, consulte la documentación de Muestreo.
Use inicializadores de telemetría cuando quiera definir propiedades para que se envíen con toda la telemetría.
Añada cualquier inicializador nuevo de telemetría al contenedor DependencyInjection
y el SDK los añadirá automáticamente a TelemetryConfiguration
.
using Microsoft.ApplicationInsights.Extensibility;
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
services.AddApplicationInsightsTelemetryWorkerService();
}
Los inicializadores de telemetría están presentes de forma predeterminada. Para quitar todos los inicializadores de telemetría o solo algunos específicos, use el siguiente código de ejemplo después de llamar a AddApplicationInsightsTelemetryWorkerService()
.
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetryWorkerService();
// Remove a specific built-in telemetry initializer.
var tiToRemove = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(AspNetCoreEnvironmentTelemetryInitializer));
if (tiToRemove != null)
{
services.Remove(tiToRemove);
}
// Remove all initializers.
// This requires importing namespace by using Microsoft.Extensions.DependencyInjection.Extensions;
services.RemoveAll(typeof(ITelemetryInitializer));
}
Puede agregar procesadores de telemetría personalizados a TelemetryConfiguration
mediante el método de extensión AddApplicationInsightsTelemetryProcessor
en IServiceCollection
. Puede usar los procesadores de telemetría en escenarios de filtrado avanzado para permitir un control más directo sobre lo que se incluirá o excluirá de la telemetría que envía a Application Insights. Utilice el ejemplo siguiente:
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetryWorkerService();
services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();
// If you have more processors:
services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();
}
Application Insights usa módulos de telemetría para recopilar automáticamente información de telemetría sobre cargas de trabajo específicas sin necesidad de seguimiento manual.
Los siguientes módulos de recopilación automática están habilitados de forma predeterminada. Estos módulos son responsables de recopilar automáticamente datos de telemetría. Puede deshabilitarlos o configurarlos para modificar su comportamiento predeterminado.
DependencyTrackingTelemetryModule
PerformanceCollectorModule
QuickPulseTelemetryModule
AppServicesHeartbeatTelemetryModule
(Actualmente hay un problema relacionado con este módulo de telemetría. Para obtener una solución temporal, consulte Problema de GitHub n.º 1689.)AzureInstanceMetadataTelemetryModule
Para configurar cualquier módulo de telemetría predeterminado, use el método de extensión ConfigureTelemetryModule<T>
en IServiceCollection
, como se muestra en el ejemplo siguiente:
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector;
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetryWorkerService();
// The following configures QuickPulseTelemetryModule.
// Similarly, any other default modules can be configured.
services.ConfigureTelemetryModule<QuickPulseTelemetryModule>((module, o) =>
{
module.AuthenticationApiKey = "keyhere";
});
// The following removes PerformanceCollectorModule to disable perf-counter collection.
// Similarly, any other default modules can be removed.
var performanceCounterService = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
services.Remove(performanceCounterService);
}
}
El canal predeterminado es ServerTelemetryChannel
. Puede invalidarlo tal como se muestra en el ejemplo siguiente:
using Microsoft.ApplicationInsights.Channel;
public void ConfigureServices(IServiceCollection services)
{
// Use the following to replace the default channel with InMemoryChannel.
// This can also be applied to ServerTelemetryChannel.
services.AddSingleton(typeof(ITelemetryChannel), new InMemoryChannel() {MaxTelemetryBufferCapacity = 19898 });
services.AddApplicationInsightsTelemetryWorkerService();
}
Si desea deshabilitar la telemetría condicional y dinámicamente, puede resolver la instancia TelemetryConfiguration
con el contenedor de inyección de dependencias de ASP.NET Core en cualquier parte del código y establecer DisableTelemetry
como marca.
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetryWorkerService();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration configuration)
{
configuration.DisableTelemetry = true;
...
}
Esta sección proporciona respuestas a preguntas comunes.
Escenario de aplicación de .NET Core | Paquete |
---|---|
Sin HostedServices | WorkerService |
With HostedServices | AspNetCore (no WorkerService) |
Con HostedServices, con supervisión solo de HostedServices | WorkerService (escenario poco frecuente) |
Sí, la configuración se comparte con el resto de la aplicación web.
Obtenga una instancia de TelemetryClient
mediante el uso de la inserción del constructor y llame al método TrackXXX()
necesario que incluye. No se recomienda crear instancias de TelemetryClient
. 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.
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 ofrezca compatibilidad con las aplicaciones de servicio de trabajo de incorporación.
No. Actualmente, el agente de Azure Monitor Application Insights solo admite .NET.
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();
}
Aplicación de consola .NET Core: use este ejemplo si va a utilizar una aplicación de consola escrita en .NET Core (versión 2.0 o posterior) o .NET Framework (versión 4.7.2 o posterior).
Tareas en segundo plano de ASP.NET Core con HostedServices: use este ejemplo si está en ASP.NET Core y está creando tareas en segundo plano según la guía oficial.
Servicio Worker de .NET Core: use este ejemplo si tiene una aplicación del servicio Worker de .NET conforme a la guía oficial.
Lectura y contribución al código.
Para obtener las actualizaciones y correcciones de errores más recientes, vea las notas de la versión.
Eventos
Compilación de Intelligent Apps
17 mar, 21 - 21 mar, 10
Únase a la serie de reuniones para crear soluciones de inteligencia artificial escalables basadas en casos de uso reales con compañeros desarrolladores y expertos.
Regístrese ahoraCursos
Módulo
Uso de la telemetría en un proyecto de .NET Aspire - Training
En este módulo, obtendrá información sobre el uso de la telemetría para registrar el comportamiento de una aplicación nativa de nube y cómo la pila Aspire de .NET facilita el almacenamiento de datos y su posterior visualización.
Certificación
Microsoft Certified: Azure Developer Associate - Certifications
Cree soluciones de un extremo a otro en Microsoft Azure para crear Azure Functions, implementar y administrar aplicaciones web, desarrollar soluciones que usen Azure Storage, etc.
Documentación
Registro de Application Insights con .NET - Azure Monitor
Aprenda a usar Application Insights con la interfaz ILogger en .NET.
Application Insights para aplicaciones de ASP.NET Core - Azure Monitor
Supervise la disponibilidad, el rendimiento y el uso de las aplicaciones web de ASP.NET Core.
Exploración de registros de seguimiento de .NET en Application Insights - Azure Monitor
Busque registros generados por Seguimiento, NLog o Log4Net.