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.

Screenshot that shows the Live Metrics tab.

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

Pour activer Application Insights. vérifiez qu’il est activé dans le Portail Azure et que votre application utilise une version récente du package NuGet Application Insights. 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 Live Metrics manuellement :

  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;

// 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.

Screenshot that shows the Filter request rate.

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.

Screenshot that shows the Query Builder on Request Rate with a custom metric.

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.

Screenshot that shows the Filter button.

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.

Screenshot that shows the Query Builder.

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.

Screenshot that shows the Sample telemetry window with an exception selected and the exception details displayed at the bottom of the window.

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.

Screenshot that shows the Sampled live failures.

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 Insights. 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 Microsoft Entra.
  • 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 la diffuser en continu du Live Metrics vers Application Insights devra être effectuée avec l’authentification Microsoft Entra 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 devez autoriser les serveurs connectés à chaque 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.

Screenshot that shows the Authorize connected servers dialog.

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

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

    Screenshot that shows selecting the API Access tab and the Create API key button.

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

    Screenshot that shows the Create API key pane. Select Authenticate SDK control channel checkbox and then select Generate key.

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.

Dans le fichier Program.cs, ajoutez l’espace de noms suivant :

using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

Ajoutez ensuite l’inscription du service suivante :

// Existing code which includes services.AddApplicationInsightsTelemetry() to enable Application Insights.
builder.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
Python Non pris en charge Non pris en charge Non pris en charge Non pris en charge 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 performance sont pris en charge lorsque l’application est exécutée sur n’importe quelle machine Windows pour applications qui ciblent .NET Core LTS ou une version ultérieure.
  • 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 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.

Message d’état « Les données sont temporairement inaccessibles »

Lorsque vous accédez à Live Metrics, vous pouvez voir une bannière avec le message d’état : « Les données sont temporairement inaccessibles ». Les mises à jour sur notre état sont publiées ici https://aka.ms/aistatus »

Suivez le lien vers la page Statut Azure et vérifier tout problème d’activation affectant Application Insights. Vérifiez que les pare-feu et les extensions de navigateur ne bloquent pas l’accès aux métriques temps réel en cas de panne. Par exemple, certaines extensions ad-blocker populaires bloquent les connexions à *.monitor.azure.com. Pour utiliser toutes les fonctionnalités des métriques en direct, désactivez l’extension ad-blocker ou ajoutez une règle d’exclusion à votre bloqueur de publicités, à votre pare-feu, etc. pour le domaine *.livediagnostics.monitor.azure.com.

Grand nombre inattendu de requêtes de livediagnostics.monitor.azure.com

Les SDK Application Insights utilisent une API REST pour communiquer avec des points de terminaison QuickPulse, qui fournissent des métriques actives pour votre application web. Par défaut, les sdk interrogent les points de terminaison une fois toutes les cinq secondes pour case activée si vous affichez le volet Métriques en direct dans le Portail Azure.

Si vous ouvrez le volet Métriques actives, les SDK basculent vers un mode de fréquence plus élevée et envoient de nouvelles métriques à QuickPulse toutes les secondes. Cela vous permet de surveiller et de diagnostiquer votre application en direct avec une latence de 1 seconde, mais génère également plus de trafic réseau. Pour restaurer le flux normal du trafic, quittez le volet Métriques en direct.

Notes

Les appels d’API REST effectués par les SDK aux points de terminaison QuickPulse ne sont pas suivis par Application Insights et n’affectent pas vos appels de dépendance ou d’autres métriques. Toutefois, vous pouvez les voir dans d’autres outils de surveillance réseau.

Étapes suivantes