Live Metrics : Superviser et diagnostiquer avec une latence de 1 seconde

Supervisez votre application web dynamique en production en utilisant Live Metrics (également appelé QuickPulse) à partir d’Application Insights. Vous pouvez sélectionner et filtrer les métriques et les compteurs de performances pour surveiller en temps réel, sans aucune perturbation de votre service. Vous pouvez également inspecter les traces de la pile à partir des exemples de demandes et d’exceptions ayant échoué. En combinaison avec le profileur et le Débogueur de capture instantanée, Live Metrics constitue un outil de diagnostic puissant et non invasif pour votre site web en temps réel.

Notes

Les métriques temps réel prennent uniquement en charge TLS 1.2. Pour plus d’informations, consultez la page Dépannage.

Avec Live Metrics, vous pouvez :

  • Valider un correctif lors de sa publication, en observant les performances et les nombres d’échecs.
  • Observer l’effet des tests de charge et diagnostiquer les problèmes en temps réel.
  • Vous concentrer sur des sessions de tests particulières ou filtrer les problèmes connus, en sélectionnant et en filtrant les métriques que vous voulez observer.
  • Obtenir les traces des exceptions quand elles se produisent.
  • Faites des essais avec les filtres pour rechercher les indicateurs de performance clés les plus pertinents.
  • Surveiller en temps réel des compteurs de performances Windows.
  • Identifier plus facilement un serveur qui rencontre des problèmes et filtrer tous les indicateurs de performance clés/flux en temps réel sur ce serveur uniquement.

Capture d’écran montrant l’onglet Live Metrics.

Live Metrics est actuellement pris en charge pour les applications ASP.NET, ASP.NET Core, Azure Functions, Java et Node.js

Remarque

Le nombre d’instances de serveur supervisées affichées par Live Metrics risque d’être inférieur au nombre réel d’instances allouées pour l’application. Cette différence vient du fait que de nombreux serveurs web modernes déchargent les applications qui ne reçoivent pas de demandes sur une période donnée afin de préserver les ressources. Étant donné que Live Metrics compte uniquement les serveurs qui exécutent actuellement l’application, les serveurs qui ont déjà déchargé le processus ne sont pas compris dans ce total.

Bien démarrer

Important

La surveillance des applications ASP.NET Core LTS nécessite Application Insights version 2.8.0 ou ultérieure. Pour activer Application Insights assurez-vous qu’il est activé dans le portail Azure et que le package NuGet Application Insights est inclus. Sans le package NuGet, certaines données de télémétrie sont envoyées à Application Insights, mais n’apparaissent pas dans Live Metrics.

  1. Suivez les instructions propres à chaque langage pour activer Live Metrics :

  2. Dans le portail Azure, ouvrez la ressource Application Insights pour votre application. Ensuite, ouvrez Flux temps réel.

  3. Sécurisez le canal de contrôle si vous risquez d’utiliser des données sensibles comme des noms de clients dans vos filtres.

Notes

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.

Activer Live Metrics en utilisant le code pour les applications .NET

Remarque

Live Metrics est activé par défaut lorsque vous l’intégrez en suivant les instructions recommandées pour les applications .NET.

Pour configurer manuellement Live Metrics :

  1. Installez le package NuGet Microsoft.ApplicationInsights.PerfCounterCollector.

  2. L’exemple de code d’application console suivant illustre la configuration de Live Metrics :

    using Microsoft.ApplicationInsights;
    using Microsoft.ApplicationInsights.Extensibility;
    using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;
    using System;
    using System.Threading.Tasks;
    
    namespace LiveMetricsDemo
    {
        class Program
        {
            static void Main(string[] args)
            {
                // Create a TelemetryConfiguration instance.
                TelemetryConfiguration config = TelemetryConfiguration.CreateDefault();
                config.InstrumentationKey = "INSTRUMENTATION-KEY-HERE";
                QuickPulseTelemetryProcessor quickPulseProcessor = null;
                config.DefaultTelemetrySink.TelemetryProcessorChainBuilder
                    .Use((next) =>
                    {
                        quickPulseProcessor = new QuickPulseTelemetryProcessor(next);
                        return quickPulseProcessor;
                    })
                    .Build();
    
                var quickPulseModule = new QuickPulseTelemetryModule();
    
                // Secure the control channel.
                // This is optional, but recommended.
                quickPulseModule.AuthenticationApiKey = "YOUR-API-KEY-HERE";
                quickPulseModule.Initialize(config);
                quickPulseModule.RegisterTelemetryProcessor(quickPulseProcessor);
    
                // Create a TelemetryClient instance. It is important
                // to use the same TelemetryConfiguration here as the one
                // used to set up Live Metrics.
                TelemetryClient client = new TelemetryClient(config);
    
                // This sample runs indefinitely. Replace with actual application logic.
                while (true)
                {
                    // Send dependency and request telemetry.
                    // These will be shown in Live Metrics.
                    // CPU/Memory Performance counter is also shown
                    // automatically without any additional steps.
                    client.TrackDependency("My dependency", "target", "http://sample",
                        DateTimeOffset.Now, TimeSpan.FromMilliseconds(300), true);
                    client.TrackRequest("My Request", DateTimeOffset.Now,
                        TimeSpan.FromMilliseconds(230), "200", true);
                    Task.Delay(1000).Wait();
                }
            }
        }
    }
    

L’exemple précédent s’utilise pour les applications console, mais le même code peut être utilisé dans toute application .NET. Si d’autres modules de télémétrie sont activés pour collecter automatiquement la télémétrie, il est important de s’assurer que la même configuration utilisée pour l’initialisation de ces modules est utilisée pour le module Live Metrics.

En quoi Live Metrics diffère de Metrics Explorer et de Log Analytics ?

Fonctionnalités Flux temps réel Metrics Explorer et Log Analytics
Latence Données affichées en une seconde. Agrégé sur plusieurs minutes.
Pas de conservation Les données persistent tant qu’elles sont sur le graphique, puis sont abandonnées. Données conservées pendant 90 jours.
À la demande Les données sont diffusées uniquement tant que le volet Live Metrics est ouvert. Les données sont envoyées quand le SDK est installé et activé.
Gratuit Les données Flux de métriques temps réel n’engendrent pas de frais. Soumis à tarification.
échantillonnage Tous les compteurs et métriques sélectionnés sont transmis. Les échecs et les traces de pile sont échantillonnés. Les événements peuvent être échantillonnés.
Canal de contrôle Les signaux de contrôle de filtre sont envoyés au SDK. Nous vous recommandons de sécuriser ce canal. La communication est unidirectionnelle vers le portail.

Sélectionner et filtrer vos métriques

Ces fonctionnalités sont disponibles avec ASP.NET, ASP.NET Core et Azure Functions (v2).

Vous pouvez surveiller un KPI personnalisé en temps réel en appliquant des filtres arbitraires sur les données de télémétrie Application Insights à partir du portail. Cliquez sur la commande de filtre qui s’affiche lorsque vous passez la souris sur un graphique. Le graphique suivant illustre un KPI du nombre de demandes personnalisé avec des filtres sur les attributs URL et Durée. Vérifiez vos filtres en regardant la section d’aperçu du flux qui montre un flux en temps réel de télémétrie correspondant aux critères que vous avez spécifiés.

Capture d’écran montrant le filtre du taux de demandes.

Vous pouvez surveiller une valeur autre qu’un Nombre. Les options varient selon le type de flux, qui peut être n’importe quelle télémétrie Application Insights comme les demandes, dépendances, exceptions, suivis, événements ou métriques. Il peut s’agir aussi de votre propre mesure personnalisée.

Capture d’écran montrant le Générateur de requêtes sur le taux de demandes avec une métrique personnalisée.

En plus de la télémétrie Application Insights, vous pouvez également surveiller n’importe quel compteur de performances Windows. Sélectionnez-le dans les options de flux et fournissez le nom du compteur de performances.

Les métriques temps réel sont agrégées à deux endroits : localement sur chaque serveur, puis sur tous les serveurs. Vous pouvez changer la valeur par défaut en sélectionnant d’autres options dans les listes déroulantes respectives.

Exemple de télémétrie : événements de diagnostic temps réel personnalisés

Par défaut, le flux d’événements temps réel présente des exemples de demandes ayant échoué et d’appels de dépendance, d’exceptions, d’événements et de suivis. Sélectionnez l'icône de filtre pour voir les critères appliqués à tout moment.

Capture d’écran montrant le bouton de filtre.

Comme avec les métriques, vous pouvez spécifier un critère arbitraire sur les types de données de télémétrie Application Insights. Dans cet exemple, nous sélectionnons des événements et des échecs de demande spécifiques.

Capture d’écran montrant le Générateur de requêtes.

Remarque

Pour les critères basés sur un message d’exception, utilisez le message d’exception le plus à l’extérieur. Dans l’exemple précédent, pour éliminer l’exception sans gravité avec un message d’exception interne (après le délimiteur « <-- ») Le « client déconnecté », utilisez un critère de message ne contenant pas « Erreur de lecture du contenu de la demande ».

Pour voir les détails d’un élément dans le flux temps réel, sélectionnez-le. Vous pouvez interrompre le flux en sélectionnant Pause ou en faisant défiler vers le bas et en sélectionnant un élément. Le flux temps réel reprend lorsque vous revenez en haut, ou que vous sélectionnez le compteur d’éléments collectés alors qu’il était suspendu.

Capture d’écran montrant la fenêtre Exemple de télémétrie, avec une exception sélectionnée et les détails de l’exception affichés au bas de la fenêtre.

Filtrer par instance de serveur

Si vous voulez surveiller une instance de rôle serveur spécifique, vous pouvez appliquer un filtre par serveur. Pour filtrer, sélectionnez le nom du serveur sous Serveurs.

Capture d’écran montrant les échecs en temps réel échantillonnées.

Sécuriser le canal de contrôle

Les filtres personnalisés Live Metrics vous permettent de contrôler quelles données de télémétrie de votre application sont diffusées en streaming dans la vue Live Metrics du portail Azure. Les critères de filtres sont envoyés aux applications instrumentées avec le Kit de développement logiciel (SDK) Application Informations. La valeur de filtre peut potentiellement contenir des informations sensibles telles que l’ID client. Pour sécuriser cette valeur et empêcher la divulgation potentielle aux applications non autorisées, vous avez deux options :

  • Recommandé : Sécurisez le canal Live Metrics en utilisant l’authentification Azure Active Directory (Azure AD).
  • Hérité (non recommandé) : Configurez un canal authentifié en configurant une clé API secrète comme expliqué dans la section « Option héritée ».

Remarque

Le 30 septembre 2025, les clés API utilisées pour envoyer en streaming la télémétrie Live Metrics à Application Insights seront mises hors service. Après cette date, les applications qui utilisent les clés API ne pourront plus envoyer de données Live Metrics à votre ressource Application Insights. Une ingestion des données de télémétrie authentifiée pour le streaming Live Metrics vers Application Insights devra être effectuée avec l’authentification Azure AD pour Application Insights.

Il est possible d’essayer des filtres personnalisés sans avoir à configurer un canal authentifié. Sélectionnez l’une des icônes de filtre et autorisez les serveurs connectés. Si vous choisissez cette option, vous devrez autoriser les serveurs connectés à chaque une nouvelle session ou quand un nouveau serveur est en ligne.

Avertissement

Nous déconseillons fortement d’utiliser des canaux non sécurisés et nous désactiverons cette option six mois après le début de son utilisation. La boîte de dialogue Autoriser les serveurs connectés affiche la date après laquelle cette option sera désactivée.

Capture d’écran montrant la boîte de dialogue « Autoriser les serveurs connectés ».

Option héritée : Créer une clé API

  1. Sélectionnez l’onglet Accès d’API, puis Créer une clé API.

    Capture d’écran montrant la sélection de l’onglet Accès d’API et du bouton Créer une clé API.

  2. Cochez la case Authentifier le canal de contrôle du SDK, puis sélectionnez Générer la clé.

    Capture d’écran montrant le volet Créer une clé API, la case Authentifier le canal de contrôle du SDK cochée et la sélection de Générer la clé.

Ajouter une clé API à la configuration

Vous pouvez ajouter une clé API à la configuration des applications ASP.NET, ASP.NET Core, WorkerService et Azure Functions.

ASP.NET

Dans le fichier applicationinsights.config, ajoutez AuthenticationApiKey à QuickPulseTelemetryModule :

<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector">
      <AuthenticationApiKey>YOUR-API-KEY-HERE</AuthenticationApiKey>
</Add>

ASP.NET Core

Pour les applications ASP.NET Core, suivez ces instructions.

Modifiez ConfigureServices de votre fichier Startup.cs, comme illustré.

Ajoutez l’espace de noms suivant :

using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

Ensuite, modifiez la méthode ConfigureServices :

public void ConfigureServices(IServiceCollection services)
{
    // Existing code which includes services.AddApplicationInsightsTelemetry() to enable Application Insights.
    services.ConfigureTelemetryModule<QuickPulseTelemetryModule> ((module, o) => module.AuthenticationApiKey = "YOUR-API-KEY-HERE");
}

Pour plus d’informations sur la configuration des applications ASP.NET Core, consultez Configuration des modules de télémétrie dans ASP.NET Core.

WorkerService

Pour les applications WorkerService, suivez ces instructions.

Ajoutez l’espace de noms suivant :

using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

Ensuite, ajoutez la ligne suivante avant l’appel services.AddApplicationInsightsTelemetryWorkerService :

    services.ConfigureTelemetryModule<QuickPulseTelemetryModule> ((module, o) => module.AuthenticationApiKey = "YOUR-API-KEY-HERE");

Pour plus d’informations sur la configuration des applications WorkerService, consultez Configuration des modules de télémétrie dans WorkerService.

Applications Azure Functions

Pour les applications Azure Functions (v2), vous pouvez sécuriser le canal avec une clé API en utilisant une variable d’environnement.

Créez une clé API à partir de votre ressource Application Insights et accédez à Paramètres>Configuration pour votre application Azure Functions. Sélectionnez Nouveau paramètre d’application, entrez un nom APPINSIGHTS_QUICKPULSEAUTHAPIKEY et entrez une valeur qui correspond à votre clé API.

Tableau des fonctionnalités prises en charge

Langage Métriques de base Mesures de performances Filtrage personnalisé Exemple de télémétrie UC fractionnée par processus
.NET Framework Pris en charge (LTS) Pris en charge (LTS) Pris en charge (LTS) Pris en charge (LTS) Pris en charge (LTS)
.NET Core (cible=. NET Framework) Pris en charge (LTS) Pris en charge (LTS) Pris en charge (LTS) Pris en charge (LTS) Pris en charge (LTS)
.NET Core (cible=. NET Core) Pris en charge (LTS) Pris en charge* Pris en charge (LTS) Pris en charge (LTS) Non pris en charge
Azure Functions v2 Prise en charge Prise en charge Prise en charge Prise en charge Non pris en charge
Java Pris en charge (V2.0.0 et versions ultérieures) Pris en charge (V2.0.0 et versions ultérieures) Non pris en charge Pris en charge (V3.2.0+) Non pris en charge
Node.js Pris en charge (V1.3.0 et versions ultérieures) Pris en charge (V1.3.0 et versions ultérieures) Non pris en charge Pris en charge (V1.3.0 et versions ultérieures) Non pris en charge

Les métriques de base incluent les requêtes, les dépendances et le taux d’exceptions. Les métriques du niveau de performance (compteurs de performances) incluent la mémoire et l’UC. L’exemple de télémétrie montre un flux d’informations détaillées pour les demandes et les dépendances ayant échoué, les exceptions, les événements et les traces.

La prise en charge des compteurs de performances varie légèrement entre les versions de .NET Core qui ne ciblent pas le .NET Framework :

  • Les métriques des compteurs de performances sont prises en charge quand elles sont exécutées dans Azure App Service pour Windows (SDK ASP.NET Core version 2.4.1 ou ultérieure).
  • Les compteurs de performances sont pris en charge quand l’application est exécutée sur des machines Windows, comme une machine virtuelle, un service cloud Azure ou en local (SDK ASP.NET Core version 2.7.1 ou ultérieure), mais uniquement pour les applications qui ciblent .NET Core LTS ou ultérieur.
  • Les compteurs de performances sont pris en charge lorsque l’application s’exécute n’importe où (Linux, Windows, app service pour Linux ou conteneurs) dans les versions les plus récentes, mais uniquement pour les applications qui ciblent .NET Core LTS ou ultérieur.

Dépannage

Live Metrics utilise des adresses IP différentes de celles des autres données de télémétrie Application Insights. Assurez-vous que ces adresses IP sont ouvertes dans votre pare-feu. Vérifiez également que les ports sortants pour Live Metrics sont ouverts dans le pare-feu de vos serveurs.

Comme décrit dans l’annonce relative à la migration d’Azure TLS 1.2, les métriques temps réel prennent uniquement en charge TLS 1.2 par défaut. Si vous utilisez une version antérieure de TLS, les métriques en temps réel n’affichent aucune donnée. Pour les applications basées sur le .NET Framework 4.5.1, consultez Activer TLS (Transport Layer Security) 1.2 sur les clients – Configuration Manager pour prendre en charge la version plus récente de TLS.

Configuration manquante pour .NET

  1. Vérifiez que vous utilisez la dernière version du package NuGet Microsoft.ApplicationInsights.PerfCounterCollector.

  2. Modifiez le fichier ApplicationInsights.config :

    • Vérifiez que la chaîne de connexion pointe vers la ressource Application Insights que vous utilisez.
    • Localisez l’option de configuration QuickPulseTelemetryModule. Si elle n’est pas là, ajoutez-la.
    • Localisez l’option de configuration QuickPulseTelemetryProcessor. Si elle n’est pas là, ajoutez-la.
    <TelemetryModules>
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.
    QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector"/>
    </TelemetryModules>
    
    <TelemetryProcessors>
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.
    QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector"/>
    <TelemetryProcessors>
    
  3. Redémarrez-la.

Étapes suivantes