FAQ sur les Application Insights - Questions fréquentes (FAQ)

FAQ officielle pour Azure Monitor Application Insights. Trouvez des réponses aux questions sur l’utilisation d’Application Insights avec Azure Monitor.

Aperçu

Comment puis-je instrumenter une application ?

Pour plus d’informations sur l’instrumentation des applications, afin d’activer Application Insights, consultez les principes de base de la collecte de données.

Comment puis-je utiliser Application Insights ?

Après avoir activé Application Insights en instrumentant une application, nous vous suggérons de commencer par consulter les métriques en direct et la carte de l'application.

Quelles sont les données de télémétrie collectées par Application Insights ?

À partir des applications web du serveur :

• Requêtes HTTP.
• Dépendances telles que SQL, HTTP, Azure Cosmos DB, Azure Table Storage, Stockage Blob Azure et appels Stockage File d'attente Azure.
• Exceptions et traces de pile.
• Métriques d’exécution à partir de l’instrumentation prise en charge.
• Événements et métriques personnalisés que vous envoyez à l’aide de la télémétrie personnalisée OpenTelemetry, du Kit de développement logiciel (SDK) JavaScript ou de Click Analytics.
• Journaux d’activité de suivi si vous configurez le collecteur approprié.

À partir des pages web du client :

• Exceptions non interceptées dans votre application, y compris des informations sur

  • Arborescence des appels de procédure
  • Détails de l’exception et message accompagnant l’erreur
  • Numéros de ligne et de colonne de l’erreur
  • URL où l’erreur a été générée
  • Les demandes de dépendance réseau effectuées par vos requêtes HTTP XML (XHR) d’application et Fetch (la collecte d’extraction est désactivée par défaut), incluent des informations sur :
    • URL de la source de dépendance
    • Commande et méthode utilisées pour demander la dépendance
    • Durée de la demande
    • Code de résultat et état de réussite de la demande
    • ID (le cas échéant) de l’utilisateur qui effectue la demande
    • Contexte de corrélation (le cas échéant) dans lequel la demande est effectuée

• Informations utilisateur (par exemple, emplacement, réseau, adresse IP)

• Informations sur l’appareil (par exemple, le navigateur, le système d’exploitation, la version, la langue ou le modèle)

• Informations de session

  Remarque

  Pour certaines applications, telles que les applications SPA (Single Page Applications), la durée n'est pas toujours enregistrée et, dans ces cas, elle est par défaut à 0.

  Pour plus d’informations, consultez collecte, rétention et stockage des données dans Application Insights.

À partir d’autres sources, si vous les configurez :

• Azure Diagnostics
• Importer dans Log Analytics
• Log Analytics
• Logstash

Où vont les données de télémétrie collectées avec les cadres de suivi traditionnels ?

Lorsque vous utilisez des frameworks de journalisation comme Serilog, les messages de journal sont ingérés par Application Insights en tant que données de télémétrie de trace et stockés dans la traces table (ou AppTraces dans Log Analytics). Cela est par conception, étant donné que les tables telles que requests, dependencieset exceptions sont réservées à leurs types de données de télémétrie respectifs.

Pour plus d’informations, consultez le modèle de données de télémétrie Application Insights.

Combien de ressources Application Insights déployer ?

Pour comprendre le nombre de ressources Application Insights requises pour couvrir vos applications ou composants entre les environnements, consultez le guide de planification du déploiement Application Insights.

Comment gérer les ressources Application Insights avec PowerShell ?

Vous pouvez écrire des scripts PowerShell à l’aide d'Azure Resource Monitor pour :

• Créer et mettre à jour des ressources Application Insights.
• Définir le plan de tarification.
• Obtenez le chaîne de connexion.
• Ajouter une alerte métrique.
• Ajouter un test de disponibilité.

Vous ne pouvez pas définir un rapport de l’explorateur de métriques ou une exportation continue.

Comment interroger la télémétrie Application Insights ?

Utilisez l’API REST pour exécuter des requêtes Log Analytics.

Puis-je envoyer des données de télémétrie au portail Application Insights ?

Nous vous recommandons Azure Monitor OpenTelemetry Distro.

Le schéma d'ingestion et le protocole de point de terminaison sont disponibles publiquement.

Combien de temps dure la collecte de données de télémétrie ?

La plupart des données Application Insights ont une latence de moins de 5 minutes. Certaines données peuvent prendre plus de temps, ce qui est courant pour les fichiers journaux plus volumineux. Consultez le contrat de niveau de service Application Insights.

Qu’est-ce que le modèle tarifaire Application Insights ?

Application Insights est facturé via l'espace de travail Log Analytics dans lequel ses données de journal sont importées. Le niveau tarifaire Log Analytics par défaut avec paiement à l’utilisation comprend 5 Go par mois d’allocation de données gratuite par compte de facturation. Découvrez les options de tarification des journaux d’activité d’Azure Monitor.

Existe-t-il des frais de transfert de données entre une application web Azure et Application Insights ?

• Si votre application web Azure est hébergée dans un centre de données où il existe un point de terminaison de collection Application Insights, il n'y a aucun frais.
• S'il n'existe aucun point de terminaison de collecte dans votre centre de données hôte, la télémétrie de votre application entraîne des frais de sortie Azure.

Cette réponse dépend de la distribution de nos points de terminaison, et non pas de l’endroit où votre ressource Application Insights est hébergée.

Est-ce que j’entraîne des coûts réseau si ma ressource Application Insights surveille une ressource Azure (autrement dit, producteur de télémétrie) dans une autre région ?

Oui, vous pouvez encourir des frais de réseau supplémentaires qui varient en fonction de la région d'où provient la télémétrie et de sa destination. Pour plus d’informations, consultez Azure tarification de la bande passante.

Si vous voyez des frais inattendus ou des coûts élevés dans Application Insights, ce guide peut vous aider. Il couvre les causes courantes telles que le volume de télémétrie élevé, les pics d’ingestion de données et l’échantillonnage mal configuré. Il est particulièrement utile si vous résolvez des problèmes liés aux pics de coûts, au volume de télémétrie, à l’échantillonnage qui ne fonctionne pas, aux limites de données, à l’ingestion élevée ou à la facturation inattendue. Pour démarrer, consultez la section « Dépannage d’un volume élevé d’ingestion de données » dans Application Insights.

Quelles sont les versions TLS prises en charge ?

Application Insights utilise TLS (Transport Layer Security) 1.2 et 1.3.

Pour toute question d’ordre général concernant le problème lié à l’ancienne version de TLS, consultez les articles Résolution des problèmes TLS et Prise en charge de TLS par Azure Resource Manager.

Où puis-je trouver plus d'informations sur Application Insights ?

Pour plus d’informations, consultez Présentation d’Application Insights.

Collecte, rétention, storage et confidentialité des données

Comment Application Insights gère-t-il la collecte, la rétention, la storage et la confidentialité des données ?

Contexte

Application Insights collecte les données de télémétrie à partir de votre application et les stocke dans un espace de travail Log Analytics. Il fonctionne pour les applications hébergées n’importe où, non seulement dans Azure.

Ce qui est collecté et d'où

La télémétrie provient de : (1) le Kit de développement logiciel (SDK) que vous ajoutez à votre application, y compris les données de télémétrie personnalisées que vous envoyez, les agents serveur facultatifs (2) et (3) les tests de disponibilité exécutés par Microsoft. Les données classiques incluent les requêtes, les dépendances, les exceptions et les incidents, les compteurs de performances, le contexte du client et du serveur, les traces et tous les événements ou métriques personnalisés que vous envoyez. Pour vérifier ce qui est envoyé, exécutez votre application en mode débogage et vérifiez les fenêtres Sortie ou Diagnostics de votre IDE. Pour les pages web, ouvrez votre navigateur developer tools et inspectez l’onglet Réseau. Vous pouvez filtrer ou enrichir les données de télémétrie avant d’être envoyées en implémentant un processeur de télémétrie.

Rétention et stockage

La conservation des données brutes peut être définie sur 30, 60, 90, 120, 180, 270, 365, 550 ou 730 jours. La rétention au-delà de 90 jours peut entraîner des frais supplémentaires. Les métriques agrégées sont conservées à une granularité de 1 minute pendant 90 jours. Les instantanés de débogage sont conservés pendant 15 jours. Les données sont stockées dans la région que vous choisissez lors de la création de la ressource. La télémétrie est immuable après l’ingestion. Vous ne pouvez pas modifier les données de télémétrie. Le vidage est disponible pour supprimer des données si nécessaire.

Access, la sécurité et le chiffrement

Les données sont visibles pour vous et vos collègues avec access et peuvent être exportées. Microsoft utilise vos données uniquement pour fournir au service des access de personnel restreint et peut utiliser des statistiques agrégées pour améliorer le service. Les données de télémétrie sont envoyées via HTTPS et les données sont chiffrées au repos et se déplacent entre les centres de données.

Confidentialité et utilisation responsable

Les modules sdk par défaut se concentrent sur les performances, l’utilisation et les diagnostics, et n’incluent généralement pas de données personnelles sensibles. Ne placez pas de données sensibles dans des URL. Passez en revue les données de télémétrie personnalisées afin qu’elles n’incluent pas de données personnelles. L’adresse IP du client est utilisée pour la géolocalisation, puis le champ IP stocké est zéro par défaut. Si vous avez besoin de masquage, ajoutez un initialiseur de télémétrie. Si votre application a besoin d’une désactivation, désactivez la collecte dans le code. Passez également en revue les champs apparemment innocues, par exemple le nom de l’appareil sur les appareils personnels. Vous pouvez contrôler ou désactiver une collection dans la configuration ou via du code. Pour plus d’informations, consultez Gestion de la géolocalisation et des adresses IP.

TLS

Utilisez TLS moderne pour les données en transit. Ne codez pas en dur les versions antérieures du protocole. Autorisez la plateforme à négocier des versions plus récentes dès qu’elles deviennent disponibles. Pour plus d’informations, consultez Secure your Azure Monitor deployment.

Mise en mémoire tampon locale et interruptions de service

Si la connectivité à Azure est perdue ou limitée, les exportateurs OpenTelemetry pris en charge et les kits SDK actuels peuvent mettre en mémoire tampon les données de télémétrie localement et réessayer. Pour connaître le comportement actuel d’OpenTelemetry, consultez stockage hors connexion et nouvelles tentatives automatiques. Pour connaître les paramètres de mise en mémoire tampon du navigateur, consultez la configuration du Kit de développement logiciel (SDK) JavaScript.

Quelles sont les données d’utilisation collectées par Microsoft ?

Dans de nombreux cas, Application Insights collecte automatiquement des données sur l’utilisation du produit pour Microsoft. Ces données sont stockées dans un magasin de données Microsoft et n’affectent pas le volume et le coût de surveillance des clients. Application Insights collecte les métriques essentielles et nonessentiales sur les points suivants :

• Distribution Azure Monitor OpenTelemetry
• Autoinstrumentation (instrumentation automatique)

Les trois principaux objectifs de cette collecte de données sont les suivants :

• Santé et fiabilité du service : la surveillance de la connectivité au point de terminaison d’ingestion d’une perspective externe pour garantir que le service fonctionne correctement.
• Diagnostics de support : fournir des insights d’auto-assistance et aider le support client à diagnostiquer et à résoudre les problèmes.
• Amélioration du produit : collecte d’insights pour que Microsoft optimise la conception du produit et améliore l’expérience utilisateur globale.

Remarque

La collecte de données d'utilisation ne prend pas en charge Azure Private Link.

Langues prises en charge

Métriques	.NET	Java	JavaScript	Node.js	Python
Métriques essentielles
Réseau	❌	✅	❌	✅	✅
Joindre	✔️*	✅	❌	✅	✅
Caractéristique	❌	✅	❌	✅	✅
Métriques non essentielles
Échec des E/S de disque	❌	✅	❌	❌	❌

Régions d’Europe prises en charge

La collecte de données d’utilisation prend en charge la limite de données de l’UE pour les ressources Application Insights dans les régions suivantes :

Nom de la zone géographique	Nom de la région
Europe	Europe Nord
Europe	Europe Ouest
France	France Centrale
France	France Sud
Allemagne	Allemagne Centre-Ouest
Norvège	Norvège Est
Norvège	Norvège Ouest
Suède	Suède Centre
Suisse	Suisse Nord
Suisse	Suisse Ouest
Royaume-Uni	Royaume-Uni Sud
Royaume-Uni	Royaume-Uni Ouest

Données d’utilisation collectées

Métriques réseau

Nom de la métrique	Unité	Dimensions prises en charge
Nombre de succès de la requête	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host
Nombre d’échecs de requêtes	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Status Code
Durée de la demande	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host
Nombre de nouvelles tentatives	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Status Code
Nombre de limitations	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Status Code
Nombre d’exceptions	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Exception Type

Ajouter des métriques

Nom de la métrique	Unité	Dimensions prises en charge
Joindre	Nombre	Resource Provider, Resource Provider Identifier, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version

Métriques de fonctionnalité

Nom de la métrique	Unité	Dimensions prises en charge
Caractéristique	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Feature, Type, Operating System, Language, Version

Métriques non essentielles

Suivre l’échec d’E/S du disque lorsque vous utilisez la persistance de disque pour une télémétrie fiable.

Nom de la métrique	Unité	Dimensions prises en charge
Nombre d’échecs de lecture	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version
Nombre d’échecs d’écriture	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version

Configuration du pare-feu

Les métriques sont envoyées aux emplacements suivants, auxquels les connexions sortantes doivent être ouvertes dans les pare-feu :

Emplacement	URL
Europe	westeurope-5.in.applicationinsights.azure.com
En dehors de l’Europe	westus-0.in.applicationinsights.azure.com

Désactiver la collecte des données d’utilisation

.NET

La collecte de données d’utilisation est activée par défaut. Il peut être désactivé en définissant la variable d’environnement APPLICATIONINSIGHTS_STATSBEAT_DISABLED sur true.

Java

Remarque

Seules les métriques non essentielles peuvent être désactivées en Java.

Pour désactiver les métriques nonessential, ajoutez la configuration suivante à votre fichier de configuration :

{
  "preview": {
    "statsbeat": {
        "disabled": "true"
    }
  }
}

Vous pouvez également désactiver cette fonctionnalité en paramétrant la variable d’environnement APPLICATIONINSIGHTS_STATSBEAT_DISABLED sur true. Ce paramètre est alors prioritaire sur disabled qui est spécifié dans la configuration JSON.

Node.js

La collecte de données d’utilisation est activée par défaut. Il peut être désactivé en définissant la variable d’environnement APPLICATION_INSIGHTS_NO_STATSBEAT sur true.

Python

La collecte de données d’utilisation est activée par défaut. Il peut être désactivé en définissant la variable d’environnement APPLICATIONINSIGHTS_STATSBEAT_DISABLED_ALL sur true.

Informations archivées

Pour des informations archivées, consultez La collecte, la rétention, et le stockage des données dans Application Insights.

Prise en charge de TLS

Déterminer si la mise hors service TLS vous affecte

Application Insights et Azure Monitor ne contrôlent pas la version TLS utilisée pour les connexions HTTPS. La version TLS dépend du système d’exploitation et de l’environnement d’exécution où votre application s’exécute.

Pour confirmer la version TLS en cours d’utilisation :

• Passez en revue la documentation relative à votre système d’exploitation et à votre runtime ou infrastructure.
• Si vous avez besoin d’aide supplémentaire, contactez l’équipe de support appropriée. N’ouvrez pas de demande de support avec Application Insights.

Exemple de prise en charge du langage et du runtime pour TLS 1.2+

Les versions suivantes incluent la prise en charge intégrée de TLS 1.2 ou version ultérieure :

• .NET / .NET Core : .NET Framework 4.6.2 ou version ultérieure, et toutes les versions de .NET Core
• Java : Java 8 update 161 (8u161) ou version ultérieure
• Python : Distributions Python générées avec OpenSSL 1.0.1 ou version ultérieure
• Node.js: Node.js version 10 ou ultérieure

Exemple de prise en charge du système d’exploitation pour TLS 1.2+

Les systèmes d’exploitation suivants incluent la prise en charge intégrée de TLS 1.2 ou version ultérieure :

• Windows : Windows 8, Windows Server 2012 et versions ultérieures
• Linux : la plupart des distributions Linux modernes qui utilisent OpenSSL 1.0.1 ou version ultérieure

Comment puis-je m'assurer que mes ressources ne sont pas affectées ?

Pour éviter les interruptions de service, chaque point de terminaison distant (y compris les demandes dépendantes) que votre ressource interagit avec les besoins de prendre en charge au moins une combinaison de la même version du protocole, de la suite de chiffrement et de la courbe elliptique mentionnée précédemment. Si le point de terminaison distant ne prend pas en charge la configuration TLS requise, il doit être mis à jour pour prendre en charge une combinaison de la configuration TLS postérieure à l'obsolescence.

Après le 1er mai 2025, quel est le comportement des ressources affectées ?

Les ressources Application Insights affectées arrêtent l'ingestion de données et ne peuvent pas accéder aux composants d'application requis. Par conséquent, certaines fonctionnalités arrêtent de fonctionner.

Quels composants la dépréciation affecte-t-elle ?

La dépréciation du protocole TLS (Transport Layer Security) détaillée dans ce document ne doit affecter le comportement qu’après le 1er mai 2025. Pour plus d’informations sur les opérations CRUD, consultez la documentation relative à la prise en charge de TLS par Azure Resource Manager. Cette ressource fournit plus d’informations sur le support TLS et les calendriers d’obsolescence.

Où puis-je obtenir la prise en charge du protocole TLS (Transport Layer Security) ?

Pour toute question générale sur les problème de TLS hérité, consultez Résolution des problèmes TLS.

Où puis-je trouver plus d'informations sur la prise en charge de TLS dans Application Insights ?

Pour plus d'informations, consultez la section relative à la prise en charge de TLS..

applications ASP.NET Core

Comment puis-je suivre les données de télémétrie qui ne sont pas automatiquement collectées ?

Pour l’instrumentation actuelle, utilisez les API OpenTelemetry et les API de journalisation ou de métriques spécifiques au langage. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Pour les événements personnalisés du navigateur, utilisez le Kit de développement logiciel (SDK) JavaScript Application Insights ou Click Analytics. Pour les événements personnalisés côté serveur, utilisez des événements personnalisés OpenTelemetry.

Comment puis-je enregistrer le corps de la requête et de la réponse dans ma télémétrie ?

ASP.NET Core dispose d'un support intégré pour la journalisation des informations de requêtes et réponses HTTP, y compris le corps de la requête. Cela peut exposer des informations d’identification personnelle (PII) et augmenter considérablement les coûts de performances et d’ingestion, afin d’évaluer soigneusement les risques avant de l’utiliser.

Comment puis-je personnaliser la collecte des journaux ILogger ?

Pour les applications .NET actuelles, configurez la collecte de journaux via OpenTelemetry et votre configuration standard de journalisation .NET. Utilisez Logging:LogLevel dans appsettings.json pour choisir les niveaux de journalisation des applications et configurer l’exportation du journal OpenTelemetry dans le cadre de la configuration d’OpenTelemetry pour Azure Monitor. Consultez Activer OpenTelemetry avec Application Insights et Modifier la télémétrie.

Je déploie mon application ASP.NET Core sur Web Apps. Dois-je toujours activer l’extension Application Insights à partir de Web Apps ?

Choisissez un chemin d’instrumentation pour l’application. Pour la configuration actuelle basée sur le code, utilisez Azure Monitor OpenTelemetry. Pour l’analyse App Service sans code, utilisez l’analyse des applications sans modification du code. Évitez de superposer l’instrumentation pour la même application, sauf si vous validez une migration.

Puis-je activer la surveillance Application Insights sans modifier le code d’application ?

Pour la surveillance des nouvelles applications, utilisez la distribution Azure Monitor OpenTelemetry ou les chemins d’auto-instrumentation actuels. Consultez Activer OpenTelemetry avec Application Insights et l’analyse des applications sans modification du code.

Où puis-je obtenir plus d’informations sur l’utilisation d’Application Insights pour ASP.NET Core applications ?

Pour l’instrumentation actuelle pour ASP.NET Core, consultez Activer OpenTelemetry avec Application Insights.

Compteurs de performances ASP.NET

Quelle est la différence entre le taux d’exceptions et les mesures d’exceptions ?

• Exception rate : le taux d’exceptions est un compteur de performances système. Le CLR compte l’ensemble des exceptions gérées et non gérées qui sont levées et divise le total d’un intervalle d’échantillonnage par la longueur de cet intervalle. Le Kit de développement logiciel (SDK) Application Insights collecte ce résultat et l’envoie au portail.
• Exceptions: la métrique Exceptions compte les données de télémétrie d’exception reçues par le portail dans l’intervalle d’échantillonnage du graphique. Il a également géré les exceptions que votre instrumentation rapporte. Il peut ne pas inclure chaque exception non gérée.

Où puis-je obtenir plus d’informations sur les compteurs de performances ASP.NET ?

Pour obtenir des conseils actuels sur les métriques, consultez Métriques dans Application Insights.

Compteurs d’événements ASP.NET

Puis-je voir les compteurs d’événements dans les métriques temps réel ?

Les mesures en temps réel n’affichent pas EventCounters. Utilisez Metrics Explorer ou Analytics pour voir les données de télémétrie.

Après avoir activé Application Insights à partir du portail d'application web Azure, pourquoi ne puis-je pas voir les compteurs d'événements ?

La surveillance App Service sans modification du code ne prend actuellement pas en charge cette fonctionnalité pour ASP.NET Core.

Où puis-je obtenir plus d’informations sur les compteurs d’événements ASP.NET ?

Pour obtenir des conseils actuels sur les métriques, consultez Métriques dans Application Insights.

Suivi des dépendances

Comment le collecteur automatique de dépendances signale-t-il les échecs d’appels des dépendances ?

Les appels de dépendance échoués ont success le champ défini à false. La télémétrie des dépendances ne crée pas automatiquement un élément d’exception distinct pour chaque appel de dépendance échoué. Le modèle de données complet pour la télémétrie des dépendances est décrit dans le modèle de données de télémétrie Application Insights.

Comment puis-je calculer la latence d’ingestion pour mes données de télémétrie de dépendances ?

Utilisez ce code :

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp
| extend TimeIngested = ingestion_time()

Comment puis-je déterminer le moment où l'appel de dépendance a été initié ?

Dans la vue de requête Log Analytics, timestamp représente le moment où l’opération de télémétrie de dépendance a été lancée, qui se produit immédiatement après la réception de la réponse de l’appel de dépendance. Pour calculer l’heure de début de l’appel de dépendance, vous devez prendre timestamp et soustraire la duration enregistrée de l’appel de dépendance.

Le suivi des dépendances dans Application Insights inclut-il les corps de réponse de journalisation ?

Le suivi des dépendances dans Application Insights n’inclut pas les corps de réponse de journalisation, car cela générerait trop de données de télémétrie pour la plupart des applications.

Où puis-je trouver plus d'informations sur le suivi des dépendances dans Application Insights ?

Pour obtenir des instructions actuelles sur les dépendances et les étendues personnalisées, consultez Ajouter des étendues personnalisées.

Tests de disponibilité

Puis-je exécuter des tests de disponibilité sur un serveur intranet ?

Les tests de disponibilité s’exécutent sur des points de présence qui sont répartis dans le monde entier. Il existe deux solutions :

• Firewall door : autoriser les demandes adressées à votre serveur à partir de la liste longue et modifiable des agents de test web.
• Code personnalisé : Écrivez votre propre code pour envoyer des requêtes régulières à votre serveur depuis votre intranet. Vous pouvez exécuter Visual Studio tests web à cet effet. Émettez un signal de santé interne et alertez sur le journal ou la métrique résultante.

Quelle est la chaîne de l’agent utilisateur pour les tests de disponibilité ?

La chaîne de l’agent utilisateur est Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Où puis-je trouver plus d'informations sur les tests de disponibilité d'Application Insights ?

Pour plus d'informations, consultez la section Tests de disponibilité.

Prise en charge TLS pour les tests de disponibilité

Quel est l'impact de cette dépréciation sur le comportement de mes tests web ?

Les tests de disponibilité agissent comme un client distribué dans chacun des emplacements de test web pris en charge. Chaque fois qu’un test web est exécuté, le service de test de disponibilité tente d’atteindre le point de terminaison distant défini dans la configuration du test web. Un message Hello du client TLS est envoyé, qui contient toutes les configurations TLS actuellement prises en charge. Si le point de terminaison distant partage une configuration TLS commune avec le client de test de disponibilité, alors l’établissement de la liaison TLS réussit. Sinon, le test web échoue avec un échec d’établissement d'une liaison TLS.

Comment puis-je valider la configuration TLS qu'un point de terminaison distant supporte ?

Il existe plusieurs outils pour définir la configuration TLS prise en charge par un point de terminaison. L’une des méthodes consiste à suivre l’exemple détaillé sur cette page. Si votre point de terminaison distant n'est pas disponible via l'Internet public, vous devez vous assurer que vous validez la configuration TLS prise en charge sur le point de terminaison distant à partir d'un ordinateur qui a access pour appeler votre point de terminaison.

Remarque

Pour découvrir les étapes permettant d’activer la configuration TLS nécessaire sur votre serveur web, il est préférable de contacter l’équipe propriétaire de la plateforme d’hébergement sur laquelle votre serveur web s’exécute, si le processus n’est pas connu.

Après le 1er mai 2025, quel sera le comportement des tests Web impactés ?

Il n’existe aucun type d’exception avec lequel tous les échecs d’établissement d’une liaison TLS affectés par cette dépréciation se présenteraient. Toutefois, l’exception la plus courante qui commencerait à faire échouer votre test web serait The request was aborted: Couldn't create SSL/TLS secure channel. Vous devriez également pouvoir consulter les éventuelles erreurs liées au protocole TLS dans la section Dépannage du transport TLS du résultat du test Web potentiellement concerné.

Puis-je voir quelle configuration TLS est actuellement utilisée par mon test web ?

La configuration TLS négociée pendant une exécution de test web ne peut pas être consultée. Tant que le point de terminaison distant prend en charge la configuration TLS courante avec les tests de disponibilité, aucun impact ne doit être observé après la dépréciation.

Quels composants la dépréciation affecte-t-elle dans le service de test de disponibilité ?

L’obsolescence de TLS détaillée dans ce document ne devrait affecter le comportement d’exécution des tests Web de disponibilité qu’après le 1er mai 2025. Pour plus d’informations sur l’interaction avec le service de test de disponibilité pour les opérations CRUD, consultez Prise en charge TLS d'Azure Resource Manager. Cette ressource fournit plus d’informations sur le support TLS et les calendriers d’obsolescence.

Où puis-je obtenir des informations sur la prise en charge de TLS ?

Pour toute question générale sur les problème de TLS hérité, consultez Résolution des problèmes TLS.

Où puis-je trouver plus d'informations sur la prise en charge de TLS pour les tests de disponibilité ?

Pour plus d'informations, consultez la section Configurations TLS prises en charge.

Supervision dans Azure App Service pour les applications .NET, Node.js, Python et Java

Que modifie Application Insights dans mon project ?

Les modifications dépendent de la voie d’instrumentation. La surveillance du service d'application sans code utilise généralement les paramètres d'application et la configuration de la plateforme. La surveillance basée sur le code utilise le package OpenTelemetry et la configuration de démarrage pour la langue sélectionnée. Pour obtenir des conseils actuels, consultez Enable application monitoring in Azure App Service et Enable OpenTelemetry avec Application Insights.

Quelle est la différence entre les métriques standard d'Application Insights et les métriques Azure App Service ?

Application Insights collecte des données de télémétrie pour les requêtes qui ont été envoyées à l'application. Si l'échec se produit dans Web Apps ou le serveur web et que la demande n'a pas atteint l'application utilisateur, Application Insights ne dispose pas de données de télémétrie.

La durée de serverresponsetime calculée par Application Insights ne correspond pas nécessairement au temps de réponse du serveur observé par Web Apps. Application Insights compte la durée pendant laquelle la requête atteint l’application utilisateur. Si la demande est bloquée ou mise en file d’attente sur le serveur web, le temps d’attente est inclus dans les métriques Web Apps, mais pas dans les métriques Application Insights.

Où puis-je obtenir plus d’informations sur la surveillance dans Azure App Service pour les applications .NET, Node.js, Python et Java ?

Pour plus d’informations, consultez Enable application monitoring in Azure App Service.

Instrumentation automatique

Le terme « auto-instrumentation » doit-il comporter un trait d’union en anglais ?

Nous suivons le Guide de style Microsoft pour la documentation de produit publiée sur la plateforme Microsoft Learn.

En général, nous n’incluons pas de trait d’union après le préfixe « auto ».

Où puis-je trouver plus d'informations sur l'instrumentation automatique ?

Pour plus d’informations, consultez Quelle est l’autoinstrumentation pour Azure Monitor Application Insights ?.

Chaînes de connexion

Les nouvelles régions Azure nécessitent-elles l’utilisation de chaînes de connexion ?

Nouvelles régions Azure requièrent l’utilisation de chaînes de connexion au lieu de clés d’instrumentation. Connection string identifie la ressource que vous souhaitez associer à vos données de télémétrie. Elle vous permet également de modifier les points de terminaison que votre ressource utilisera comme destination pour votre télémétrie. Copiez le chaîne de connexion et ajoutez-le au code de votre application ou à une variable d'environnement.

Dois-je utiliser des chaînes de connexion ou des clés d’instrumentation ?

Nous vous recommandons d’utiliser des chaînes de connexion plutôt que des clés d’instrumentation.

Quand dois-je définir la variable d’environnement ?

Définissez la APPLICATIONINSIGHTS_CONNECTION_STRING valeur manuelle dans tous les scénarios où le système ne le fournit pas automatiquement. Ces scénarios incluent, mais ne sont pas limités à : le développement local et les Fonctions Isolées .NET avec l'intégration d'ASP.NET Core. Dans ce cas, la variable d’environnement garantit que le pipeline OpenTelemetry peut envoyer des données de télémétrie à Application Insights. Pour plus d’informations sur la configuration des chaînes de connexion avec une variable d’environnement, consultez Configuration d’OpenTelemetry dans Application Insights.

Dois-je utiliser une ressource Application Insights distincte pour la télémétrie du navigateur si j’utilise l’ingestion côté serveur authentifiée ou OTLP ?

Pas strictement. Une seule ressource Application Insights peut recevoir des données de télémétrie de navigateur à partir du Kit de développement logiciel (SDK) JavaScript Application Insights et des données de télémétrie côté serveur envoyées à l’aide de l’ingestion authentifiée lorsque l’authentification locale reste activée pour l’ingestion du navigateur. La télémétrie côté serveur peut utiliser l’ingestion authentifiée via Microsoft Entra, tandis que l’ingestion OTLP à l’aide du collecteur OpenTelemetry nécessite une authentification Microsoft Entra. Vous n’avez pas besoin d’éviter OpenTelemetry ou OTLP uniquement, car votre application collecte également les données de télémétrie du navigateur.

L’exception principale est lorsque vous désactivez l’authentification locale sur une ressource Application Insights pour exiger Microsoft Entra authentification pour toute ingestion. Dans cette configuration, le Kit de développement logiciel (SDK) JavaScript ne peut pas s’authentifier directement à partir du navigateur et la télémétrie du navigateur pourrait arrêter de circuler. Pour la télémétrie du navigateur dans ce scénario, utilisez une ressource de télémétrie de navigateur distincte avec l’authentification locale activée ou routez la télémétrie du navigateur via un modèle proxy authentifié. Pour plus d’informations, consultez La télémétrie du navigateur authentifié à l’aide de chaînes de connexion.

Même lorsqu’une seule ressource fonctionne techniquement, envisagez d’utiliser une ressource Application Insights distincte pour les données de télémétrie côté navigateur/côté client comme meilleure pratique d’isolation des risques. L'instrumentation du navigateur s'exécute dans un environnement client non approuvé, de sorte que son chaîne de connexion est visible pour les utilisateurs et ne peut pas être traité comme un secret. Une chaîne de connexion exposée peut être utilisée pour envoyer des données de télémétrie usurpées, non pertinentes ou à volume élevé à la ressource associée, qui peuvent polluer les tableaux de bord, les alertes, les requêtes de dépannage et augmenter les coûts d’ingestion.

Une ressource de télémétrie de navigateur distincte peut vous aider à :

• Faites pivoter ou remplacez le chaîne de connexion côté navigateur sans perturber les données de télémétrie côté serveur.
• Contient une télémétrie usurpée, indésirable ou corrompue pour la ressource spécifique du navigateur.
• Protégez la qualité des données de télémétrie côté serveur utilisées pour les diagnostics, les alertes et l’analyse opérationnelle.
• Appliquez différents paramètres de contrôle d’accès, de propriété ou de gouvernance si nécessaire.

Mettez ces avantages en balance avec la charge de gestion supplémentaire liée à plusieurs ressources, notamment les chaînes de connexion supplémentaires, les attributions RBAC, la configuration et les investigations inter-ressources. La corrélation de bout en bout peut toujours fonctionner sur plusieurs ressources Application Insights lorsque l’utilisateur a accès aux ressources pertinentes. Pour plus d’informations, consultez La carte des applications et les diagnostics de transaction.

Private Link et l’authentification d’ingestion sont des contrôles distincts. Private Link contrôle l’accès réseau aux ressources Azure Monitor, tandis que l'authentification Microsoft Entra détermine si l’ingestion de télémétrie est autorisée par une identité. N'utilisez pas Private Link comme substitut de l'authentification d'ingestion et ne traitez pas la séparation des ressources comme une exigence pour l'ingestion côté serveur authentifiée.

Comment puis-je configurer une application web mondiale pour satisfaire aux exigences de conformité des données à l'échelle régionale ?

Pour répondre aux exigences de conformité des données régionales, utilisez des points de terminaison Application Insights régionaux au lieu du point de terminaison global. Le point de terminaison global ne garantit pas que les données restent dans une région spécifique. Les points de terminaison régionaux permettent de s’assurer que les données de télémétrie provenant d’utilisateurs dans des zones réglementées sont envoyées uniquement aux centres de données de ces régions.

Pour configurer votre application web globale pour la conformité régionale :

• Créez une ressource Application Insights par région avec des exigences de conformité strictes, telles que l’Union européenne ou le États-Unis.
• Créez une autre ressource Application Insights pour les utilisateurs de toutes les autres régions.
• Configurez votre application pour envoyer des données de télémétrie à la ressource Application Insights appropriée en fonction de la région de chaque utilisateur. Déterminez la région à l’aide de signaux tels que l’adresse IP, les métadonnées de compte ou les paramètres d’emplacement.
• Connectez toutes les ressources Application Insights à un espace de travail Log Analytics si vous avez besoin d’une expérience de requête unifiée entre les régions.

Par exemple:

• Envoyez des données des utilisateurs de la région A vers la ressource Application Insights de la région A en utilisant la chaîne de connexion de la région A.
• Envoyez les données des utilisateurs de la région B à la ressource Application Insights de la région B en utilisant la chaîne de connexion de la région B.
• Envoyez toutes les autres données utilisateur à une ressource Application Insights à usage général à l’aide d’une autre chaîne de connexion.

Important

L’utilisation du point de terminaison global ne garantit pas la conformité régionale. Pour répondre aux exigences de résidence des données, utilisez toujours des points de terminaison spécifiques à la région et routez les données de télémétrie en fonction de la région de l’utilisateur.

Le diagramme suivant montre un exemple de configuration pour une application web globale :

Où puis-je trouver plus d'informations sur les chaînes de connexion dans Application Insights ?

Pour plus d’informations, consultez Chaînes de connexion.

Création et configuration des ressources Application Insights

Comment déplacer une ressource Application Insights vers un autre emplacement ?

Le transfert de ressources Application Insights existant entre les régions n'est pas pris en charge. Par conséquent, vous ne pouvez pas migrer les données historiques vers une nouvelle région. La solution de contournement implique :

• Création d’une ressource Application Insights dans la région souhaitée.
• Recréer toutes les personnalisations uniques de la ressource d'origine dans la nouvelle ressource.
• Mise à jour de votre application avec la nouvelle ressource de région chaîne de connexion.
• des tests pour s'assurer que tout fonctionne comme prévu avec la nouvelle ressource Application Insights ;
• la prise de décision sur le fait de conserver ou de supprimer la ressource Application Insights d'origine. La suppression d'une ressource classique signifie perdre toutes les données historiques. Si la ressource est basée sur l’espace de travail, les données restent dans Log Analytics, ce qui permet access aux données historiques jusqu’à l’expiration de la période de rétention.

Les personnalisations uniques qui doivent généralement être recréées ou mises à jour manuellement pour la ressource dans la nouvelle région incluent, mais sans s’y limiter :

• Recréer des tableaux de bord et des classeurs personnalisés.
• Recréer ou mettre à jour l’étendue de toutes les alertes de journal/métrique personnalisées.
• Recréer des alertes de disponibilité.
• Recréez les paramètres de contrôle d'accès personnalisés Azure basés sur les rôles requis pour que vos utilisateurs aient accès à la nouvelle ressource.
• Répliquer les paramètres impliquant l’échantillonnage d’ingestion, la conservation des données, la limite quotidienne et l’activation des métriques personnalisées. Ces paramètres sont contrôlés via le volet Utilisation et coûts estimés.
• Toute intégration reposant sur des clés API telles que les annotations de version et les canaux de contrôle sécurisés des métriques en temps réel. Vous devez générer de nouvelles clés API et mettre à jour l’intégration associée.
• L’exportation continue dans les ressources classiques doit être reconfigurée.
• Les paramètres de diagnostic des ressources basées sur l’espace de travail doivent être reconfigurés.

Puis-je utiliser les fournisseurs('Microsoft.Insights', 'components').apiVersions[0] dans mes déploiements de Azure Resource Manager ?

Nous ne recommandons pas d’utiliser cette méthode pour renseigner la version de l’API. La version la plus récente peut représenter des versions préliminaires susceptibles de contenir des changements majeurs. Même avec les versions non préliminaires plus récentes, les versions d’API ne sont pas toujours compatibles avec les modèles existants. Dans certains cas, la version de l’API peut ne pas être disponible pour tous les abonnements.

Où puis-je trouver plus d'informations sur la création et la configuration des ressources Application Insights ?

Pour plus d'informations, consultez la section Créer et configurer les ressources Application Insights.

Modèle de données de télémétrie

Comment puis-je signaler des problèmes de modèle de données ou de schéma et des suggestions ?

Pour signaler des problèmes de modèle de données ou de schéma et des suggestions, utilisez notre référentiel GitHub.

Comment puis-je mesurer l’impact d’une campagne de surveillance ?

La télémétrie PageView inclut une URL et vous pouvez analyser le paramètre UTM en tirant parti d’une fonction regex dans Kusto.

Ces données peuvent parfois être manquantes ou inexactes si l’utilisateur ou l’entreprise désactive l’envoi de l’agent utilisateur dans les paramètres du navigateur. Les UA Parser regexes peuvent ne pas inclure toutes les informations d’appareil. Ou bien Application Insights n’a peut-être pas intégré les dernières mises à jour.

Pourquoi une mesure personnalisée réussit-elle sans erreur, sans pour autant que le journal s’affiche ?

Cela peut se produire si vous utilisez des valeurs de chaîne. Seules des valeurs numériques fonctionnent avec des mesures personnalisées.

Où puis-je trouver plus d'informations sur le modèle de données de télémétrie ?

Pour plus d’informations, consultez le Modèle de données de télémétrie d’Application Insights.

Journalisation avec .NET

Quel type de télémétrie Application Insights est produit à partir des journaux d’activité ILogger ? Où se trouvent les journaux ILogger dans Application Insights ?

Les enregistrements de journal OpenTelemetry sont stockés dans la traces table des journaux Application Insights. Pour les afficher dans le portail Azure, ouvrez votre ressource Application Insights, sélectionnez Logs et interrogez la table traces.

Exemple de requête : traces | where message contains "YourSearchTerm".

Comment puis-je personnaliser la collecte des journaux ILogger ?

Pour les applications .NET actuelles, configurez la collecte de journaux via OpenTelemetry et votre configuration standard de journalisation .NET. Utilisez Logging:LogLevel dans appsettings.json pour choisir les niveaux de journalisation des applications et configurer l’exportation du journal OpenTelemetry dans le cadre de la configuration d’OpenTelemetry pour Azure Monitor. Consultez Activer OpenTelemetry avec Application Insights et Modifier la télémétrie.

Pourquoi certains journaux ILogger n’ont-ils pas les mêmes propriétés que d’autres ?

Lorsque les journaux d’activité sont émis avant la fin de la configuration de la télémétrie d’application, ils peuvent avoir moins de propriétés enrichies que les journaux émis plus tard dans le cycle de vie de l’application.

Comment envoyer manuellement des données de télémétrie personnalisées ?

Pour l'instrumentation actuelle, envoyez des données de télémétrie personnalisées avec les API OpenTelemetry ou la distribution OpenTelemetry d'Azure Monitor. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Où puis-je obtenir plus d’informations sur la journalisation avec .NET ?

Pour l’instrumentation actuelle .NET, consultez Activer OpenTelemetry avec Application Insights.

Profileur Java

Qu’est-ce qu’Azure Monitor Application Insights pour le profilage Java ?

Le profileur Java utilise Java Flight Recorder (JFR) pour profiler votre application en utilisant une configuration personnalisée.

Qu’est-ce que Java Flight Recorder ?

Java Flight Recorder (JFR) est un outil permettant de collecter des données de profilage d’une application Java en cours d’exécution. JFR est intégré à la machine virtuelle Java (JVM) et sert à résoudre les problèmes de performances. En savoir plus sur le runtime Java SE JFR.

Quelles sont les implications en termes de prix et/ou de frais de licence pour l’activation du profilage Java sur Application Insights ?

Le profilage Java est une fonctionnalité gratuite d’Application Insights. La tarification d’Azure Monitor Application Insights est basée sur le coût d’ingestion.

Quelles informations de profilage Java sont collectées ?

Les données de profilage collectées par JFR incluent : les données de profilage de méthode et d’exécution, les données de garbage collection et les profils de verrouillage.

Comment puis-je utiliser le profilage de Java dans Application Insights et visualiser les données ?

L’enregistrement JFR peut être consulté et analysé avec votre outil préféré, par exemple Java Mission Control (JMC).

Les recommandations de diagnostic et de correction des performances sont-elles fournies avec le profilage de Java dans Application Insights ?

« Diagnostics et recommandations de performances » est une nouvelle fonctionnalité bientôt disponible en tant que diagnostics Java dans Application Insights. Vous pouvez vous inscrire pour afficher un aperçu de cette fonctionnalité. L’enregistrement JFR peut être consulté avec Java Mission Control (JMC).

Quelle est la différence entre le profilage Java à la demande et automatique dans Application Insights ?

Le profilage à la demande est déclenché par l’utilisateur en temps réel, tandis que le profilage automatique se fait avec des déclencheurs préconfigurés.

Utilisez Profile Now pour l’option de profilage à la demande. Profiler maintenant profile immédiatement tous les agents attachés à l’instance Application Insights.

Le profilage automatisé est déclenché quand le seuil d’une ressource est atteint.

Quels déclencheurs de profilage Java puis-je configurer ?

L’agent Java Application Insights prend actuellement en charge la surveillance de la consommation de processeur et de mémoire. Le seuil du processeur est configuré en pourcentage de tous les cœurs disponibles sur la machine. La mémoire est l’occupation actuelle de la région de mémoire foncière (OldGen) par rapport à la taille maximale possible de la région.

Quelles sont les conditions préalables requises pour activer le profilage Java ?

Passez en revue les prérequis.

Puis-je utiliser le profilage Java pour une application de microservices ?

Oui, vous pouvez profiler une machine virtuelle JVM exécutant des microservices à l’aide de JFR.

Où puis-je trouver plus d'informations sur Java Profiler ?

Pour plus d’informations, consultez l'Application Insights Profiler d’Azure Monitor pour Java.

Remplacement des paramètres d'échantillonnage - Application Insights pour Java

Dois-je utiliser une instrumentation manuelle pour activer les substitutions d'échantillonnage ?

Non, les substitutions d'échantillonnage sont désormais disponibles pour tous (GA) et peuvent être utilisées avec l'instrumentation automatique et l'instrumentation manuelle.

Comment configurer les remplacements d’échantillonnage lors de l’utilisation d’Azure App Service avec l’autoinstrumentation ?

Si vous utilisez l'autoinstrumentation, mettez à jour le fichier applicationinsights.json dans le portail Azure.

Est-il nécessaire de télécharger manuellement le fichier de l'agent Application Insights pour les substitutions d'échantillonnage ?

Pour l’instrumentation automatique, aucun chargement manuel d’agent n’est nécessaire. Toutefois, pour l’instrumentation manuelle, vous devez toujours inclure le fichier JAR de l’agent Application Insights et les fichiers de configuration dans votre package de déploiement.

Quelle est la différence entre « développement local » et « serveur d’applications » dans le contexte de l’instrumentation manuelle ?

Le développement local fait référence à l'environnement dans lequel l'application est générée ou testée, comme l'ordinateur d'un développeur ou une instance de Azure Cloud Shell. Le serveur d’applications fait référence au serveur web exécutant l’application, tel que Tomcat 11 dans un App Service environment Azure. Lorsque vous utilisez l’instrumentation manuelle, vous devez vous assurer que le fichier JAR de l’agent est correctement placé sur le serveur d’applications.

Si j'utilise un Azure App Service avec un environnement d'exécution Java (par exemple, Tomcat 11), comment puis-je configurer des modifications des paramètres d'échantillonnage ?

Pour l'instrumentation automatique, vous pouvez configurer les substitutions d'échantillonnage via le Portail Microsoft Azure. Si vous utilisez l’instrumentation manuelle, vous devez placer le fichier JAR de l’agent Application Insights dans le répertoire approprié et inclure le fichier applicationinsights.json avec vos paramètres d’échantillonnage souhaités.

Où puis-je trouver plus d'informations sur les substitutions d'échantillonnage ?

Pour plus d’informations, consultez Sampling overrides - Azure Monitor Application Insights pour Java.

Processeurs de télémétrie

Pourquoi le processeur de journaux ne traite-t-il pas les journaux en dehors de l’instrumentation OpenTelemetry ?

Les processeurs OpenTelemetry peuvent fonctionner avec des données de télémétrie qui transitent par le pipeline OpenTelemetry. Les journaux ou fichiers écrits en dehors de ce pipeline ne sont pas traités par les processeurs OpenTelemetry à moins que vous ne les collectiez explicitement.

Où puis-je trouver plus d'informations sur les processeurs de télémétrie ?

Pour plus d’informations, consultez Processeurs de télémétrie (version préliminaire) - Azure Monitor Application Insights pour Java.

Kit de développement logiciel (SDK) JavaScript

Que désignent les nombres d’utilisateurs et de sessions ?

• Le SDK JavaScript définit un cookie utilisateur sur le client web pour identifier les utilisateurs récurrents, ainsi qu’un cookie de session pour regrouper des activités.
• S’il n’existe aucun script côté client, vous pouvez définir des cookies sur le serveur.
• Si un utilisateur réel utilise votre site dans différents navigateurs, ou s’il utilise la navigation privée/incognito, ou encore différentes machines, il est comptabilisé plusieurs fois.
• Pour identifier un utilisateur connecté entre les ordinateurs et les navigateurs, utilisez le contexte utilisateur authentifié du Kit de développement logiciel (SDK) JavaScript ou définissez l’attribut OpenTelemetry enduser.id .

Quelle est la surcharge du SDK JavaScript ou quelles sont ses performances ?

Le SDK JavaScript Application Insights présente une surcharge minimale sur votre site web. Avec seulement 36 Ko compressés avec gzip et mettant environ 15 ms seulement pour s’initialiser, le SDK ajoute un temps de chargement négligeable à votre site web. Les composants minimaux de la bibliothèque sont rapidement chargés lorsque vous utilisez le SDK, et le script complet est téléchargé en arrière-plan.

En outre, pendant le téléchargement du script à partir du CDN, tout le suivi de votre page est mis en file d’attente, de sorte que vous ne perdez aucune télémétrie pendant tout le cycle de vie de votre page. Ce processus de configuration fournit à votre page un système d’analyse transparent, invisible à vos utilisateurs.

Quels sont les navigateurs pris en charge par le kit de développement logiciel (SDK) JavaScript ?

Chrome version la plus récente ✔	Firefox version la plus récente ✔	v3.x : IE 9+ et Microsoft Edge ✔ v2.x : IE 8+ Compatible et Microsoft Edge ✔	Opera version la plus récente ✔	Safari version la plus récente ✔

Où puis-je trouver des exemples de code pour le kit de développement logiciel (SDK) JavaScript ?

Pour obtenir des exemples exécutables, consultez Application Insights JavaScript SDK.

Quelle est la compatibilité ES3/Internet Explorer 8 avec le SDK JavaScript ?

Nous devons prendre les mesures nécessaires pour s’assurer que ce SDK continue à « fonctionner » et n’interrompt pas l’exécution de JavaScript lorsqu’il est chargé par un navigateur plus ancien. Il serait idéal de ne pas prendre en charge les navigateurs plus anciens, mais de nombreux clients importants ne peuvent pas contrôler le navigateur que leurs utilisateurs choisissent d’utiliser.

Cela ne signifie pas que nous ne prenons en charge que l’ensemble commun de fonctionnalités les plus faibles. Nous devons maintenir la compatibilité du code ES3. De nouvelles fonctionnalités doivent être ajoutées de manière à ne pas perturber l'analyse JavaScript ES3 et doivent être proposées en tant que fonctionnalités facultatives.

Consultez GitHub pour plus d’informations sur la prise en charge de Internet Explorer 8.

Le kit de développement logiciel (SDK) JavaScript est-il open source ?

Oui, le Kit de développement logiciel (SDK) JavaScript Application Insights est open source. Pour afficher le code source ou contribuer au project, consultez le référentiel official GitHub.

Où puis-je trouver plus d'informations sur le SDK JavaScript ?

Pour plus d’informations, consultez Activer Azure Monitor Application Insights Real User Monitoring.

Configuration du kit de développement logiciel (SDK) JavaScript

Comment mettre à jour ma configuration de serveur tiers pour le kit de développement logiciel (SDK) JavaScript ?

Le côté serveur doit être en mesure d’accepter les connexions avec ces en-têtes présents. Selon la configuration Access-Control-Allow-Headers côté serveur, il est souvent nécessaire d'étendre la liste côté serveur en ajoutant manuellement Request-Id, Request-Context et traceparent (en-tête distribué W3C).

Access-Control-Allow-Headers : Request-Id, traceparent, Request-Context, <your header>

Comment désactiver le suivi distribué pour le SDK JavaScript ?

Le suivi distribué peut être désactivé dans la configuration.

Les réponses HTTP 502 et 503 sont-elles toujours capturées par Application Insights ?

Non. Les erreurs « 502 Passerelle incorrecte » et « 503 Service indisponible » ne sont pas toujours capturées par Application Insights. Si seul le code JavaScript côté client est utilisé pour l’analyse, ce comportement est prévisible, car la réponse d’erreur est retournée avant la page contenant l’en-tête HTML avec l’extrait de code JavaScript d’analyse rendu.

Si la réponse 502 ou 503 a été envoyée à partir d’un serveur sur lequel l’analyse côté serveur est activée, les erreurs sont collectées par le Kit de développement logiciel (SDK) Application Insights.

Même lorsque l’analyse côté serveur est activée sur le serveur web d’une application, il arrive qu’une erreur 502 ou 503 ne soit pas capturée par Application Insights. De nombreux serveurs web modernes ne permettent pas à un client de communiquer directement. Au lieu de cela, ils utilisent des solutions telles que les proxys inverses pour transmettre des informations entre le client et les serveurs web frontaux.

Dans ce scénario, une réponse 502 ou 503 peut être renvoyée à un client en raison d’un problème au niveau de la couche de proxy inverse, de sorte qu’elle n’est pas capturée directement par Application Insights. Pour aider à détecter les problèmes au niveau de cette couche, vous devrez peut-être transférer les journaux de votre proxy inverse vers Log Analytics et créer une règle personnalisée pour vérifier les réponses 502 ou 503. Pour en savoir plus sur les causes courantes des erreurs 502 et 503, consultez Erreurs HTTP de « 502 mauvaise passerelle » et « 503 service indisponible » dans Azure App Service.

Où puis-je trouver plus d'informations sur la configuration du SDK JavaScript ?

Pour plus d'informations, consultez la configuration du SDK JavaScript d'Application Insights..

extensions du framework JavaScript

Comment Application Insights génère-t-il des informations sur les appareils telles que le navigateur, le système d’exploitation, la langue et le modèle ?

Le navigateur transmet la chaîne de l’agent utilisateur dans l’en-tête HTTP de la requête. Le service d’ingestion Application Insights utilise UA Parser pour générer les champs que vous voyez dans les tables de données et les expériences. Par conséquent, les utilisateurs d’Application Insights ne peuvent pas modifier ces champs.

Ces données peuvent parfois être manquantes ou inexactes si l’utilisateur ou l’entreprise désactive l’envoi de l’agent utilisateur dans les paramètres du navigateur. Les UA Parser regexes peuvent ne pas inclure toutes les informations d’appareil. Ou bien Application Insights n’a peut-être pas intégré les dernières mises à jour.

Où puis-je trouver plus d'informations sur les extensions du framework JavaScript ?

Pour plus d'informations, consultez la section Activer une extension de framework pour le kit de développement logiciel JavaScript Application Insights..

Espaces de travail managés

Dois-je mettre à jour des scripts ou une automatisation qui référencent des ressources classiques ?

Non. Les modèles ARM et les appels d’API existants continuent de fonctionner. Lorsque vous tentez de créer une ressource classique, une ressource basée sur un espace de travail avec un espace de travail managé est créée à la place.

Suis-je averti avant la migration de ma ressource ?

Non. La notification pour les migrations de ressources individuelles n’est pas disponible. Pour contrôler quand et comment vos ressources sont migrées, utilisez migration managée.

Combien de temps prend le processus de migration ?

Les migrations individuelles se terminent généralement en moins de deux minutes. Le déploiement complet se déroule sur plusieurs semaines dans toutes les régions.

Comment puis-je savoir si une ressource est migrée ?

Après la migration, la ressource est liée à un espace de travail Log Analytics sur la page Vue d’ensemble. L’avis de mise hors service classique est supprimé et le classeur de retraits ne répertorie plus la ressource.

Ma facturation va-t-elle changer après la migration ?

Les coûts restent généralement similaires. Application Insights basé sur l’espace de travail permet d’économiser des coûts et nous vous recommandons d’examiner les plans tarifaires.

Si vous utilisez un modèle de facturation hérité, consultez la documentation pricing pour plus d'informations.

Est-ce que je perds des alertes ou des tests de disponibilité pendant la migration ?

Non. Toutes les alertes, tableaux de bord et tests de disponibilité restent intacts et continuent à fonctionner après la migration.

Où puis-je trouver plus d'informations sur les espaces de travail gérés ?

Pour plus d'informations, consultez la section Espaces de travail gérés dans Application Insights..

Node.js

Comment puis-je désactiver la corrélation des données de télémétrie ?

Pour l’instrumentation actuelle, passez en revue la corrélation de suivi distribué et de télémétrie. Pour la télémétrie du navigateur JavaScript, consultez la configuration du Kit de développement logiciel (SDK) JavaScript.

Comment puis-je configurer le niveau de journal souhaité ?

Pour configurer le niveau de journal souhaité par Application Insights, utilisez la variable d’environnement APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . Les valeurs prises en charge sont NONE, ERROR, WARN, INFO, DEBUG, VERBOSE et ALL. Pour plus d’informations, consultez ApplicationInsights-node.js.

Où puis-je trouver plus d'informations sur la surveillance des services et applications Node.js avec Application Insights ?

Pour connaître l’instrumentation Node.js actuelle, consultez Activer OpenTelemetry avec Application Insights.

Azure Monitor OpenTelemetry (outil de surveillance de la performance des applications)

Où puis-je trouver la liste des versions du kit de développement logiciel (SDK) d’Application Insights ainsi que leurs noms ?

Une liste des versions et noms du SDK est hébergée sur GitHub. Pour plus d’informations, consultez SDK Version.

Où puis-je trouver plus d'informations sur OpenTelemetry ?

Pour plus d'informations, consultez la section Collecter des données de télémétrie avec OpenTelemetry dans Application Insights.

Migrer à partir du .NET SDK Application Insights vers Azure Monitor OpenTelemetry

Où puis-je obtenir des conseils sur la migration ?

Consultez la Migration des SDK d'Application Insights vers Azure Monitor OpenTelemetry. Conservez des conseils spécifiques à la migration sur cette page afin que les articles de configuration actuels puissent continuer à présenter un chemin d’accès OpenTelemetry recommandé.

Comment puis-je suivre manuellement les données de télémétrie à l'aide d'OpenTelemetry ?

Utilisez les API OpenTelemetry et les API de journalisation ou de métriques spécifiques au langage. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Échantillonnage OpenTelemetry

L’échantillonneur personnalisé Application Insights intervient-il en fin de workflow ?

L’échantillonneur personnalisé Application Insights prend des décisions d’échantillonnage après la création d’un segment plutôt qu’avant, donc il ne suit pas une approche traditionnelle d’intervention en début de workflow. Au lieu de cela, il applique des décisions d’échantillonnage à la fin de la génération d’un segment, c’est-à-dire une fois que le segment est complet, mais avant l’exportation.

Bien que ce comportement ressemble d’une certaine façon à un échantillonnage en fin de workflow, l’échantillonneur n’attend pas de collecter plusieurs segments à partir de la même trace pour décider. Au lieu de cela, il utilise un hachage de l’ID de trace pour garantir l’exhaustivité de la trace.

Cette approche équilibre l’exhaustivité et l’efficacité des traces et évite le coût plus élevé associé à l’échantillonnage complet basé sur la queue.

Pour prendre des décisions d’échantillonnage basées sur le résultat d’une trace entière (par exemple, déterminer si un segment au sein de la trace a échoué), un échantillonnage complet en fin de workflow est requis dans un agent ou un collecteur en aval. Cette fonctionnalité n'est actuellement pas prise en charge, mais vous pouvez la demander en tant que nouvelle fonctionnalité via le Feedback Hub.

Quelles sont les différences entre l’échantillonneur personnalisé Application Insights et l’échantillonnage en début ou en fin de workflow d’OpenTelemetry ?

Méthode d’échantillonnage	Point de décision	Points forts	Faiblesses
En début de workflow	Avant qu’un segment ne commence	Latence faible, surcharge minimale	Peut échantillonner les traces souhaitées, y compris les échecs
En fin de workflow	Une fois que les segments sont mis en mémoire tampon sur la base de seuils de durée ou de volume	Permet des critères d’échantillonnage de trace hautement sélectifs	Coût plus élevé et retard de traitement ajouté
Azure Monitor échantillonneur personnalisé	Fin de la génération d’un segment	Trouve l’équilibre entre les traces complètes et l’efficacité	Obligatoire pour la compatibilité des métriques actives

Puis-je échantillonner des dépendances, des demandes ou d’autres types de télémétrie à différents taux ?

Non, l’échantillonneur applique un taux fixe sur tous les types de télémétrie dans une trace. Les requêtes, dépendances et autres segments suivent le même pourcentage d’échantillonnage. Pour appliquer des taux différents par type de télémétrie, envisagez d’utiliser des processeurs de span OpenTelemetry ou des transformations au moment de l’ingestion (ingestion-time transformations)[app-insights-overview.md#telemetry-routing].

Comment l’échantillonneur personnalisé Application Insights propage-t-il les décisions d’échantillonnage ?

L’échantillonneur personnalisé Application Insights propage les décisions d’échantillonnage à l’aide de la norme de contexte de trace W3C par défaut. Cette norme permet aux décisions d’échantillonnage de circuler entre les services. Toutefois, étant donné que l’échantillonneur prend des décisions d’échantillonnage à la fin de la génération d’un segment (après l’appel aux services en aval), la propagation comporte des informations d’échantillonnage incomplètes. Cette limitation est conforme à la spécification de contexte de trace W3C, mais les services en aval ne peuvent pas utiliser de manière fiable cette décision d’échantillonnage propagée.

L’échantillonneur personnalisé Application Insights respecte-t-il les décisions d’échantillonnage des services en amont ?

Non, l’échantillonneur personnalisé Application Insights prend toujours une décision d’échantillonnage indépendante, même si le service en amont utilise le même algorithme d’échantillonnage. Les décisions d'échantillonnage des services en amont, y compris celles qui utilisent des en-têtes de contexte de traçage W3C, n'influencent pas la décision du service en aval. Toutefois, il effectue un échantillonnage à partir d’un hachage de l’ID de trace pour s’assurer que la trace est complète. Pour améliorer la cohérence et réduire le risque de traces interrompues, configurez tous les composants du système pour utiliser le même échantillonneur et le même taux d’échantillonnage.

Pourquoi certaines traces apparaissent-elles incomplètes même lors de l’utilisation de l’échantillonneur personnalisé Application Insights ?

Il existe plusieurs raisons pour lesquelles les traces peuvent apparaître incomplètes :

• Différents nœuds d’un système distribué utilisent différentes approches d’échantillonnage qui ne coordonnent pas les décisions. Par exemple, un nœud applique l’échantillonnage basé sur la tête OpenTelemetry, et un autre nœud applique l’échantillonnage via l’échantillonneur personnalisé Azure Monitor.
• Différents nœuds sont définis sur des taux d’échantillonnage différents, même s’ils utilisent la même approche d’échantillonnage.
• Vous définissez des limites de filtrage, d'échantillonnage ou de débit dans le pipeline côté serveur, et cette configuration échantillonne de manière aléatoire des traces sans tenir compte de leur exhaustivité.

Si un composant applique un échantillonnage en début de workflow sans propager la décision d’échantillonnage (via les en-têtes de contexte de trace W3C), les services en aval échantillonnent la trace indépendamment, ce qui peut aboutir à l’abandon de segments. Par conséquent, certaines parties de la trace ne sont pas toujours disponibles lorsqu’elles sont consultées dans Application Insights.

Comment l’échantillonneur personnalisé Application Insights fonctionne-t-il en même temps que l’échantillonnage d’ingestion ?

L'échantillonnage d'ingestion ne supprime que ce qui atteint le service ; il ne peut donc pas contrecarrer ni remplacer les décisions de l'échantillonneur personnalisé d'Application Insights. Si les deux sont activés, le taux effectif est multiplié. Par exemple, un taux de SDK de 20 % combiné à un taux d’ingestion de 50 % entraîne environ 10 % des données stockées. Microsoft recommande d’effectuer l’échantillonnage à la source avec l’échantillonneur OpenTelemetry Azure Monitor pour conserver les traces intactes et prévisibles, et d’utiliser l’échantillonnage d’ingestion uniquement comme secours.

Où puis-je trouver plus d'informations sur l'échantillonnage OpenTelemetry ?

Pour plus d’informations, consultez Sampling dans Azure Monitor Application Insights avec OpenTelemetry.

Assistance et commentaires sur OpenTelemetry

Qu’est-ce qu’OpenTelemetry ?

Il s'agit d'une norme open source pour l'observabilité. Pour en savoir plus, rendez-vous sur OpenTelemetry.

Pourquoi Microsoft Azure Monitor investit-il dans OpenTelemetry ?

Microsoft investit dans OpenTelemetry pour les raisons suivantes :

• Cette solution est indépendante des fournisseurs et fournit des API/SDK homogènes dans toutes les langues.
• Au fil du temps, nous pensons qu’OpenTelemetry permettra aux clients Azure Monitor d’observer les applications écrites dans des langages au-delà de nos langages pris en charge.
• Elle permet de recueillir un plus grand nombre de données grâce à un ensemble complet de bibliothèques d’instrumentation.
• Les kits de développement logiciel OpenTelemetry (SDK) sont conçus pour une télémétrie efficace et neutre vis-à-vis des fournisseurs à grande échelle.
• OpenTelemetry s'aligne sur la stratégie de Microsoft pour embrace open source.

Quel est l’état d’OpenTelemetry ?

Consultez l’état d’OpenTelemetry.

Qu'est-ce qu'Azure Monitor OpenTelemetry Distro ?

Vous pouvez le considérer comme un wrapper mince qui regroupe tous les composants OpenTelemetry pour une expérience de première classe sur Azure. Ce wrapper est également appelé une distribution dans OpenTelemetry.

Pourquoi dois-je utiliser la distribution OpenTelemetry Azure Monitor ?

Il existe plusieurs avantages à l'utilisation de la distribution Azure Monitor OpenTelemetry par rapport à OpenTelemetry d'origine de la communauté :

• Réduit l’effort d’activation
• Prise en charge par Microsoft
• Apporte des fonctionnalités spécifiques à Azure telles que :
  • L’échantillonnage compatible avec les kits SDK Application Insights classiques
  • Authentification Microsoft Entra
  • Stockage hors ligne et reprises automatiques
  • Métriques standard d'Application Insights
  • Détecter les métadonnées de ressource pour remplir automatiquement le nom du rôle cloud et l’instance de rôle cloud dans différents environnements Azure
  • Métriques temps réel

Dans l’esprit d’OpenTelemetry, nous avons conçu la distribution pour qu’elle soit ouverte et extensible. Par exemple, vous pouvez ajouter :

• Un exportateur OTLP (OpenTelemetry Protocol) et l’envoi vers une seconde destination simultanément
• Autres bibliothèques d’instrumentation non incluses dans la distribution

Étant donné que la distribution fournit une distribution OpenTelemetry, la distribution prend en charge tout ce qui est pris en charge par OpenTelemetry. Par exemple, vous pouvez ajouter d’autres processeurs de télémétrie, exportateurs ou bibliothèques d’instrumentation si OpenTelemetry les prend en charge.

Pour les langues sans exportateur OpenTelemetry autonome pris en charge, la distribution openTelemetry Azure Monitor est la seule méthode actuellement prise en charge pour utiliser OpenTelemetry avec Azure Monitor. Pour les langues avec un exportateur OpenTelemetry autonome pris en charge, vous avez la possibilité d’utiliser la distribution Azure Monitor OpenTelemetry ou l’exportateur OpenTelemetry autonome approprié en fonction de votre scénario de télémétrie. Pour plus d’informations, consultez Quand dois-je utiliser l’exportateur OpenTelemetry Azure Monitor ?.

Dois-je utiliser OpenTelemetry pour les nouveaux projets Application Insights ?

Oui. Nous vous recommandons d’utiliser Azure Monitor Distro OpenTelemetry pour les nouveaux projets.

Si vous migrez une application .NET ou Node.js existante à partir de kits SDK Application Insights plus anciens, consultez Migration des kits SDK Application Insights vers Azure Monitor OpenTelemetry.

Quand dois-je utiliser l’exportateur OpenTelemetry Azure Monitor ?

Pour ASP.NET Core, Java, Node.jset Python, nous vous recommandons d’utiliser la distribution OpenTelemetry Azure Monitor. Il suffit d'une ligne de code pour commencer.

Pour tous les autres scénarios de .NET, notamment ASP.NET classique, applications console, Windows Forms (WinForms), etc., nous vous recommandons d’utiliser l’exportateur openTelemetry .NET Azure Monitor : Azure.Monitor.OpenTelemetry.Exporter.

Pour les scénarios de télémétrie Python plus complexes nécessitant une configuration avancée, nous vous recommandons d’utiliser python Azure Monitor OpenTelemetry Exporter.

Quel est l'état de publication actuel des fonctionnalités de la distribution OpenTelemetry d'Azure Monitor ?

La distribution OpenTelemetry d'Azure Monitor prend en charge le chemin d'instrumentation recommandé actuel d'Application Insights.

Pour plus d’informations sur les expériences d'analyse de code, consultez .NET Profiler et Snapshot Debugger.

OpenTelemetry peut-il être utilisé pour les navigateurs web ?

Oui, mais nous ne le recommandons pas et Azure ne le prend pas en charge. OpenTelemetry JavaScript est fortement optimisé pour Node.js. Au lieu de cela, nous vous recommandons d’utiliser le Kit de développement logiciel (SDK) JavaScript Application Insights.

Quand pouvons-nous nous attendre à ce que le Kit de développement logiciel (SDK) OpenTelemetry soit disponible pour être utilisé dans les navigateurs web ?

Le SDK web OpenTelemetry n’a pas de planning de disponibilité défini. Il faudra probablement attendre encore plusieurs années avant qu’un SDK pour navigateur ne constitue une alternative viable au SDK JavaScript d’Application Insights.

Puis-je tester OpenTelemetry dans un navigateur web aujourd’hui ?

Le bac à sable web OpenTelemetry est un fork conçu pour faire fonctionner OpenTelemetry dans un navigateur. Il n’est pas encore possible d’envoyer des données de télémétrie à Application Insights. Le SDK ne définit pas d’événements clients d’ordre général.

L’exécution d’Application Insights avec les agents concurrents tels que AppDynamics, DataDog et NewRelic est-elle prise en charge ?

Cette pratique n'est pas quelque chose que nous prévoyons de tester ou de prendre en charge, bien que nos distributions vous permettent de exporter vers un point de terminaison OTLP parallèlement à Azure Monitor simultanément.

Puis-je utiliser les fonctionnalités d’évaluation dans les environnements de production ?

Nous ne le recommandons pas. Consultez Conditions d'utilisation supplémentaires pour les préversions de Microsoft Azure.

Est-il possible d’utiliser le collecteur OpenTelemetry ?

Certains clients utilisent le collecteur OpenTelemetry comme agent de substitution, même si Microsoft ne prend pas encore officiellement en charge une approche basée sur un agent pour la surveillance d’applications. En attendant, la communauté open source a contribué à un OpenTelemetry Collector Azure Monitor Exporter que certains clients utilisent pour envoyer des données à Azure Monitor Application Insights. Ce n’est pas pris en charge par Microsoft.

Dans Grafana, pourquoi est-ce que je vois « Statut 500 » ? Impossible de visualiser les événements de trace à l'aide du visualiseur de trace ?

Vous essayez peut-être de visualiser des journaux en texte brut plutôt que des traces OpenTelemetry.

Dans Application Insights, la table « Traces » stocke les journaux en texte brut à des fins de diagnostic. Elle permet d’identifier et de mettre en corrélation les traces associées aux demandes utilisateur, à d’autres événements et aux rapports d’exceptions. Cependant, la table « Traces » ne contribue pas directement à la vue des transactions de bout en bout (graphique en cascade) dans des outils de visualisation comme Grafana.

Avec l’adoption croissante des pratiques natives cloud, la collecte et la terminologie des données de télémétrie évoluent. OpenTelemetry est désormais la norme en matière de collecte et d’instrumentation des données de télémétrie. Dans ce contexte, le terme « Traces » prend un nouveau sens. Au lieu de désigner des journaux bruts, « Traces » dans OpenTelemetry fait référence à une forme de télémétrie plus riche et structurée qui inclut des étendues représentant des unités de travail individuelles. Ces étendues sont essentielles pour construire des vues de transaction détaillées, améliorant ainsi le monitoring et les diagnostics des applications natives cloud.

Comment puis-je instrumenter Blazor Apps ?

Pour instrumenter une application Blazor, identifiez d’abord le modèle d’hébergement. Blazor Server prend en charge l’instrumentation complète basée sur OpenTelemetry. Blazor WebAssembly s’exécute dans le navigateur et prend en charge une instrumentation limitée via JavaScript.

Vue d’ensemble du tableau de bord

Puis-je afficher plus de 30 jours de données ?

Non, les données affichées dans un tableau de bord sont limitées à 30 jours.

Je vois une erreur « ressource introuvable » sur le tableau de bord.

Ce type d’erreur peut survenir si vous déplacez ou renommez votre instance Application Insights.

Pour contourner ce comportement, supprimez le tableau de bord par défaut et sélectionnez de nouveau Tableau de bord d’application pour en créer un nouveau.

Où puis-je trouver plus d'informations sur le tableau de bord Vue d'ensemble ?

Pour plus d’informations, consultez Tableau de bord Vue d’ensemble d’Application Insights.

Canaux de télémétrie

Application Insights garantit-elle la remise des données de télémétrie ?

Les exportateurs OpenTelemetry et les SDK utilisent généralement une méthode de livraison basée sur le meilleur effort. Les données de télémétrie peuvent toujours être perdues si une application se bloque, que le processus se termine avant l’exportation des données de télémétrie en attente, que le stockage n’est pas disponible ou que les pannes de réseau et de service ne dépassent pas les limites de nouvelle tentative. Pour connaître le comportement actuel d’OpenTelemetry, consultez stockage hors connexion et nouvelles tentatives automatiques.

Le Kit de développement logiciel (SDK) crée-t-il un storage local temporaire ? Les données sont-elles chiffrées lors du stockage ?

Certains exportateurs et SDK actuels peuvent créer un stockage local temporaire en cas de problèmes de réseau ou de limitation. Le stockage temporaire local n’est pas chiffré par Application Insights. Par conséquent, sécurisez tout répertoire que vous configurez. Pour connaître le comportement actuel d’OpenTelemetry, consultez stockage hors connexion et nouvelles tentatives automatiques.

Où puis-je obtenir plus d’informations sur le comportement de remise des données de télémétrie ?

Pour connaître le comportement actuel des nouvelles tentatives et du stockage OpenTelemetry, consultez la configuration d’OpenTelemetry.

Rechercher

Quelle est la quantité de données conservée ?

Consultez le résumé des limites.

Comment puis-je consulter les données POST dans mes demandes serveur ?

Nous ne journalisons pas automatiquement les données POST. Utilisez soigneusement la journalisation des applications si vous devez capturer les détails du corps de la demande et éviter de collecter des données sensibles.

Pourquoi ma recherche de fonction Azure ne retourne-t-elle aucun résultat ?

Azure Functions ne journalise pas les chaînes de requête d'URL.

Où puis-je obtenir plus d’informations sur la recherche ?

Pour plus d’informations, consultez Recherche et diagnostics.

Diagnostic des transactions

Pourquoi est-ce que je vois un composant unique sur le graphique et pourquoi les autres composants s’affichent uniquement en tant que dépendances externes sans aucun détail ?

Raisons possibles :

• Les autres composants sont-ils instrumentés avec Application Insights ?
• Utilisent-ils le dernier Kit de développement logiciel (SDK) d’Application Insights stable ?
• Si ces composants sont des ressources Application Insights distinctes, vérifiez que vous avez access. Si vous avez accès et que les composants sont instrumentés avec les derniers SDK Application Insights, faites-le-nous savoir via le canal de commentaires dans le coin supérieur droit.

Je vois des lignes en double pour les dépendances. Ce comportement est-il attendu ?

Actuellement, nous présentons l’appel de dépendance sortant séparément de la demande entrante. En règle générale, les deux appels semblent identiques, seule la valeur de durée est différente en raison de l’aller-retour réseau. L’icône de début et le style distinct des barres de durée permettent de les différencier. Cette présentation des données porte-t-elle à confusion ? Faites-nous part de vos commentaires !

Qu’en est-il des décalages d’horloge entre les différentes instances de composants ?

Les chronologies sont ajustées pour les variations d’horloges dans le graphique de transaction. Vous pouvez voir les timestamps exacts dans le volet d’informations ou à l’aide de Log Analytics.

Pourquoi la nouvelle interface ne propose-t-elle pas la plupart des requêtes relatives aux articles associés ?

Ce comportement est voulu. Tous les éléments associés, sur tous les composants, sont déjà disponibles sur le côté gauche dans les sections supérieure et inférieure. La nouvelle expérience comporte deux éléments associés non couverts par le côté gauche : l’ensemble de la télémétrie cinq minutes avant et après cet événement et la chronologie utilisateur.

Existe-t-il un moyen de voir moins d’événements par transaction quand j’utilise le SDK JavaScript Application Insights ?

L’expérience de diagnostic des transactions affiche toutes les données de télémétrie dans une seule opération qui partage un ID d’opération. Par défaut, le SDK Application Insights pour JavaScript crée une opération pour chaque vue de page unique. Dans une application monopage (SPA), un seul événement de visualisation de page sera généré et un seul ID d’opération sera utilisé pour toute la télémétrie générée. Par conséquent, de nombreux événements peuvent être corrélés à la même opération.

Dans ces scénarios, vous pouvez utiliser le suivi automatique des itinéraires pour créer automatiquement de nouvelles opérations pour la navigation dans votre application monopage. Vous devez activerAutoRouteTracking pour qu’une vue de page soit générée chaque fois que l’itinéraire d’URL est mis à jour (affichage de page logique). Si vous voulez actualiser manuellement l’ID de l’opération, appelez appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Le déclenchement manuel d’un événement PageView réinitialise également l’ID d’opération.

Pourquoi la durée des détails des transactions ne correspond-elle pas à la durée de la requête principale ?

Le temps non expliqué dans le diagramme de Gantt, est le temps qui n’est pas couvert par une dépendance suivie. Ce problème peut se produire car les appels externes n’ont pas été instrumentés, automatiquement ou manuellement. Cela peut également se produire parce que le traitement a pris du temps plutôt qu’en raison d’un appel externe.

Si tous les appels ont été instrumentés, dans le processus, il s’agit de la cause racine probable du temps passé. Un outil utile pour diagnostiquer le processus est le .NET Profiler.

Que se passe-t-il si le message « Erreur lors de la récupération des données » s’affiche lors de la navigation dans Application Insights dans le Azure portal ?

Cette erreur indique que le navigateur n’a pas pu appeler une API requise ou que l’API a retourné une réponse d’échec. Pour résoudre les problèmes de comportement, ouvrez une fenêtre InPrivate du navigateur et désactivez les extensions de navigateur en cours d’exécution, puis identifiez si vous pouvez toujours reproduire le comportement du portail. Si l’erreur du portail se produit toujours, essayez de tester avec d’autres navigateurs ou d’autres ordinateurs, examinez le DNS ou les éventuels autres problèmes liés au réseau à partir de l’ordinateur client où les appels d’API échouent. Si l’erreur du portail se poursuit et a besoin d’un examen plus approfondi, collectez une trace réseau de navigateur lors de la reproduction du comportement inattendu du portail, puis ouvrez un cas de support à partir du Azure portal.

Où puis-je trouver plus d'informations sur les diagnostics de transaction ?

Pour plus d’informations, consultez Examiner les échecs, les performances et les transactions avec Application Insights.

Analyse de l’utilisation

L’événement initial représente-t-il la première fois que l’événement apparaît dans une session ou chaque fois qu’il apparaît dans une session ?

L’événement initial sur la visualisation représente uniquement la première fois qu’un utilisateur a envoyé cette page consultée ou cet événement personnalisé au cours d’une session. Si les utilisateurs peuvent envoyer l’événement initial plusieurs fois pendant une session, la colonne Étape 1 affiche uniquement le comportement des utilisateurs après la première instance de l’événement initial, et non pas toutes les instances.

Certains nœuds de ma visualisation ont un niveau trop élevé. Comment puis-je obtenir des nœuds plus détaillés ?

Utilisez les options Fractionner par dans le menu Modifier :

1. Sélectionnez l’événement que vous voulez décomposer dans le menu Événement.

2. Sélectionnez une dimension dans le menu Dimension . Par exemple, si vous disposez d’un événement appelé Bouton cliqué, essayez une propriété personnalisée appelée Nom du bouton.

J’ai défini une cohorte d’utilisateurs d’un pays/d’une région. Lorsque je la compare dans l’outil Utilisateurs à la définition d’un filtre sur ce pays/cette région, pourquoi est-ce que j’obtiens des résultats différents ?

Les cohortes et les filtres sont différents. Supposons que vous ayez une cohorte d’utilisateurs du Royaume-Uni (définie comme dans l’exemple précédent) et que vous compariez ses résultats à ceux obtenus avec le filtre Country or region = United Kingdom :

• La version cohorte affiche tous les événements des utilisateurs qui ont envoyé au moins un événement au Royaume-Uni pendant la période. Si vous fractionnez les données par pays ou région, vous verrez probablement de nombreux pays et régions.

• La version filtre n’affiche que les événements du Royaume-Uni. Si vous fractionnez les données par pays ou par région, vous ne voyez que celles du Royaume-Uni.

Comment puis-je afficher les données à différents niveaux de détail (quotidien, mensuel ou hebdomadaire) ?

Vous pouvez sélectionner le filtre Fragment de date pour modifier le grain. Le filtre est disponible dans tous les onglets de dimension.

Comment puis-je accéder aux aperçus de mon application qui ne sont pas disponibles sur les classeurs HEART ?

Vous pouvez examiner les données qui alimentent le classeur HEART si les visuels ne répondent pas à toutes vos questions. To do cette tâche, sous la section Monitoring dans Application Insights, sélectionnez Logs et interrogez la table customEvents. Certains attributs de Click Analytics sont contenus dans le champ customDimensions.

Voici un exemple de requête :

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Pour en savoir plus sur les journaux dans Azure Monitor, consultez Aperçu des journaux Azure Monitor.

Puis-je modifier des éléments visuels dans le classeur ?

Oui. Pour savoir comment modifier des modèles de classeur, consultez Azure modèles classeurs.

Où puis-je trouver plus d'informations sur l'analyse de l'utilisation ?

Pour plus d'informations, consultez la section Analyse de l'utilisation avec Application Insights.

Applications des services aux travailleurs

Quel package utiliser ?

Pour les applications de service worker actuelles, utilisez le Azure Monitor OpenTelemetry Exporter ou Distro. Consultez Activer OpenTelemetry avec Application Insights.

Comment puis-je suivre les données de télémétrie qui ne sont pas automatiquement collectées ?

Pour l’instrumentation actuelle, utilisez les API OpenTelemetry et les API de journalisation ou de métriques spécifiques au langage. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Pour les événements personnalisés du navigateur, utilisez le Kit de développement logiciel (SDK) JavaScript Application Insights ou Click Analytics. Pour les événements personnalisés côté serveur, utilisez des événements personnalisés OpenTelemetry.

Puis-je activer la surveillance Application Insights sans modifier le code d’application ?

Pour la surveillance des nouvelles applications, utilisez la distribution Azure Monitor OpenTelemetry ou les chemins d’auto-instrumentation actuels. Consultez Activer OpenTelemetry avec Application Insights et l’analyse des applications sans modification du code.

Si j’exécute mon application sous Linux, toutes les fonctionnalités sont-elles prises en charge ?

La prise en charge des fonctionnalités dépend du langage, de l’environnement d’hébergement et du chemin d’instrumentation. Pour obtenir la prise en charge actuelle, commencez par Activer OpenTelemetry avec Application Insights et l’article de configuration spécifique au langage approprié.

Où puis-je trouver plus d'informations sur les applications de service aux travailleurs ?

Pour l’instrumentation actuelle des services des travailleurs, voir Activer OpenTelemetry with Application Insights.

FAQ officielle pour Azure Monitor Application Insights. Trouvez des réponses aux questions sur l’utilisation d’Application Insights avec Azure Monitor.

Pour plus d’informations sur l’instrumentation des applications, afin d’activer Application Insights, consultez les principes de base de la collecte de données.

Après avoir activé Application Insights en instrumentant une application, nous vous suggérons de commencer par consulter les métriques en direct et la carte de l'application.

À partir des applications web du serveur :

• Requêtes HTTP.
• Dépendances telles que SQL, HTTP, Azure Cosmos DB, Azure Table Storage, Stockage Blob Azure et appels Stockage File d'attente Azure.
• Exceptions et traces de pile.
• Métriques d’exécution à partir de l’instrumentation prise en charge.
• Événements et métriques personnalisés que vous envoyez à l’aide de la télémétrie personnalisée OpenTelemetry, du Kit de développement logiciel (SDK) JavaScript ou de Click Analytics.
• Journaux d’activité de suivi si vous configurez le collecteur approprié.

À partir des pages web du client :

• Exceptions non interceptées dans votre application, y compris des informations sur

  • Arborescence des appels de procédure
  • Détails de l’exception et message accompagnant l’erreur
  • Numéros de ligne et de colonne de l’erreur
  • URL où l’erreur a été générée
  • Les demandes de dépendance réseau effectuées par vos requêtes HTTP XML (XHR) d’application et Fetch (la collecte d’extraction est désactivée par défaut), incluent des informations sur :
    • URL de la source de dépendance
    • Commande et méthode utilisées pour demander la dépendance
    • Durée de la demande
    • Code de résultat et état de réussite de la demande
    • ID (le cas échéant) de l’utilisateur qui effectue la demande
    • Contexte de corrélation (le cas échéant) dans lequel la demande est effectuée

• Informations utilisateur (par exemple, emplacement, réseau, adresse IP)

• Informations sur l’appareil (par exemple, le navigateur, le système d’exploitation, la version, la langue ou le modèle)

• Informations de session

  Remarque

  Pour certaines applications, telles que les applications SPA (Single Page Applications), la durée n'est pas toujours enregistrée et, dans ces cas, elle est par défaut à 0.

  Pour plus d’informations, consultez collecte, rétention et stockage des données dans Application Insights.

À partir d’autres sources, si vous les configurez :

• Azure Diagnostics
• Importer dans Log Analytics
• Log Analytics
• Logstash

Lorsque vous utilisez des frameworks de journalisation comme Serilog, les messages de journal sont ingérés par Application Insights en tant que données de télémétrie de trace et stockés dans la traces table (ou AppTraces dans Log Analytics). Cela est par conception, étant donné que les tables telles que requests, dependencieset exceptions sont réservées à leurs types de données de télémétrie respectifs.

Pour plus d’informations, consultez le modèle de données de télémétrie Application Insights.

Pour comprendre le nombre de ressources Application Insights requises pour couvrir vos applications ou composants entre les environnements, consultez le guide de planification du déploiement Application Insights.

Vous pouvez écrire des scripts PowerShell à l’aide d'Azure Resource Monitor pour :

• Créer et mettre à jour des ressources Application Insights.
• Définir le plan de tarification.
• Obtenez le chaîne de connexion.
• Ajouter une alerte métrique.
• Ajouter un test de disponibilité.

Vous ne pouvez pas définir un rapport de l’explorateur de métriques ou une exportation continue.

Utilisez l’API REST pour exécuter des requêtes Log Analytics.

Nous vous recommandons Azure Monitor OpenTelemetry Distro.

Le schéma d'ingestion et le protocole de point de terminaison sont disponibles publiquement.

La plupart des données Application Insights ont une latence de moins de 5 minutes. Certaines données peuvent prendre plus de temps, ce qui est courant pour les fichiers journaux plus volumineux. Consultez le contrat de niveau de service Application Insights.

Application Insights est facturé via l'espace de travail Log Analytics dans lequel ses données de journal sont importées. Le niveau tarifaire Log Analytics par défaut avec paiement à l’utilisation comprend 5 Go par mois d’allocation de données gratuite par compte de facturation. Découvrez les options de tarification des journaux d’activité d’Azure Monitor.

• Si votre application web Azure est hébergée dans un centre de données où il existe un point de terminaison de collection Application Insights, il n'y a aucun frais.
• S'il n'existe aucun point de terminaison de collecte dans votre centre de données hôte, la télémétrie de votre application entraîne des frais de sortie Azure.

Cette réponse dépend de la distribution de nos points de terminaison, et non pas de l’endroit où votre ressource Application Insights est hébergée.

Oui, vous pouvez encourir des frais de réseau supplémentaires qui varient en fonction de la région d'où provient la télémétrie et de sa destination. Pour plus d’informations, consultez Azure tarification de la bande passante.

Si vous voyez des frais inattendus ou des coûts élevés dans Application Insights, ce guide peut vous aider. Il couvre les causes courantes telles que le volume de télémétrie élevé, les pics d’ingestion de données et l’échantillonnage mal configuré. Il est particulièrement utile si vous résolvez des problèmes liés aux pics de coûts, au volume de télémétrie, à l’échantillonnage qui ne fonctionne pas, aux limites de données, à l’ingestion élevée ou à la facturation inattendue. Pour démarrer, consultez la section « Dépannage d’un volume élevé d’ingestion de données » dans Application Insights.

Application Insights utilise TLS (Transport Layer Security) 1.2 et 1.3.

Pour toute question d’ordre général concernant le problème lié à l’ancienne version de TLS, consultez les articles Résolution des problèmes TLS et Prise en charge de TLS par Azure Resource Manager.

Pour plus d’informations, consultez Présentation d’Application Insights.

Contexte

Application Insights collecte les données de télémétrie à partir de votre application et les stocke dans un espace de travail Log Analytics. Il fonctionne pour les applications hébergées n’importe où, non seulement dans Azure.

Ce qui est collecté et d'où

La télémétrie provient de : (1) le Kit de développement logiciel (SDK) que vous ajoutez à votre application, y compris les données de télémétrie personnalisées que vous envoyez, les agents serveur facultatifs (2) et (3) les tests de disponibilité exécutés par Microsoft. Les données classiques incluent les requêtes, les dépendances, les exceptions et les incidents, les compteurs de performances, le contexte du client et du serveur, les traces et tous les événements ou métriques personnalisés que vous envoyez. Pour vérifier ce qui est envoyé, exécutez votre application en mode débogage et vérifiez les fenêtres Sortie ou Diagnostics de votre IDE. Pour les pages web, ouvrez votre navigateur developer tools et inspectez l’onglet Réseau. Vous pouvez filtrer ou enrichir les données de télémétrie avant d’être envoyées en implémentant un processeur de télémétrie.

Rétention et stockage

La conservation des données brutes peut être définie sur 30, 60, 90, 120, 180, 270, 365, 550 ou 730 jours. La rétention au-delà de 90 jours peut entraîner des frais supplémentaires. Les métriques agrégées sont conservées à une granularité de 1 minute pendant 90 jours. Les instantanés de débogage sont conservés pendant 15 jours. Les données sont stockées dans la région que vous choisissez lors de la création de la ressource. La télémétrie est immuable après l’ingestion. Vous ne pouvez pas modifier les données de télémétrie. Le vidage est disponible pour supprimer des données si nécessaire.

Access, la sécurité et le chiffrement

Les données sont visibles pour vous et vos collègues avec access et peuvent être exportées. Microsoft utilise vos données uniquement pour fournir au service des access de personnel restreint et peut utiliser des statistiques agrégées pour améliorer le service. Les données de télémétrie sont envoyées via HTTPS et les données sont chiffrées au repos et se déplacent entre les centres de données.

Confidentialité et utilisation responsable

Les modules sdk par défaut se concentrent sur les performances, l’utilisation et les diagnostics, et n’incluent généralement pas de données personnelles sensibles. Ne placez pas de données sensibles dans des URL. Passez en revue les données de télémétrie personnalisées afin qu’elles n’incluent pas de données personnelles. L’adresse IP du client est utilisée pour la géolocalisation, puis le champ IP stocké est zéro par défaut. Si vous avez besoin de masquage, ajoutez un initialiseur de télémétrie. Si votre application a besoin d’une désactivation, désactivez la collecte dans le code. Passez également en revue les champs apparemment innocues, par exemple le nom de l’appareil sur les appareils personnels. Vous pouvez contrôler ou désactiver une collection dans la configuration ou via du code. Pour plus d’informations, consultez Gestion de la géolocalisation et des adresses IP.

TLS

Utilisez TLS moderne pour les données en transit. Ne codez pas en dur les versions antérieures du protocole. Autorisez la plateforme à négocier des versions plus récentes dès qu’elles deviennent disponibles. Pour plus d’informations, consultez Secure your Azure Monitor deployment.

Mise en mémoire tampon locale et interruptions de service

Si la connectivité à Azure est perdue ou limitée, les exportateurs OpenTelemetry pris en charge et les kits SDK actuels peuvent mettre en mémoire tampon les données de télémétrie localement et réessayer. Pour connaître le comportement actuel d’OpenTelemetry, consultez stockage hors connexion et nouvelles tentatives automatiques. Pour connaître les paramètres de mise en mémoire tampon du navigateur, consultez la configuration du Kit de développement logiciel (SDK) JavaScript.

Dans de nombreux cas, Application Insights collecte automatiquement des données sur l’utilisation du produit pour Microsoft. Ces données sont stockées dans un magasin de données Microsoft et n’affectent pas le volume et le coût de surveillance des clients. Application Insights collecte les métriques essentielles et nonessentiales sur les points suivants :

• Distribution Azure Monitor OpenTelemetry
• Autoinstrumentation (instrumentation automatique)

Les trois principaux objectifs de cette collecte de données sont les suivants :

• Santé et fiabilité du service : la surveillance de la connectivité au point de terminaison d’ingestion d’une perspective externe pour garantir que le service fonctionne correctement.
• Diagnostics de support : fournir des insights d’auto-assistance et aider le support client à diagnostiquer et à résoudre les problèmes.
• Amélioration du produit : collecte d’insights pour que Microsoft optimise la conception du produit et améliore l’expérience utilisateur globale.

Remarque

La collecte de données d'utilisation ne prend pas en charge Azure Private Link.

Langues prises en charge

Métriques	.NET	Java	JavaScript	Node.js	Python
Métriques essentielles
Réseau	❌	✅	❌	✅	✅
Joindre	✔️*	✅	❌	✅	✅
Caractéristique	❌	✅	❌	✅	✅
Métriques non essentielles
Échec des E/S de disque	❌	✅	❌	❌	❌

Régions d’Europe prises en charge

La collecte de données d’utilisation prend en charge la limite de données de l’UE pour les ressources Application Insights dans les régions suivantes :

Nom de la zone géographique	Nom de la région
Europe	Europe Nord
Europe	Europe Ouest
France	France Centrale
France	France Sud
Allemagne	Allemagne Centre-Ouest
Norvège	Norvège Est
Norvège	Norvège Ouest
Suède	Suède Centre
Suisse	Suisse Nord
Suisse	Suisse Ouest
Royaume-Uni	Royaume-Uni Sud
Royaume-Uni	Royaume-Uni Ouest

Données d’utilisation collectées

Métriques réseau

Nom de la métrique	Unité	Dimensions prises en charge
Nombre de succès de la requête	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host
Nombre d’échecs de requêtes	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Status Code
Durée de la demande	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host
Nombre de nouvelles tentatives	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Status Code
Nombre de limitations	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Status Code
Nombre d’exceptions	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version, Endpoint, Host, Exception Type

Ajouter des métriques

Nom de la métrique	Unité	Dimensions prises en charge
Joindre	Nombre	Resource Provider, Resource Provider Identifier, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version

Métriques de fonctionnalité

Nom de la métrique	Unité	Dimensions prises en charge
Caractéristique	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Feature, Type, Operating System, Language, Version

Métriques non essentielles

Suivre l’échec d’E/S du disque lorsque vous utilisez la persistance de disque pour une télémétrie fiable.

Nom de la métrique	Unité	Dimensions prises en charge
Nombre d’échecs de lecture	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version
Nombre d’échecs d’écriture	Nombre	Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating System, Language, Version

Configuration du pare-feu

Les métriques sont envoyées aux emplacements suivants, auxquels les connexions sortantes doivent être ouvertes dans les pare-feu :

Emplacement	URL
Europe	westeurope-5.in.applicationinsights.azure.com
En dehors de l’Europe	westus-0.in.applicationinsights.azure.com

Désactiver la collecte des données d’utilisation

.NET

La collecte de données d’utilisation est activée par défaut. Il peut être désactivé en définissant la variable d’environnement APPLICATIONINSIGHTS_STATSBEAT_DISABLED sur true.

Java

Remarque

Seules les métriques non essentielles peuvent être désactivées en Java.

Pour désactiver les métriques nonessential, ajoutez la configuration suivante à votre fichier de configuration :

{
  "preview": {
    "statsbeat": {
        "disabled": "true"
    }
  }
}

Vous pouvez également désactiver cette fonctionnalité en paramétrant la variable d’environnement APPLICATIONINSIGHTS_STATSBEAT_DISABLED sur true. Ce paramètre est alors prioritaire sur disabled qui est spécifié dans la configuration JSON.

Node.js

La collecte de données d’utilisation est activée par défaut. Il peut être désactivé en définissant la variable d’environnement APPLICATION_INSIGHTS_NO_STATSBEAT sur true.

Python

La collecte de données d’utilisation est activée par défaut. Il peut être désactivé en définissant la variable d’environnement APPLICATIONINSIGHTS_STATSBEAT_DISABLED_ALL sur true.

Informations archivées

Pour des informations archivées, consultez La collecte, la rétention, et le stockage des données dans Application Insights.

Application Insights et Azure Monitor ne contrôlent pas la version TLS utilisée pour les connexions HTTPS. La version TLS dépend du système d’exploitation et de l’environnement d’exécution où votre application s’exécute.

Pour confirmer la version TLS en cours d’utilisation :

• Passez en revue la documentation relative à votre système d’exploitation et à votre runtime ou infrastructure.
• Si vous avez besoin d’aide supplémentaire, contactez l’équipe de support appropriée. N’ouvrez pas de demande de support avec Application Insights.

Exemple de prise en charge du langage et du runtime pour TLS 1.2+

Les versions suivantes incluent la prise en charge intégrée de TLS 1.2 ou version ultérieure :

• .NET / .NET Core : .NET Framework 4.6.2 ou version ultérieure, et toutes les versions de .NET Core
• Java : Java 8 update 161 (8u161) ou version ultérieure
• Python : Distributions Python générées avec OpenSSL 1.0.1 ou version ultérieure
• Node.js: Node.js version 10 ou ultérieure

Exemple de prise en charge du système d’exploitation pour TLS 1.2+

Les systèmes d’exploitation suivants incluent la prise en charge intégrée de TLS 1.2 ou version ultérieure :

• Windows : Windows 8, Windows Server 2012 et versions ultérieures
• Linux : la plupart des distributions Linux modernes qui utilisent OpenSSL 1.0.1 ou version ultérieure

Pour éviter les interruptions de service, chaque point de terminaison distant (y compris les demandes dépendantes) que votre ressource interagit avec les besoins de prendre en charge au moins une combinaison de la même version du protocole, de la suite de chiffrement et de la courbe elliptique mentionnée précédemment. Si le point de terminaison distant ne prend pas en charge la configuration TLS requise, il doit être mis à jour pour prendre en charge une combinaison de la configuration TLS postérieure à l'obsolescence.

Les ressources Application Insights affectées arrêtent l'ingestion de données et ne peuvent pas accéder aux composants d'application requis. Par conséquent, certaines fonctionnalités arrêtent de fonctionner.

La dépréciation du protocole TLS (Transport Layer Security) détaillée dans ce document ne doit affecter le comportement qu’après le 1er mai 2025. Pour plus d’informations sur les opérations CRUD, consultez la documentation relative à la prise en charge de TLS par Azure Resource Manager. Cette ressource fournit plus d’informations sur le support TLS et les calendriers d’obsolescence.

Pour toute question générale sur les problème de TLS hérité, consultez Résolution des problèmes TLS.

Pour plus d'informations, consultez la section relative à la prise en charge de TLS..

Pour l’instrumentation actuelle, utilisez les API OpenTelemetry et les API de journalisation ou de métriques spécifiques au langage. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Pour les événements personnalisés du navigateur, utilisez le Kit de développement logiciel (SDK) JavaScript Application Insights ou Click Analytics. Pour les événements personnalisés côté serveur, utilisez des événements personnalisés OpenTelemetry.

ASP.NET Core dispose d'un support intégré pour la journalisation des informations de requêtes et réponses HTTP, y compris le corps de la requête. Cela peut exposer des informations d’identification personnelle (PII) et augmenter considérablement les coûts de performances et d’ingestion, afin d’évaluer soigneusement les risques avant de l’utiliser.

Pour les applications .NET actuelles, configurez la collecte de journaux via OpenTelemetry et votre configuration standard de journalisation .NET. Utilisez Logging:LogLevel dans appsettings.json pour choisir les niveaux de journalisation des applications et configurer l’exportation du journal OpenTelemetry dans le cadre de la configuration d’OpenTelemetry pour Azure Monitor. Consultez Activer OpenTelemetry avec Application Insights et Modifier la télémétrie.

Choisissez un chemin d’instrumentation pour l’application. Pour la configuration actuelle basée sur le code, utilisez Azure Monitor OpenTelemetry. Pour l’analyse App Service sans code, utilisez l’analyse des applications sans modification du code. Évitez de superposer l’instrumentation pour la même application, sauf si vous validez une migration.

Pour la surveillance des nouvelles applications, utilisez la distribution Azure Monitor OpenTelemetry ou les chemins d’auto-instrumentation actuels. Consultez Activer OpenTelemetry avec Application Insights et l’analyse des applications sans modification du code.

Pour l’instrumentation actuelle pour ASP.NET Core, consultez Activer OpenTelemetry avec Application Insights.

• Exception rate : le taux d’exceptions est un compteur de performances système. Le CLR compte l’ensemble des exceptions gérées et non gérées qui sont levées et divise le total d’un intervalle d’échantillonnage par la longueur de cet intervalle. Le Kit de développement logiciel (SDK) Application Insights collecte ce résultat et l’envoie au portail.
• Exceptions: la métrique Exceptions compte les données de télémétrie d’exception reçues par le portail dans l’intervalle d’échantillonnage du graphique. Il a également géré les exceptions que votre instrumentation rapporte. Il peut ne pas inclure chaque exception non gérée.

Pour obtenir des conseils actuels sur les métriques, consultez Métriques dans Application Insights.

Les mesures en temps réel n’affichent pas EventCounters. Utilisez Metrics Explorer ou Analytics pour voir les données de télémétrie.

La surveillance App Service sans modification du code ne prend actuellement pas en charge cette fonctionnalité pour ASP.NET Core.

Pour obtenir des conseils actuels sur les métriques, consultez Métriques dans Application Insights.

Les appels de dépendance échoués ont success le champ défini à false. La télémétrie des dépendances ne crée pas automatiquement un élément d’exception distinct pour chaque appel de dépendance échoué. Le modèle de données complet pour la télémétrie des dépendances est décrit dans le modèle de données de télémétrie Application Insights.

Utilisez ce code :

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp
| extend TimeIngested = ingestion_time()

Dans la vue de requête Log Analytics, timestamp représente le moment où l’opération de télémétrie de dépendance a été lancée, qui se produit immédiatement après la réception de la réponse de l’appel de dépendance. Pour calculer l’heure de début de l’appel de dépendance, vous devez prendre timestamp et soustraire la duration enregistrée de l’appel de dépendance.

Le suivi des dépendances dans Application Insights n’inclut pas les corps de réponse de journalisation, car cela générerait trop de données de télémétrie pour la plupart des applications.

Pour obtenir des instructions actuelles sur les dépendances et les étendues personnalisées, consultez Ajouter des étendues personnalisées.

Les tests de disponibilité s’exécutent sur des points de présence qui sont répartis dans le monde entier. Il existe deux solutions :

• Firewall door : autoriser les demandes adressées à votre serveur à partir de la liste longue et modifiable des agents de test web.
• Code personnalisé : Écrivez votre propre code pour envoyer des requêtes régulières à votre serveur depuis votre intranet. Vous pouvez exécuter Visual Studio tests web à cet effet. Émettez un signal de santé interne et alertez sur le journal ou la métrique résultante.

La chaîne de l’agent utilisateur est Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Pour plus d'informations, consultez la section Tests de disponibilité.

Les tests de disponibilité agissent comme un client distribué dans chacun des emplacements de test web pris en charge. Chaque fois qu’un test web est exécuté, le service de test de disponibilité tente d’atteindre le point de terminaison distant défini dans la configuration du test web. Un message Hello du client TLS est envoyé, qui contient toutes les configurations TLS actuellement prises en charge. Si le point de terminaison distant partage une configuration TLS commune avec le client de test de disponibilité, alors l’établissement de la liaison TLS réussit. Sinon, le test web échoue avec un échec d’établissement d'une liaison TLS.

Il existe plusieurs outils pour définir la configuration TLS prise en charge par un point de terminaison. L’une des méthodes consiste à suivre l’exemple détaillé sur cette page. Si votre point de terminaison distant n'est pas disponible via l'Internet public, vous devez vous assurer que vous validez la configuration TLS prise en charge sur le point de terminaison distant à partir d'un ordinateur qui a access pour appeler votre point de terminaison.

Remarque

Pour découvrir les étapes permettant d’activer la configuration TLS nécessaire sur votre serveur web, il est préférable de contacter l’équipe propriétaire de la plateforme d’hébergement sur laquelle votre serveur web s’exécute, si le processus n’est pas connu.

Il n’existe aucun type d’exception avec lequel tous les échecs d’établissement d’une liaison TLS affectés par cette dépréciation se présenteraient. Toutefois, l’exception la plus courante qui commencerait à faire échouer votre test web serait The request was aborted: Couldn't create SSL/TLS secure channel. Vous devriez également pouvoir consulter les éventuelles erreurs liées au protocole TLS dans la section Dépannage du transport TLS du résultat du test Web potentiellement concerné.

La configuration TLS négociée pendant une exécution de test web ne peut pas être consultée. Tant que le point de terminaison distant prend en charge la configuration TLS courante avec les tests de disponibilité, aucun impact ne doit être observé après la dépréciation.

L’obsolescence de TLS détaillée dans ce document ne devrait affecter le comportement d’exécution des tests Web de disponibilité qu’après le 1er mai 2025. Pour plus d’informations sur l’interaction avec le service de test de disponibilité pour les opérations CRUD, consultez Prise en charge TLS d'Azure Resource Manager. Cette ressource fournit plus d’informations sur le support TLS et les calendriers d’obsolescence.

Pour toute question générale sur les problème de TLS hérité, consultez Résolution des problèmes TLS.

Pour plus d'informations, consultez la section Configurations TLS prises en charge.

Les modifications dépendent de la voie d’instrumentation. La surveillance du service d'application sans code utilise généralement les paramètres d'application et la configuration de la plateforme. La surveillance basée sur le code utilise le package OpenTelemetry et la configuration de démarrage pour la langue sélectionnée. Pour obtenir des conseils actuels, consultez Enable application monitoring in Azure App Service et Enable OpenTelemetry avec Application Insights.

Application Insights collecte des données de télémétrie pour les requêtes qui ont été envoyées à l'application. Si l'échec se produit dans Web Apps ou le serveur web et que la demande n'a pas atteint l'application utilisateur, Application Insights ne dispose pas de données de télémétrie.

La durée de serverresponsetime calculée par Application Insights ne correspond pas nécessairement au temps de réponse du serveur observé par Web Apps. Application Insights compte la durée pendant laquelle la requête atteint l’application utilisateur. Si la demande est bloquée ou mise en file d’attente sur le serveur web, le temps d’attente est inclus dans les métriques Web Apps, mais pas dans les métriques Application Insights.

Pour plus d’informations, consultez Enable application monitoring in Azure App Service.

Nous suivons le Guide de style Microsoft pour la documentation de produit publiée sur la plateforme Microsoft Learn.

En général, nous n’incluons pas de trait d’union après le préfixe « auto ».

Pour plus d’informations, consultez Quelle est l’autoinstrumentation pour Azure Monitor Application Insights ?.

Nouvelles régions Azure requièrent l’utilisation de chaînes de connexion au lieu de clés d’instrumentation. Connection string identifie la ressource que vous souhaitez associer à vos données de télémétrie. Elle vous permet également de modifier les points de terminaison que votre ressource utilisera comme destination pour votre télémétrie. Copiez le chaîne de connexion et ajoutez-le au code de votre application ou à une variable d'environnement.

Nous vous recommandons d’utiliser des chaînes de connexion plutôt que des clés d’instrumentation.

Définissez la APPLICATIONINSIGHTS_CONNECTION_STRING valeur manuelle dans tous les scénarios où le système ne le fournit pas automatiquement. Ces scénarios incluent, mais ne sont pas limités à : le développement local et les Fonctions Isolées .NET avec l'intégration d'ASP.NET Core. Dans ce cas, la variable d’environnement garantit que le pipeline OpenTelemetry peut envoyer des données de télémétrie à Application Insights. Pour plus d’informations sur la configuration des chaînes de connexion avec une variable d’environnement, consultez Configuration d’OpenTelemetry dans Application Insights.

Pas strictement. Une seule ressource Application Insights peut recevoir des données de télémétrie de navigateur à partir du Kit de développement logiciel (SDK) JavaScript Application Insights et des données de télémétrie côté serveur envoyées à l’aide de l’ingestion authentifiée lorsque l’authentification locale reste activée pour l’ingestion du navigateur. La télémétrie côté serveur peut utiliser l’ingestion authentifiée via Microsoft Entra, tandis que l’ingestion OTLP à l’aide du collecteur OpenTelemetry nécessite une authentification Microsoft Entra. Vous n’avez pas besoin d’éviter OpenTelemetry ou OTLP uniquement, car votre application collecte également les données de télémétrie du navigateur.

L’exception principale est lorsque vous désactivez l’authentification locale sur une ressource Application Insights pour exiger Microsoft Entra authentification pour toute ingestion. Dans cette configuration, le Kit de développement logiciel (SDK) JavaScript ne peut pas s’authentifier directement à partir du navigateur et la télémétrie du navigateur pourrait arrêter de circuler. Pour la télémétrie du navigateur dans ce scénario, utilisez une ressource de télémétrie de navigateur distincte avec l’authentification locale activée ou routez la télémétrie du navigateur via un modèle proxy authentifié. Pour plus d’informations, consultez La télémétrie du navigateur authentifié à l’aide de chaînes de connexion.

Même lorsqu’une seule ressource fonctionne techniquement, envisagez d’utiliser une ressource Application Insights distincte pour les données de télémétrie côté navigateur/côté client comme meilleure pratique d’isolation des risques. L'instrumentation du navigateur s'exécute dans un environnement client non approuvé, de sorte que son chaîne de connexion est visible pour les utilisateurs et ne peut pas être traité comme un secret. Une chaîne de connexion exposée peut être utilisée pour envoyer des données de télémétrie usurpées, non pertinentes ou à volume élevé à la ressource associée, qui peuvent polluer les tableaux de bord, les alertes, les requêtes de dépannage et augmenter les coûts d’ingestion.

Une ressource de télémétrie de navigateur distincte peut vous aider à :

• Faites pivoter ou remplacez le chaîne de connexion côté navigateur sans perturber les données de télémétrie côté serveur.
• Contient une télémétrie usurpée, indésirable ou corrompue pour la ressource spécifique du navigateur.
• Protégez la qualité des données de télémétrie côté serveur utilisées pour les diagnostics, les alertes et l’analyse opérationnelle.
• Appliquez différents paramètres de contrôle d’accès, de propriété ou de gouvernance si nécessaire.

Mettez ces avantages en balance avec la charge de gestion supplémentaire liée à plusieurs ressources, notamment les chaînes de connexion supplémentaires, les attributions RBAC, la configuration et les investigations inter-ressources. La corrélation de bout en bout peut toujours fonctionner sur plusieurs ressources Application Insights lorsque l’utilisateur a accès aux ressources pertinentes. Pour plus d’informations, consultez La carte des applications et les diagnostics de transaction.

Private Link et l’authentification d’ingestion sont des contrôles distincts. Private Link contrôle l’accès réseau aux ressources Azure Monitor, tandis que l'authentification Microsoft Entra détermine si l’ingestion de télémétrie est autorisée par une identité. N'utilisez pas Private Link comme substitut de l'authentification d'ingestion et ne traitez pas la séparation des ressources comme une exigence pour l'ingestion côté serveur authentifiée.

Pour répondre aux exigences de conformité des données régionales, utilisez des points de terminaison Application Insights régionaux au lieu du point de terminaison global. Le point de terminaison global ne garantit pas que les données restent dans une région spécifique. Les points de terminaison régionaux permettent de s’assurer que les données de télémétrie provenant d’utilisateurs dans des zones réglementées sont envoyées uniquement aux centres de données de ces régions.

Pour configurer votre application web globale pour la conformité régionale :

• Créez une ressource Application Insights par région avec des exigences de conformité strictes, telles que l’Union européenne ou le États-Unis.
• Créez une autre ressource Application Insights pour les utilisateurs de toutes les autres régions.
• Configurez votre application pour envoyer des données de télémétrie à la ressource Application Insights appropriée en fonction de la région de chaque utilisateur. Déterminez la région à l’aide de signaux tels que l’adresse IP, les métadonnées de compte ou les paramètres d’emplacement.
• Connectez toutes les ressources Application Insights à un espace de travail Log Analytics si vous avez besoin d’une expérience de requête unifiée entre les régions.

Par exemple:

• Envoyez des données des utilisateurs de la région A vers la ressource Application Insights de la région A en utilisant la chaîne de connexion de la région A.
• Envoyez les données des utilisateurs de la région B à la ressource Application Insights de la région B en utilisant la chaîne de connexion de la région B.
• Envoyez toutes les autres données utilisateur à une ressource Application Insights à usage général à l’aide d’une autre chaîne de connexion.

Important

L’utilisation du point de terminaison global ne garantit pas la conformité régionale. Pour répondre aux exigences de résidence des données, utilisez toujours des points de terminaison spécifiques à la région et routez les données de télémétrie en fonction de la région de l’utilisateur.

Le diagramme suivant montre un exemple de configuration pour une application web globale :

Pour plus d’informations, consultez Chaînes de connexion.

Le transfert de ressources Application Insights existant entre les régions n'est pas pris en charge. Par conséquent, vous ne pouvez pas migrer les données historiques vers une nouvelle région. La solution de contournement implique :

• Création d’une ressource Application Insights dans la région souhaitée.
• Recréer toutes les personnalisations uniques de la ressource d'origine dans la nouvelle ressource.
• Mise à jour de votre application avec la nouvelle ressource de région chaîne de connexion.
• des tests pour s'assurer que tout fonctionne comme prévu avec la nouvelle ressource Application Insights ;
• la prise de décision sur le fait de conserver ou de supprimer la ressource Application Insights d'origine. La suppression d'une ressource classique signifie perdre toutes les données historiques. Si la ressource est basée sur l’espace de travail, les données restent dans Log Analytics, ce qui permet access aux données historiques jusqu’à l’expiration de la période de rétention.

Les personnalisations uniques qui doivent généralement être recréées ou mises à jour manuellement pour la ressource dans la nouvelle région incluent, mais sans s’y limiter :

• Recréer des tableaux de bord et des classeurs personnalisés.
• Recréer ou mettre à jour l’étendue de toutes les alertes de journal/métrique personnalisées.
• Recréer des alertes de disponibilité.
• Recréez les paramètres de contrôle d'accès personnalisés Azure basés sur les rôles requis pour que vos utilisateurs aient accès à la nouvelle ressource.
• Répliquer les paramètres impliquant l’échantillonnage d’ingestion, la conservation des données, la limite quotidienne et l’activation des métriques personnalisées. Ces paramètres sont contrôlés via le volet Utilisation et coûts estimés.
• Toute intégration reposant sur des clés API telles que les annotations de version et les canaux de contrôle sécurisés des métriques en temps réel. Vous devez générer de nouvelles clés API et mettre à jour l’intégration associée.
• L’exportation continue dans les ressources classiques doit être reconfigurée.
• Les paramètres de diagnostic des ressources basées sur l’espace de travail doivent être reconfigurés.

Nous ne recommandons pas d’utiliser cette méthode pour renseigner la version de l’API. La version la plus récente peut représenter des versions préliminaires susceptibles de contenir des changements majeurs. Même avec les versions non préliminaires plus récentes, les versions d’API ne sont pas toujours compatibles avec les modèles existants. Dans certains cas, la version de l’API peut ne pas être disponible pour tous les abonnements.

Pour plus d'informations, consultez la section Créer et configurer les ressources Application Insights.

Pour signaler des problèmes de modèle de données ou de schéma et des suggestions, utilisez notre référentiel GitHub.

La télémétrie PageView inclut une URL et vous pouvez analyser le paramètre UTM en tirant parti d’une fonction regex dans Kusto.

Ces données peuvent parfois être manquantes ou inexactes si l’utilisateur ou l’entreprise désactive l’envoi de l’agent utilisateur dans les paramètres du navigateur. Les UA Parser regexes peuvent ne pas inclure toutes les informations d’appareil. Ou bien Application Insights n’a peut-être pas intégré les dernières mises à jour.

Cela peut se produire si vous utilisez des valeurs de chaîne. Seules des valeurs numériques fonctionnent avec des mesures personnalisées.

Pour plus d’informations, consultez le Modèle de données de télémétrie d’Application Insights.

Les enregistrements de journal OpenTelemetry sont stockés dans la traces table des journaux Application Insights. Pour les afficher dans le portail Azure, ouvrez votre ressource Application Insights, sélectionnez Logs et interrogez la table traces.

Exemple de requête : traces | where message contains "YourSearchTerm".

Pour les applications .NET actuelles, configurez la collecte de journaux via OpenTelemetry et votre configuration standard de journalisation .NET. Utilisez Logging:LogLevel dans appsettings.json pour choisir les niveaux de journalisation des applications et configurer l’exportation du journal OpenTelemetry dans le cadre de la configuration d’OpenTelemetry pour Azure Monitor. Consultez Activer OpenTelemetry avec Application Insights et Modifier la télémétrie.

Lorsque les journaux d’activité sont émis avant la fin de la configuration de la télémétrie d’application, ils peuvent avoir moins de propriétés enrichies que les journaux émis plus tard dans le cycle de vie de l’application.

Pour l'instrumentation actuelle, envoyez des données de télémétrie personnalisées avec les API OpenTelemetry ou la distribution OpenTelemetry d'Azure Monitor. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Pour l’instrumentation actuelle .NET, consultez Activer OpenTelemetry avec Application Insights.

Le profileur Java utilise Java Flight Recorder (JFR) pour profiler votre application en utilisant une configuration personnalisée.

Java Flight Recorder (JFR) est un outil permettant de collecter des données de profilage d’une application Java en cours d’exécution. JFR est intégré à la machine virtuelle Java (JVM) et sert à résoudre les problèmes de performances. En savoir plus sur le runtime Java SE JFR.

Le profilage Java est une fonctionnalité gratuite d’Application Insights. La tarification d’Azure Monitor Application Insights est basée sur le coût d’ingestion.

Les données de profilage collectées par JFR incluent : les données de profilage de méthode et d’exécution, les données de garbage collection et les profils de verrouillage.

L’enregistrement JFR peut être consulté et analysé avec votre outil préféré, par exemple Java Mission Control (JMC).

« Diagnostics et recommandations de performances » est une nouvelle fonctionnalité bientôt disponible en tant que diagnostics Java dans Application Insights. Vous pouvez vous inscrire pour afficher un aperçu de cette fonctionnalité. L’enregistrement JFR peut être consulté avec Java Mission Control (JMC).

Le profilage à la demande est déclenché par l’utilisateur en temps réel, tandis que le profilage automatique se fait avec des déclencheurs préconfigurés.

Utilisez Profile Now pour l’option de profilage à la demande. Profiler maintenant profile immédiatement tous les agents attachés à l’instance Application Insights.

Le profilage automatisé est déclenché quand le seuil d’une ressource est atteint.

L’agent Java Application Insights prend actuellement en charge la surveillance de la consommation de processeur et de mémoire. Le seuil du processeur est configuré en pourcentage de tous les cœurs disponibles sur la machine. La mémoire est l’occupation actuelle de la région de mémoire foncière (OldGen) par rapport à la taille maximale possible de la région.

Passez en revue les prérequis.

Oui, vous pouvez profiler une machine virtuelle JVM exécutant des microservices à l’aide de JFR.

Pour plus d’informations, consultez l'Application Insights Profiler d’Azure Monitor pour Java.

Non, les substitutions d'échantillonnage sont désormais disponibles pour tous (GA) et peuvent être utilisées avec l'instrumentation automatique et l'instrumentation manuelle.

Si vous utilisez l'autoinstrumentation, mettez à jour le fichier applicationinsights.json dans le portail Azure.

Pour l’instrumentation automatique, aucun chargement manuel d’agent n’est nécessaire. Toutefois, pour l’instrumentation manuelle, vous devez toujours inclure le fichier JAR de l’agent Application Insights et les fichiers de configuration dans votre package de déploiement.

Le développement local fait référence à l'environnement dans lequel l'application est générée ou testée, comme l'ordinateur d'un développeur ou une instance de Azure Cloud Shell. Le serveur d’applications fait référence au serveur web exécutant l’application, tel que Tomcat 11 dans un App Service environment Azure. Lorsque vous utilisez l’instrumentation manuelle, vous devez vous assurer que le fichier JAR de l’agent est correctement placé sur le serveur d’applications.

Pour l'instrumentation automatique, vous pouvez configurer les substitutions d'échantillonnage via le Portail Microsoft Azure. Si vous utilisez l’instrumentation manuelle, vous devez placer le fichier JAR de l’agent Application Insights dans le répertoire approprié et inclure le fichier applicationinsights.json avec vos paramètres d’échantillonnage souhaités.

Pour plus d’informations, consultez Sampling overrides - Azure Monitor Application Insights pour Java.

Les processeurs OpenTelemetry peuvent fonctionner avec des données de télémétrie qui transitent par le pipeline OpenTelemetry. Les journaux ou fichiers écrits en dehors de ce pipeline ne sont pas traités par les processeurs OpenTelemetry à moins que vous ne les collectiez explicitement.

Pour plus d’informations, consultez Processeurs de télémétrie (version préliminaire) - Azure Monitor Application Insights pour Java.

• Le SDK JavaScript définit un cookie utilisateur sur le client web pour identifier les utilisateurs récurrents, ainsi qu’un cookie de session pour regrouper des activités.
• S’il n’existe aucun script côté client, vous pouvez définir des cookies sur le serveur.
• Si un utilisateur réel utilise votre site dans différents navigateurs, ou s’il utilise la navigation privée/incognito, ou encore différentes machines, il est comptabilisé plusieurs fois.
• Pour identifier un utilisateur connecté entre les ordinateurs et les navigateurs, utilisez le contexte utilisateur authentifié du Kit de développement logiciel (SDK) JavaScript ou définissez l’attribut OpenTelemetry enduser.id .

Le SDK JavaScript Application Insights présente une surcharge minimale sur votre site web. Avec seulement 36 Ko compressés avec gzip et mettant environ 15 ms seulement pour s’initialiser, le SDK ajoute un temps de chargement négligeable à votre site web. Les composants minimaux de la bibliothèque sont rapidement chargés lorsque vous utilisez le SDK, et le script complet est téléchargé en arrière-plan.

En outre, pendant le téléchargement du script à partir du CDN, tout le suivi de votre page est mis en file d’attente, de sorte que vous ne perdez aucune télémétrie pendant tout le cycle de vie de votre page. Ce processus de configuration fournit à votre page un système d’analyse transparent, invisible à vos utilisateurs.

Chrome version la plus récente ✔	Firefox version la plus récente ✔	v3.x : IE 9+ et Microsoft Edge ✔ v2.x : IE 8+ Compatible et Microsoft Edge ✔	Opera version la plus récente ✔	Safari version la plus récente ✔

Pour obtenir des exemples exécutables, consultez Application Insights JavaScript SDK.

Nous devons prendre les mesures nécessaires pour s’assurer que ce SDK continue à « fonctionner » et n’interrompt pas l’exécution de JavaScript lorsqu’il est chargé par un navigateur plus ancien. Il serait idéal de ne pas prendre en charge les navigateurs plus anciens, mais de nombreux clients importants ne peuvent pas contrôler le navigateur que leurs utilisateurs choisissent d’utiliser.

Cela ne signifie pas que nous ne prenons en charge que l’ensemble commun de fonctionnalités les plus faibles. Nous devons maintenir la compatibilité du code ES3. De nouvelles fonctionnalités doivent être ajoutées de manière à ne pas perturber l'analyse JavaScript ES3 et doivent être proposées en tant que fonctionnalités facultatives.

Consultez GitHub pour plus d’informations sur la prise en charge de Internet Explorer 8.

Oui, le Kit de développement logiciel (SDK) JavaScript Application Insights est open source. Pour afficher le code source ou contribuer au project, consultez le référentiel official GitHub.

Pour plus d’informations, consultez Activer Azure Monitor Application Insights Real User Monitoring.

Le côté serveur doit être en mesure d’accepter les connexions avec ces en-têtes présents. Selon la configuration Access-Control-Allow-Headers côté serveur, il est souvent nécessaire d'étendre la liste côté serveur en ajoutant manuellement Request-Id, Request-Context et traceparent (en-tête distribué W3C).

Access-Control-Allow-Headers : Request-Id, traceparent, Request-Context, <your header>

Le suivi distribué peut être désactivé dans la configuration.

Non. Les erreurs « 502 Passerelle incorrecte » et « 503 Service indisponible » ne sont pas toujours capturées par Application Insights. Si seul le code JavaScript côté client est utilisé pour l’analyse, ce comportement est prévisible, car la réponse d’erreur est retournée avant la page contenant l’en-tête HTML avec l’extrait de code JavaScript d’analyse rendu.

Si la réponse 502 ou 503 a été envoyée à partir d’un serveur sur lequel l’analyse côté serveur est activée, les erreurs sont collectées par le Kit de développement logiciel (SDK) Application Insights.

Même lorsque l’analyse côté serveur est activée sur le serveur web d’une application, il arrive qu’une erreur 502 ou 503 ne soit pas capturée par Application Insights. De nombreux serveurs web modernes ne permettent pas à un client de communiquer directement. Au lieu de cela, ils utilisent des solutions telles que les proxys inverses pour transmettre des informations entre le client et les serveurs web frontaux.

Dans ce scénario, une réponse 502 ou 503 peut être renvoyée à un client en raison d’un problème au niveau de la couche de proxy inverse, de sorte qu’elle n’est pas capturée directement par Application Insights. Pour aider à détecter les problèmes au niveau de cette couche, vous devrez peut-être transférer les journaux de votre proxy inverse vers Log Analytics et créer une règle personnalisée pour vérifier les réponses 502 ou 503. Pour en savoir plus sur les causes courantes des erreurs 502 et 503, consultez Erreurs HTTP de « 502 mauvaise passerelle » et « 503 service indisponible » dans Azure App Service.

Pour plus d'informations, consultez la configuration du SDK JavaScript d'Application Insights..

Le navigateur transmet la chaîne de l’agent utilisateur dans l’en-tête HTTP de la requête. Le service d’ingestion Application Insights utilise UA Parser pour générer les champs que vous voyez dans les tables de données et les expériences. Par conséquent, les utilisateurs d’Application Insights ne peuvent pas modifier ces champs.

Ces données peuvent parfois être manquantes ou inexactes si l’utilisateur ou l’entreprise désactive l’envoi de l’agent utilisateur dans les paramètres du navigateur. Les UA Parser regexes peuvent ne pas inclure toutes les informations d’appareil. Ou bien Application Insights n’a peut-être pas intégré les dernières mises à jour.

Pour plus d'informations, consultez la section Activer une extension de framework pour le kit de développement logiciel JavaScript Application Insights..

Non. Les modèles ARM et les appels d’API existants continuent de fonctionner. Lorsque vous tentez de créer une ressource classique, une ressource basée sur un espace de travail avec un espace de travail managé est créée à la place.

Non. La notification pour les migrations de ressources individuelles n’est pas disponible. Pour contrôler quand et comment vos ressources sont migrées, utilisez migration managée.

Les migrations individuelles se terminent généralement en moins de deux minutes. Le déploiement complet se déroule sur plusieurs semaines dans toutes les régions.

Après la migration, la ressource est liée à un espace de travail Log Analytics sur la page Vue d’ensemble. L’avis de mise hors service classique est supprimé et le classeur de retraits ne répertorie plus la ressource.

Les coûts restent généralement similaires. Application Insights basé sur l’espace de travail permet d’économiser des coûts et nous vous recommandons d’examiner les plans tarifaires.

Si vous utilisez un modèle de facturation hérité, consultez la documentation pricing pour plus d'informations.

Non. Toutes les alertes, tableaux de bord et tests de disponibilité restent intacts et continuent à fonctionner après la migration.

Pour plus d'informations, consultez la section Espaces de travail gérés dans Application Insights..

Pour l’instrumentation actuelle, passez en revue la corrélation de suivi distribué et de télémétrie. Pour la télémétrie du navigateur JavaScript, consultez la configuration du Kit de développement logiciel (SDK) JavaScript.

Pour configurer le niveau de journal souhaité par Application Insights, utilisez la variable d’environnement APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . Les valeurs prises en charge sont NONE, ERROR, WARN, INFO, DEBUG, VERBOSE et ALL. Pour plus d’informations, consultez ApplicationInsights-node.js.

Pour connaître l’instrumentation Node.js actuelle, consultez Activer OpenTelemetry avec Application Insights.

Une liste des versions et noms du SDK est hébergée sur GitHub. Pour plus d’informations, consultez SDK Version.

Pour plus d'informations, consultez la section Collecter des données de télémétrie avec OpenTelemetry dans Application Insights.

Consultez la Migration des SDK d'Application Insights vers Azure Monitor OpenTelemetry. Conservez des conseils spécifiques à la migration sur cette page afin que les articles de configuration actuels puissent continuer à présenter un chemin d’accès OpenTelemetry recommandé.

Utilisez les API OpenTelemetry et les API de journalisation ou de métriques spécifiques au langage. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

L’échantillonneur personnalisé Application Insights prend des décisions d’échantillonnage après la création d’un segment plutôt qu’avant, donc il ne suit pas une approche traditionnelle d’intervention en début de workflow. Au lieu de cela, il applique des décisions d’échantillonnage à la fin de la génération d’un segment, c’est-à-dire une fois que le segment est complet, mais avant l’exportation.

Bien que ce comportement ressemble d’une certaine façon à un échantillonnage en fin de workflow, l’échantillonneur n’attend pas de collecter plusieurs segments à partir de la même trace pour décider. Au lieu de cela, il utilise un hachage de l’ID de trace pour garantir l’exhaustivité de la trace.

Cette approche équilibre l’exhaustivité et l’efficacité des traces et évite le coût plus élevé associé à l’échantillonnage complet basé sur la queue.

Pour prendre des décisions d’échantillonnage basées sur le résultat d’une trace entière (par exemple, déterminer si un segment au sein de la trace a échoué), un échantillonnage complet en fin de workflow est requis dans un agent ou un collecteur en aval. Cette fonctionnalité n'est actuellement pas prise en charge, mais vous pouvez la demander en tant que nouvelle fonctionnalité via le Feedback Hub.

Méthode d’échantillonnage	Point de décision	Points forts	Faiblesses
En début de workflow	Avant qu’un segment ne commence	Latence faible, surcharge minimale	Peut échantillonner les traces souhaitées, y compris les échecs
En fin de workflow	Une fois que les segments sont mis en mémoire tampon sur la base de seuils de durée ou de volume	Permet des critères d’échantillonnage de trace hautement sélectifs	Coût plus élevé et retard de traitement ajouté
Azure Monitor échantillonneur personnalisé	Fin de la génération d’un segment	Trouve l’équilibre entre les traces complètes et l’efficacité	Obligatoire pour la compatibilité des métriques actives

Non, l’échantillonneur applique un taux fixe sur tous les types de télémétrie dans une trace. Les requêtes, dépendances et autres segments suivent le même pourcentage d’échantillonnage. Pour appliquer des taux différents par type de télémétrie, envisagez d’utiliser des processeurs de span OpenTelemetry ou des transformations au moment de l’ingestion (ingestion-time transformations)[app-insights-overview.md#telemetry-routing].

L’échantillonneur personnalisé Application Insights propage les décisions d’échantillonnage à l’aide de la norme de contexte de trace W3C par défaut. Cette norme permet aux décisions d’échantillonnage de circuler entre les services. Toutefois, étant donné que l’échantillonneur prend des décisions d’échantillonnage à la fin de la génération d’un segment (après l’appel aux services en aval), la propagation comporte des informations d’échantillonnage incomplètes. Cette limitation est conforme à la spécification de contexte de trace W3C, mais les services en aval ne peuvent pas utiliser de manière fiable cette décision d’échantillonnage propagée.

Non, l’échantillonneur personnalisé Application Insights prend toujours une décision d’échantillonnage indépendante, même si le service en amont utilise le même algorithme d’échantillonnage. Les décisions d'échantillonnage des services en amont, y compris celles qui utilisent des en-têtes de contexte de traçage W3C, n'influencent pas la décision du service en aval. Toutefois, il effectue un échantillonnage à partir d’un hachage de l’ID de trace pour s’assurer que la trace est complète. Pour améliorer la cohérence et réduire le risque de traces interrompues, configurez tous les composants du système pour utiliser le même échantillonneur et le même taux d’échantillonnage.

Il existe plusieurs raisons pour lesquelles les traces peuvent apparaître incomplètes :

• Différents nœuds d’un système distribué utilisent différentes approches d’échantillonnage qui ne coordonnent pas les décisions. Par exemple, un nœud applique l’échantillonnage basé sur la tête OpenTelemetry, et un autre nœud applique l’échantillonnage via l’échantillonneur personnalisé Azure Monitor.
• Différents nœuds sont définis sur des taux d’échantillonnage différents, même s’ils utilisent la même approche d’échantillonnage.
• Vous définissez des limites de filtrage, d'échantillonnage ou de débit dans le pipeline côté serveur, et cette configuration échantillonne de manière aléatoire des traces sans tenir compte de leur exhaustivité.

Si un composant applique un échantillonnage en début de workflow sans propager la décision d’échantillonnage (via les en-têtes de contexte de trace W3C), les services en aval échantillonnent la trace indépendamment, ce qui peut aboutir à l’abandon de segments. Par conséquent, certaines parties de la trace ne sont pas toujours disponibles lorsqu’elles sont consultées dans Application Insights.

L'échantillonnage d'ingestion ne supprime que ce qui atteint le service ; il ne peut donc pas contrecarrer ni remplacer les décisions de l'échantillonneur personnalisé d'Application Insights. Si les deux sont activés, le taux effectif est multiplié. Par exemple, un taux de SDK de 20 % combiné à un taux d’ingestion de 50 % entraîne environ 10 % des données stockées. Microsoft recommande d’effectuer l’échantillonnage à la source avec l’échantillonneur OpenTelemetry Azure Monitor pour conserver les traces intactes et prévisibles, et d’utiliser l’échantillonnage d’ingestion uniquement comme secours.

Pour plus d’informations, consultez Sampling dans Azure Monitor Application Insights avec OpenTelemetry.

Il s'agit d'une norme open source pour l'observabilité. Pour en savoir plus, rendez-vous sur OpenTelemetry.

Microsoft investit dans OpenTelemetry pour les raisons suivantes :

• Cette solution est indépendante des fournisseurs et fournit des API/SDK homogènes dans toutes les langues.
• Au fil du temps, nous pensons qu’OpenTelemetry permettra aux clients Azure Monitor d’observer les applications écrites dans des langages au-delà de nos langages pris en charge.
• Elle permet de recueillir un plus grand nombre de données grâce à un ensemble complet de bibliothèques d’instrumentation.
• Les kits de développement logiciel OpenTelemetry (SDK) sont conçus pour une télémétrie efficace et neutre vis-à-vis des fournisseurs à grande échelle.
• OpenTelemetry s'aligne sur la stratégie de Microsoft pour embrace open source.

Consultez l’état d’OpenTelemetry.

Vous pouvez le considérer comme un wrapper mince qui regroupe tous les composants OpenTelemetry pour une expérience de première classe sur Azure. Ce wrapper est également appelé une distribution dans OpenTelemetry.

Il existe plusieurs avantages à l'utilisation de la distribution Azure Monitor OpenTelemetry par rapport à OpenTelemetry d'origine de la communauté :

• Réduit l’effort d’activation
• Prise en charge par Microsoft
• Apporte des fonctionnalités spécifiques à Azure telles que :
  • L’échantillonnage compatible avec les kits SDK Application Insights classiques
  • Authentification Microsoft Entra
  • Stockage hors ligne et reprises automatiques
  • Métriques standard d'Application Insights
  • Détecter les métadonnées de ressource pour remplir automatiquement le nom du rôle cloud et l’instance de rôle cloud dans différents environnements Azure
  • Métriques temps réel

Dans l’esprit d’OpenTelemetry, nous avons conçu la distribution pour qu’elle soit ouverte et extensible. Par exemple, vous pouvez ajouter :

• Un exportateur OTLP (OpenTelemetry Protocol) et l’envoi vers une seconde destination simultanément
• Autres bibliothèques d’instrumentation non incluses dans la distribution

Étant donné que la distribution fournit une distribution OpenTelemetry, la distribution prend en charge tout ce qui est pris en charge par OpenTelemetry. Par exemple, vous pouvez ajouter d’autres processeurs de télémétrie, exportateurs ou bibliothèques d’instrumentation si OpenTelemetry les prend en charge.

Pour les langues sans exportateur OpenTelemetry autonome pris en charge, la distribution openTelemetry Azure Monitor est la seule méthode actuellement prise en charge pour utiliser OpenTelemetry avec Azure Monitor. Pour les langues avec un exportateur OpenTelemetry autonome pris en charge, vous avez la possibilité d’utiliser la distribution Azure Monitor OpenTelemetry ou l’exportateur OpenTelemetry autonome approprié en fonction de votre scénario de télémétrie. Pour plus d’informations, consultez Quand dois-je utiliser l’exportateur OpenTelemetry Azure Monitor ?.

Oui. Nous vous recommandons d’utiliser Azure Monitor Distro OpenTelemetry pour les nouveaux projets.

Si vous migrez une application .NET ou Node.js existante à partir de kits SDK Application Insights plus anciens, consultez Migration des kits SDK Application Insights vers Azure Monitor OpenTelemetry.

Pour ASP.NET Core, Java, Node.jset Python, nous vous recommandons d’utiliser la distribution OpenTelemetry Azure Monitor. Il suffit d'une ligne de code pour commencer.

Pour tous les autres scénarios de .NET, notamment ASP.NET classique, applications console, Windows Forms (WinForms), etc., nous vous recommandons d’utiliser l’exportateur openTelemetry .NET Azure Monitor : Azure.Monitor.OpenTelemetry.Exporter.

Pour les scénarios de télémétrie Python plus complexes nécessitant une configuration avancée, nous vous recommandons d’utiliser python Azure Monitor OpenTelemetry Exporter.

La distribution OpenTelemetry d'Azure Monitor prend en charge le chemin d'instrumentation recommandé actuel d'Application Insights.

Pour plus d’informations sur les expériences d'analyse de code, consultez .NET Profiler et Snapshot Debugger.

Oui, mais nous ne le recommandons pas et Azure ne le prend pas en charge. OpenTelemetry JavaScript est fortement optimisé pour Node.js. Au lieu de cela, nous vous recommandons d’utiliser le Kit de développement logiciel (SDK) JavaScript Application Insights.

Le SDK web OpenTelemetry n’a pas de planning de disponibilité défini. Il faudra probablement attendre encore plusieurs années avant qu’un SDK pour navigateur ne constitue une alternative viable au SDK JavaScript d’Application Insights.

Le bac à sable web OpenTelemetry est un fork conçu pour faire fonctionner OpenTelemetry dans un navigateur. Il n’est pas encore possible d’envoyer des données de télémétrie à Application Insights. Le SDK ne définit pas d’événements clients d’ordre général.

Cette pratique n'est pas quelque chose que nous prévoyons de tester ou de prendre en charge, bien que nos distributions vous permettent de exporter vers un point de terminaison OTLP parallèlement à Azure Monitor simultanément.

Nous ne le recommandons pas. Consultez Conditions d'utilisation supplémentaires pour les préversions de Microsoft Azure.

Certains clients utilisent le collecteur OpenTelemetry comme agent de substitution, même si Microsoft ne prend pas encore officiellement en charge une approche basée sur un agent pour la surveillance d’applications. En attendant, la communauté open source a contribué à un OpenTelemetry Collector Azure Monitor Exporter que certains clients utilisent pour envoyer des données à Azure Monitor Application Insights. Ce n’est pas pris en charge par Microsoft.

Vous essayez peut-être de visualiser des journaux en texte brut plutôt que des traces OpenTelemetry.

Dans Application Insights, la table « Traces » stocke les journaux en texte brut à des fins de diagnostic. Elle permet d’identifier et de mettre en corrélation les traces associées aux demandes utilisateur, à d’autres événements et aux rapports d’exceptions. Cependant, la table « Traces » ne contribue pas directement à la vue des transactions de bout en bout (graphique en cascade) dans des outils de visualisation comme Grafana.

Avec l’adoption croissante des pratiques natives cloud, la collecte et la terminologie des données de télémétrie évoluent. OpenTelemetry est désormais la norme en matière de collecte et d’instrumentation des données de télémétrie. Dans ce contexte, le terme « Traces » prend un nouveau sens. Au lieu de désigner des journaux bruts, « Traces » dans OpenTelemetry fait référence à une forme de télémétrie plus riche et structurée qui inclut des étendues représentant des unités de travail individuelles. Ces étendues sont essentielles pour construire des vues de transaction détaillées, améliorant ainsi le monitoring et les diagnostics des applications natives cloud.

Pour instrumenter une application Blazor, identifiez d’abord le modèle d’hébergement. Blazor Server prend en charge l’instrumentation complète basée sur OpenTelemetry. Blazor WebAssembly s’exécute dans le navigateur et prend en charge une instrumentation limitée via JavaScript.

Non, les données affichées dans un tableau de bord sont limitées à 30 jours.

Ce type d’erreur peut survenir si vous déplacez ou renommez votre instance Application Insights.

Pour contourner ce comportement, supprimez le tableau de bord par défaut et sélectionnez de nouveau Tableau de bord d’application pour en créer un nouveau.

Pour plus d’informations, consultez Tableau de bord Vue d’ensemble d’Application Insights.

Les exportateurs OpenTelemetry et les SDK utilisent généralement une méthode de livraison basée sur le meilleur effort. Les données de télémétrie peuvent toujours être perdues si une application se bloque, que le processus se termine avant l’exportation des données de télémétrie en attente, que le stockage n’est pas disponible ou que les pannes de réseau et de service ne dépassent pas les limites de nouvelle tentative. Pour connaître le comportement actuel d’OpenTelemetry, consultez stockage hors connexion et nouvelles tentatives automatiques.

Certains exportateurs et SDK actuels peuvent créer un stockage local temporaire en cas de problèmes de réseau ou de limitation. Le stockage temporaire local n’est pas chiffré par Application Insights. Par conséquent, sécurisez tout répertoire que vous configurez. Pour connaître le comportement actuel d’OpenTelemetry, consultez stockage hors connexion et nouvelles tentatives automatiques.

Pour connaître le comportement actuel des nouvelles tentatives et du stockage OpenTelemetry, consultez la configuration d’OpenTelemetry.

Consultez le résumé des limites.

Nous ne journalisons pas automatiquement les données POST. Utilisez soigneusement la journalisation des applications si vous devez capturer les détails du corps de la demande et éviter de collecter des données sensibles.

Azure Functions ne journalise pas les chaînes de requête d'URL.

Pour plus d’informations, consultez Recherche et diagnostics.

Raisons possibles :

• Les autres composants sont-ils instrumentés avec Application Insights ?
• Utilisent-ils le dernier Kit de développement logiciel (SDK) d’Application Insights stable ?
• Si ces composants sont des ressources Application Insights distinctes, vérifiez que vous avez access. Si vous avez accès et que les composants sont instrumentés avec les derniers SDK Application Insights, faites-le-nous savoir via le canal de commentaires dans le coin supérieur droit.

Actuellement, nous présentons l’appel de dépendance sortant séparément de la demande entrante. En règle générale, les deux appels semblent identiques, seule la valeur de durée est différente en raison de l’aller-retour réseau. L’icône de début et le style distinct des barres de durée permettent de les différencier. Cette présentation des données porte-t-elle à confusion ? Faites-nous part de vos commentaires !

Les chronologies sont ajustées pour les variations d’horloges dans le graphique de transaction. Vous pouvez voir les timestamps exacts dans le volet d’informations ou à l’aide de Log Analytics.

Ce comportement est voulu. Tous les éléments associés, sur tous les composants, sont déjà disponibles sur le côté gauche dans les sections supérieure et inférieure. La nouvelle expérience comporte deux éléments associés non couverts par le côté gauche : l’ensemble de la télémétrie cinq minutes avant et après cet événement et la chronologie utilisateur.

L’expérience de diagnostic des transactions affiche toutes les données de télémétrie dans une seule opération qui partage un ID d’opération. Par défaut, le SDK Application Insights pour JavaScript crée une opération pour chaque vue de page unique. Dans une application monopage (SPA), un seul événement de visualisation de page sera généré et un seul ID d’opération sera utilisé pour toute la télémétrie générée. Par conséquent, de nombreux événements peuvent être corrélés à la même opération.

Dans ces scénarios, vous pouvez utiliser le suivi automatique des itinéraires pour créer automatiquement de nouvelles opérations pour la navigation dans votre application monopage. Vous devez activerAutoRouteTracking pour qu’une vue de page soit générée chaque fois que l’itinéraire d’URL est mis à jour (affichage de page logique). Si vous voulez actualiser manuellement l’ID de l’opération, appelez appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Le déclenchement manuel d’un événement PageView réinitialise également l’ID d’opération.

Le temps non expliqué dans le diagramme de Gantt, est le temps qui n’est pas couvert par une dépendance suivie. Ce problème peut se produire car les appels externes n’ont pas été instrumentés, automatiquement ou manuellement. Cela peut également se produire parce que le traitement a pris du temps plutôt qu’en raison d’un appel externe.

Si tous les appels ont été instrumentés, dans le processus, il s’agit de la cause racine probable du temps passé. Un outil utile pour diagnostiquer le processus est le .NET Profiler.

Cette erreur indique que le navigateur n’a pas pu appeler une API requise ou que l’API a retourné une réponse d’échec. Pour résoudre les problèmes de comportement, ouvrez une fenêtre InPrivate du navigateur et désactivez les extensions de navigateur en cours d’exécution, puis identifiez si vous pouvez toujours reproduire le comportement du portail. Si l’erreur du portail se produit toujours, essayez de tester avec d’autres navigateurs ou d’autres ordinateurs, examinez le DNS ou les éventuels autres problèmes liés au réseau à partir de l’ordinateur client où les appels d’API échouent. Si l’erreur du portail se poursuit et a besoin d’un examen plus approfondi, collectez une trace réseau de navigateur lors de la reproduction du comportement inattendu du portail, puis ouvrez un cas de support à partir du Azure portal.

Pour plus d’informations, consultez Examiner les échecs, les performances et les transactions avec Application Insights.

L’événement initial sur la visualisation représente uniquement la première fois qu’un utilisateur a envoyé cette page consultée ou cet événement personnalisé au cours d’une session. Si les utilisateurs peuvent envoyer l’événement initial plusieurs fois pendant une session, la colonne Étape 1 affiche uniquement le comportement des utilisateurs après la première instance de l’événement initial, et non pas toutes les instances.

Utilisez les options Fractionner par dans le menu Modifier :

1. Sélectionnez l’événement que vous voulez décomposer dans le menu Événement.

2. Sélectionnez une dimension dans le menu Dimension . Par exemple, si vous disposez d’un événement appelé Bouton cliqué, essayez une propriété personnalisée appelée Nom du bouton.

Les cohortes et les filtres sont différents. Supposons que vous ayez une cohorte d’utilisateurs du Royaume-Uni (définie comme dans l’exemple précédent) et que vous compariez ses résultats à ceux obtenus avec le filtre Country or region = United Kingdom :

• La version cohorte affiche tous les événements des utilisateurs qui ont envoyé au moins un événement au Royaume-Uni pendant la période. Si vous fractionnez les données par pays ou région, vous verrez probablement de nombreux pays et régions.

• La version filtre n’affiche que les événements du Royaume-Uni. Si vous fractionnez les données par pays ou par région, vous ne voyez que celles du Royaume-Uni.

Vous pouvez sélectionner le filtre Fragment de date pour modifier le grain. Le filtre est disponible dans tous les onglets de dimension.

Vous pouvez examiner les données qui alimentent le classeur HEART si les visuels ne répondent pas à toutes vos questions. To do cette tâche, sous la section Monitoring dans Application Insights, sélectionnez Logs et interrogez la table customEvents. Certains attributs de Click Analytics sont contenus dans le champ customDimensions.

Voici un exemple de requête :

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Pour en savoir plus sur les journaux dans Azure Monitor, consultez Aperçu des journaux Azure Monitor.

Oui. Pour savoir comment modifier des modèles de classeur, consultez Azure modèles classeurs.

Pour plus d'informations, consultez la section Analyse de l'utilisation avec Application Insights.

Pour les applications de service worker actuelles, utilisez le Azure Monitor OpenTelemetry Exporter ou Distro. Consultez Activer OpenTelemetry avec Application Insights.

Pour l’instrumentation actuelle, utilisez les API OpenTelemetry et les API de journalisation ou de métriques spécifiques au langage. Pour obtenir des exemples, consultez Collecter des données de télémétrie personnalisées.

Pour les événements personnalisés du navigateur, utilisez le Kit de développement logiciel (SDK) JavaScript Application Insights ou Click Analytics. Pour les événements personnalisés côté serveur, utilisez des événements personnalisés OpenTelemetry.

Pour la surveillance des nouvelles applications, utilisez la distribution Azure Monitor OpenTelemetry ou les chemins d’auto-instrumentation actuels. Consultez Activer OpenTelemetry avec Application Insights et l’analyse des applications sans modification du code.

La prise en charge des fonctionnalités dépend du langage, de l’environnement d’hébergement et du chemin d’instrumentation. Pour obtenir la prise en charge actuelle, commencez par Activer OpenTelemetry avec Application Insights et l’article de configuration spécifique au langage approprié.

Pour l’instrumentation actuelle des services des travailleurs, voir Activer OpenTelemetry with Application Insights.