Application Insights pour les applications Service Worker (applications non HTTP)
Le nouveau kit de développement logiciel (SDK) Application Insights pour services Worker est le mieux adapté aux charges de travail non HTTP, telles que la messagerie, les tâches en arrière-plan et les applications console. Ces types d’applications n’ont pas la notion d’une requête HTTP entrante comme une application web traditionnelle ASP.NET/ASP.NET Core. Pour cette raison, l’utilisation de packages Application Insights pour les applications ASP.NET ou ASP.NET Core n’est pas prise en charge.
Remarque
La documentation suivante s’appuie sur l’API classique d’Application Insights. Le plan à long terme pour Application Insights est de collecter des données en utilisant OpenTelemetry. Pour plus d’informations, consultez Activer Azure Monitor OpenTelemetry pour les applications .NET, Node.js, Python et Java et notre feuille de route OpenTelemetry. L’aide sur la migration est disponible pour .NET, Node.js et Python.
Le nouveau SDK n’effectue pas de collecte de données de télémétrie par lui-même. Au lieu de cela, il intègre d’autres collecteurs automatiques Application Insights réputés, comme DependencyCollector, PerfCounterCollector, et ApplicationInsightsLoggingProvider. Ce kit de développement logiciel (SDK) expose des méthodes d’extension sur IServiceCollection
pour activer et configurer la collecte de données de télémétrie.
Scénarios pris en charge
Le SDK Application Insights pour Service Worker est particulièrement bien adapté aux applications non HTTP, peu importe où et comment elles s’exécutent. Si votre application est en cours d’exécution et dispose d’une connectivité réseau vers Azure, les données de télémétrie peuvent être collectées. La surveillance Application Insights est prise en charge partout où .NET Core est pris en charge. Ce package peut être utilisé dans le nouveau Service Worker .NET Core, les tâches en arrière-plan dans ASP.NET Core, les applications console comme .NET Core/ .NET Framework.
Prérequis
Vous devez disposer d’une chaîne de connexion Application Insights valide. Cette chaîne est requise pour envoyer les données de télémétrie à Application Insights. Si vous avez besoin créer une ressource Application Insights pour obtenir une chaîne de connexion, consultez Chaînes de connexion.
Remarque
Le support de l’ingestion de clé d’instrumentation prendra fin le 31 mars 2025. L’ingestion de clé d’instrumentation continuera de fonctionner, mais nous ne fournirons plus de mises à jour ni de support pour la fonctionnalité. Passez aux chaînes de connexion pour tirer parti des nouvelles fonctionnalités.
Utiliser le Kit de développement logiciel (SDK) Application Insights pour Worker Service
Installez le package Microsoft.ApplicationInsights.WorkerService dans l’application. L’extrait de code suivant montre les modifications qui doivent être ajoutées au fichier
.csproj
de votre projet :<ItemGroup> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> </ItemGroup>
Configurez la chaîne de connexion dans la variable d’environnement
APPLICATIONINSIGHTS_CONNECTION_STRING
ou dans la configuration(appsettings.json
).Récupérez une instance
ILogger
ouTelemetryClient
à partir du conteneur Dependency Injection (DI) en appelantserviceProvider.GetRequiredService<TelemetryClient>();
ou en utilisant Constructor Injection. Cette étape déclenchera la configuration deTelemetryConfiguration
et des modules de collecte automatique.
Les instructions spécifiques pour chaque type d’application sont décrites dans les sections suivantes.
Application de service Worker .NET Core
L’exemple complet est partagé sur le site web NuGet.
Créer un projet Service Worker à l’aide du nouveau modèle de projet ou de la ligne de commande Visual Studio
dotnet new worker
.Ajouter le package Microsoft.ApplicationInsights.WorkerService à l’application.
Ajoutez
services.AddApplicationInsightsTelemetryWorkerService();
à la méthodeCreateHostBuilder()
dans la classeProgram.cs
, comme dans cet exemple :public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureServices((hostContext, services) => { services.AddHostedService<Worker>(); services.AddApplicationInsightsTelemetryWorkerService(); });
Modifiez votre
Worker.cs
conformément à l’exemple suivant :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); } } }
Définissez la chaîne de connexion.
Notes
Nous vous recommandons de spécifier la chaîne de connexion dans la configuration. L’exemple de code suivant montre comment spécifier une chaîne de connexion dans
appsettings.json
. Assurez-vous queappsettings.json
est copié dans le dossier racine de l’application lors de la publication.{ "ApplicationInsights": { "ConnectionString" : "InstrumentationKey=00000000-0000-0000-0000-000000000000;" }, "Logging": { "LogLevel": { "Default": "Warning" } } }
Vous pouvez aussi spécifier la chaîne de connexion dans la variable d’environnement APPLICATIONINSIGHTS_CONNECTION_STRING
.
En règle générale, APPLICATIONINSIGHTS_CONNECTION_STRING
spécifie la chaîne de connexion pour les applications déployées sur Web Apps en tant que Tâches web.
Remarque
Une chaîne de connexion spécifiée dans le code est prioritaire sur la variable d’environnement APPLICATIONINSIGHTS_CONNECTION_STRING
, qui est prioritaire sur les autres options.
Tâches ASP.NET Core en arrière-plan avec services hébergés
Ce document décrit la façon de créer des tâches en arrière-plan dans une application ASP.NET Core.
L’exemple complet est partagé dans cette page GitHub.
Installez le package Microsoft.ApplicationInsights.WorkerService dans l’application.
Ajoutez
services.AddApplicationInsightsTelemetryWorkerService();
à la méthodeConfigureServices()
, comme dans cet exemple :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(); } }
Le code suivant est pour
TimedHostedService
, où réside la logique de tâche en arrière-plan :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"); } } }
Définissez la chaîne de connexion. Utilisez le même
appsettings.json
que le précédent exemple de service Worker .NET.
Application console .NET Core /. NET Framework
Comme indiqué au début de cet article, le nouveau package peut être utilisé pour activer Application Insights télémétrie à partir d’une application de console normale. Ce package cible netstandard2.0
et peut donc être utilisé pour les applications console dans .NET Core ou versions ultérieures, ainsi que .NET Framework ou versions ultérieures.
L’exemple complet est partagé dans cette page GitHub.
Installez le package Microsoft.ApplicationInsights.WorkerService dans l’application.
Modifiez Program.cs comme indiqué dans l’exemple suivant :
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(); } } }
Cette application console utilise également la même valeur par défaut TelemetryConfiguration
. Il peut être personnalisé de la même manière que les exemples des sections précédentes.
Exécuter votre application
Exécutez votre application. Les workers de tous les exemples précédents effectuent un appel HTTP toutes les secondes pour bing.com et émettent également quelques journaux à l’aide de ILogger
. Ces lignes sont encapsulées à l’intérieur de l’appel StartOperation
de TelemetryClient
, qui est utilisé pour créer une opération. Dans cet exemple, RequestTelemetry
est nommé « operation. »
Application Insights collecte ces journaux ILogger, avec une gravité d’Avertissement ou supérieure par défaut, et des dépendances. Elles sont corrélées à RequestTelemetry
avec une relation parent-enfant. La corrélation fonctionne également au-delà des limites du processus/du réseau. Par exemple, si l’appel a été effectué vers un autre composant surveillé, il est également corrélé à ce parent.
Cette opération personnalisée de RequestTelemetry
peut être considérée comme l’équivalent d’une requête web entrante dans une application web classique. Il n’est pas nécessaire d’utiliser une opération, mais elle s’adapte mieux au modèle de données de corrélation Application Insights. RequestTelemetry
fait office d’opération mère et chaque télémétrie générée dans l’itération du travailleur est traitée comme appartenant logiquement à la même opération.
Cette approche garantit également que toutes les données de télémétrie produites, à la fois automatiques et manuelles posséderont le même operation_id
. Comme l’échantillonnage est basé sur operation_id
, l’algorithme d’échantillonnage conserve ou supprime toutes les données de télémétrie d’une même itération.
Les sections suivantes répertorient les données de télémétrie complètes collectées automatiquement par Application Insights.
Métriques temps réel
Les métriques en direct peuvent être utilisées pour vérifier rapidement si la supervision de l’application avec Application Insights est correctement configurée. La télémétrie peut prendre quelques minutes pour s’afficher dans le Portail Azure, mais le volet des métriques en direct affiche l’utilisation du processeur pour les processus en cours d’exécution en quasi-temps réel. Elle peut également afficher d’autres données de télémétrie comme les requêtes, les dépendances et les traces.
Journaux ILogger
Les journaux émis via ILogger
avec la gravité Avertissement ou supérieur sont automatiquement capturés. Pour modifier ce comportement, remplacez explicitement la configuration de la journalisation pour le fournisseur ApplicationInsights
(comme indiqué dans le code suivant). La configuration suivante permet à Application Insights de capturer tous les journaux Information
et ceux de gravité supérieure.
{
"Logging": {
"LogLevel": {
"Default": "Warning"
},
"ApplicationInsights": {
"LogLevel": {
"Default": "Information"
}
}
}
}
Il est important de noter que l’exemple suivant ne permet pas au fournisseur Application Insights de capturer les journaux Information
. Il ne la capture pas, car le kit de développement logiciel (SDK) ajoute un filtre de journalisation par défaut qui indique à ApplicationInsights
de capturer uniquement les journaux Warning
de gravité supérieure. Application Insights nécessite un remplacement explicite.
{
"Logging": {
"LogLevel": {
"Default": "Information"
}
}
}
Pour plus d’informations, suivez la documentation ILogger pour personnaliser les niveaux de journalisation capturés par Application Insights.
Les dépendances
La collecte des dépendances est activée par défaut. L’article Suivi des dépendances dans Application Insights explique les dépendances qui sont collectées automatiquement et contient également les étapes à suivre manuellement.
EventCounter
EventCounterCollectionModule
est activé par défaut et il collecte un ensemble de compteurs par défaut à partir des applications .NET. Le didacticiel EventCounter répertorie l'ensemble par défaut de compteurs collectés. Il contient également des instructions sur la façon de personnaliser la liste.
Suivi manuel d’autres données de télémétrie
Bien que le SDK collecte automatiquement la télémétrie comme expliqué, dans la plupart des cas, vous devez envoyer d’autres données de télémétrie à Application Insights. La méthode recommandée pour le suivi d’autres données de télémétrie consiste à obtenir une instance de TelemetryClient
auprès de l’injection de dépendance, puis à appeler une des méthodes de TrackXXX()
l’API prises en charge sur cette instance. Le suivi personnalisé des opérations est un autre cas d’utilisation classique de cette approche. Cette approche est illustrée dans les exemples de travail précédents.
Configurer le SDK Application Insights
La valeur par défaut TelemetryConfiguration
utilisée par le kit de développement logiciel (SDK) du service Worker est similaire à la configuration automatique utilisée dans une application ASP.NET ou ASP.NET Core, moins les initialiseurs télémétrie utilisés pour enrichir les données de télémétrie de HttpContext
.
Vous pouvez personnaliser le SDK Application Insights pour Service Worker afin de modifier la configuration par défaut. Les utilisateurs du SDK Application Insights ASP.NET Core peuvent maîtriser la modification de configuration à l’aide de l’injection de dépendances intégrée à ASP.NET Core. Le kit de développement logiciel (SDK) Worker Service est également basé sur des principes similaires. Effectuez pratiquement toutes les modifications de configuration dans la section ConfigureServices()
en appelant les méthodes appropriées sur IServiceCollection
, comme indiqué dans la section suivante.
Notes
Quand vous utilisez ce kit de développement logiciel (SDK), il n’est pas possible de modifier la configuration à l’aide de TelemetryConfiguration.Active
, et les modifications réalisées par ce biais ne sont pas répercutées.
Utiliser ApplicationInsightsServiceOptions
Vous pouvez modifier quelques paramètres courants en passant de ApplicationInsightsServiceOptions
à AddApplicationInsightsTelemetryWorkerService
, comme dans cet exemple :
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);
}
ApplicationInsightsServiceOptions
dans ce SDK se trouve dans l’espace de noms Microsoft.ApplicationInsights.WorkerService
au lieu de Microsoft.ApplicationInsights.AspNetCore.Extensions
dans le SDK ASP.NET Core.
Le tableau suivant répertorie les méthodes fréquemment utilisées dans ApplicationInsightsServiceOptions
.
Paramètre | Description | Default |
---|---|---|
EnableQuickPulseMetricStream | Activez/désactivez la fonctionnalité métriques en direct. | True |
EnableAdaptiveSampling | Active/désactive l’échantillonnage adaptatif. | True |
EnableHeartbeat | Activez/désactivez la fonction Heartbeats, qui envoie périodiquement (15 minutes par défaut) une mesure personnalisée appelée « HeartBeatState » avec des informations sur le temps d'exécution comme la version .NET et l’environnement Azure, le cas échéant. | True |
AddAutoCollectedMetricExtractor | Active/désactive l’extracteur AutoCollectedMetrics qui est un processeur de télémétrie envoyant des métriques pré-agrégées sur les demandes/dépendances avant l’échantillonnage. | True |
EnableDiagnosticsTelemetryModule | Active/désactive DiagnosticsTelemetryModule . La désactivation de ce paramètre fait que les paramètres suivants sont ignorés : EnableHeartbeat , EnableAzureInstanceMetadataTelemetryModule et EnableAppServicesHeartbeatTelemetryModule . |
True |
Pour obtenir la liste la plus récente, consultez les paramètres configurables dans ApplicationInsightsServiceOptions
.
échantillonnage
Le kit SDK Application Insights pour Service Worker prend en charge l’échantillonnage à taux fixe et l’échantillonnage adaptatif. L’échantillonnage adaptatif est activé par défaut. L’échantillonnage peut être désactivé à l’aide de l’option EnableAdaptiveSampling
qui se trouve dans ApplicationInsightsServiceOptions.
Pour configurer d’autres paramètres d’échantillonnage, vous pouvez utiliser l’exemple suivant :
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.AddApplicationInsightsTelemetry(new ApplicationInsightsServiceOptions
{
EnableAdaptiveSampling = false,
});
var app = builder.Build();
Pour plus d’informations, consultez la documentation Échantillonnage.
Ajouter Initialiseurs de télémétrie
Utilisez des initialiseurs de télémétrie lorsque vous souhaitez définir des propriétés qui sont envoyées avec toutes les données de télémétrie.
Ajoutez tout nouvel initialisateur de télémétrie au conteneur DependencyInjection
et le SDK les ajoute automatiquement à TelemetryConfiguration
.
using Microsoft.ApplicationInsights.Extensibility;
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
services.AddApplicationInsightsTelemetryWorkerService();
}
Supprimer initialiseurs de télémétrie
Les initialiseurs de télémétrie sont présents par défaut. Pour supprimer tout ou partie des initialiseurs de télémétrie, utilisez l’exemple de code suivant après avoir appelé 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));
}
Ajouter processeurs de télémétrie
Vous pouvez ajouter des processeurs de télémétrie personnalisés à TelemetryConfiguration
à l’aide de la méthode d’extension AddApplicationInsightsTelemetryProcessor
sur IServiceCollection
. Vous utilisez des processeurs de télémétrie dans des scénarios de filtrage avancés pour permettre un contrôle plus direct sur les informations contenues ou non dans le données de télémétrie que vous envoyez à Application Insights. Consultez l’exemple qui suit :
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetryWorkerService();
services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();
// If you have more processors:
services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();
}
Configurer ou supprimer les modules de télémétrie par défaut
Application Insights utilise les modules de télémétrie pour collecter automatiquement des informations de télémétrie sur des charges de travail spécifiques sans qu’un suivi manuel ne soit nécessaire.
Les modules de collecte automatique suivants sont activés par défaut. Ces modules sont chargés de collecter automatiquement les données de télémétrie. Vous pouvez les désactiver ou les configurer pour modifier leur comportement par défaut.
DependencyTrackingTelemetryModule
PerformanceCollectorModule
QuickPulseTelemetryModule
AppServicesHeartbeatTelemetryModule
(Il existe actuellement un problème impliquant ce module de télémétrie. Pour obtenir une solution de contournement temporaire, consultez Problème GitHub 1689.)AzureInstanceMetadataTelemetryModule
Pour configurer tout module de télémétrie par défaut, utilisez la méthode d’extension ConfigureTelemetryModule<T>
sur IServiceCollection
, comme illustré dans l’exemple suivant :
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);
}
}
Configurer le canal de télémétrie
Le canal par défaut est ServerTelemetryChannel
. Vous pouvez le remplacer, comme le montre l’exemple suivant :
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();
}
Désactiver la télémétrie dynamiquement
Si vous souhaitez désactiver la télémétrie de manière conditionnelle et dynamique, vous pouvez résoudre l’instance TelemetryConfiguration
avec un conteneur d’injection de dépendance ASP.NET n’importe où dans votre code et définir l’indicateur DisableTelemetry
sur celle-ci.
public void ConfigureServices(IServiceCollection services)
{
services.AddApplicationInsightsTelemetryWorkerService();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration configuration)
{
configuration.DisableTelemetry = true;
...
}
Forum aux questions
Cette section fournit des réponses aux questions fréquentes.
Quel package utiliser ?
Scénario d’application .Net Core | Paquet |
---|---|
Sans HostedServices | WorkerService |
Avec HostedServices | AspNetCore (non WorkerService) |
Avec HostedServices, monitoring de hostedServices uniquement | WorkerService (scénario rare) |
TelemetryClient peut-il être ajouté à HostedServices dans une application .NET Core à l’aide du package AspNetCore ?
Oui. La configuration sera partagée avec le reste de l’application web.
Comment puis-je suivre les données de télémétrie qui ne sont pas automatiquement collectées ?
Obtenez une instance de TelemetryClient
à l’aide de l’injection de constructeur et appelez la méthode TrackXXX()
requise dessus. Nous vous déconseillons de créer de nouvelles instances TelemetryClient
. Une instance singleton de TelemetryClient
est déjà inscrite dans le conteneur DependencyInjection
, qui partage TelemetryConfiguration
avec le reste de la télémétrie. La création d’une instance TelemetryClient
est recommandée uniquement si celle-ci a besoin d’une configuration distincte du reste de la télémétrie.
Puis-je utiliser l’IDE de Visual Studio pour intégrer Application Insights à un projet de service Worker ?
L’intégration de l’IDE Visual Studio est actuellement prise en charge uniquement pour les applications ASP.NET/ASP.NET Core. Ce document sera mis à jour lorsque Visual Studio prendra en charge l’intégration d’applications de service Worker.
Puis-je activer la supervision d’Application Insights à l’aide d’outils tels qu’Azure Monitor Agent Application Insights (anciennement Status Monitor v2) ?
Non. Agent Azure Monitor Application Insights prend uniquement en charge .NET actuellement.
Si j’exécute mon application sous Linux, toutes les fonctionnalités sont-elles prises en charge ?
Oui. La prise en charge de fonctionnalités pour ce SDK est la même sur toutes les plateformes, avec les exceptions suivantes :
Les compteurs de performance sont pris en charge seulement sous Windows, à l’exception de l’utilisation du processeur/de la mémoire de processus qui apparaît dans les métriques en direct.
Même si
ServerTelemetryChannel
est activé par défaut, si l’application est exécutée sous Linux ou macOS, le canal ne crée pas automatiquement un dossier de stockage local pour conserver temporairement les données de télémétrie s’il existe des problèmes de réseau. En raison de cette limitation, les données de télémétrie sont perdues en cas de problèmes temporaires de réseau ou de serveur. Pour contourner ce problème, configurez un dossier local pour le 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(); }
Exemples d'applications
Application console .NET Core Choisissez cet exemple si vous utilisez une application console écrite en .NET Core (version 2.0 ou ultérieure) ou .NET Framework (version 4.7.2 ou ultérieure).
Tâches en arrière-plan ASP.NET Core avec HostedServices Choisissez cet exemple si vous utilisez ASP.NET Core et créez des tâches en arrière-plan conformément aux instructions officielles.
Service Worker .NET Core : Utilisez cet exemple si vous disposez d’une application Service Worker .NET conformément aux instructions officielles.
Kit de développement logiciel (SDK) open source
Pour obtenir les mises à jour et correctifs de bogues les plus récents, consultez les notes de publication.
Étapes suivantes
- Utilisez l’API pour envoyer vos propres événements et mesures pour obtenir une vue détaillée des performances et de l’utilisation de votre application.
- Suivre les dépendances supplémentaires non suivies automatiquement.
- Enrichir ou filtrer les données de télémétrie collectées automatiquement.
- Injection de dépendances dans ASP.NET Core.