Application Insights pour les applications Service Worker (applications non HTTP)

Article
12/07/2024

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.

Attention

Nous recommandons la Distribution OpenTelemetry Azure Monitor pour les nouvelles applications ou les nouveaux clients afin d’alimenter Azure Monitor Application Insights. La distribution OpenTelemetry Azure Monitor offre une expérience et des fonctionnalités similaires à celles du Kit de développement logiciel (SDK) Application Insights. Il est possible de migrer depuis le Kit de développement logiciel (SDK) Application Insights en utilisant les guides de migration pour .NET, Node.js et Python, mais nous travaillons encore à l’ajout de quelques fonctionnalités supplémentaires pour la compatibilité descendante.

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 ou TelemetryClient à partir du conteneur Dependency Injection (DI) en appelant serviceProvider.GetRequiredService<TelemetryClient>(); ou en utilisant Constructor Injection. Cette étape déclenche la configuration de TelemetryConfiguration 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.

Téléchargez et installez le SDK .NET.
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éthode CreateHostBuilder() dans la classe Program.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 que appsettings.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éthode ConfigureServices(), 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, ont 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 auprès 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 Kit de développement logiciel (SDK) collecte automatiquement les données de télémétrie comme indiqué, 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.AddApplicationInsightsTelemetryWorkerService(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 DependencyInjectionet 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 est mis à jour quand Visual Studio prend en charge l’intégration d’applications de service de 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

Lisez et contribuez au code.

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.

Partager via