Collecte, rétention et stockage des données dans Application Insights

Quand vous installez le Kit de développement logiciel (SDK) Application Insights dans votre application, il envoie des données de télémétrie sur votre application au cloud. En tant que développeur responsable, vous voulez savoir exactement quelles données sont envoyées, ce qu’elles deviennent et comment vous pouvez garder le contrôle. Ils souhaitent savoir, plus particulièrement, si les données sensibles peuvent être envoyées, où elles sont stockées et à quel point elles sont sécurisées ?

Tout d’abord, la réponse courte :

  • Les modules de télémétrie standard qui s’exécutent « dès le départ » sont peu susceptibles d’envoyer des données sensibles au service. La télémétrie s’attache aux métriques de charge, de performance et d’utilisation, aux rapports d’exception et autres données de diagnostic. Les principales données utilisateur visibles dans les rapports de diagnostic sont des URL. Mais votre application ne doit en aucun cas placer de données sensibles en texte brut dans une URL.
  • Vous pouvez écrire du code qui envoie davantage de données de télémétrie personnalisées, afin de vous aider avec les diagnostics et à surveiller l’utilisation. (Cette extensibilité est une fonctionnalité intéressante de Application Insights.) Il serait possible, par erreur, d’écrire ce code de manière à ce qu’il inclue les données personnelles et d’autres données sensibles. Si votre application fonctionne avec ces données, vous devez vérifier de manière approfondie l’ensemble du code que vous écrivez.
  • Pendant que vous développez et que vous testez votre application, il est facile d’examiner ce qui est envoyé par le Kit de développement logiciel (SDK). Les données apparaissent dans les fenêtres de sortie de débogage de l’IDE et du navigateur.
  • Vous pouvez sélectionner l’emplacement quand vous créez une ressource Application Insights. Pour plus d’informations sur la disponibilité d’Application Insights par région, consultez Produits disponibles par région.
  • Passez en revue les données collectées, car celles-ci peuvent inclure des données qui sont autorisées dans certains cas, mais pas dans d’autres. À cet égard, un nom d’appareil constitue un parfait exemple. Le nom de l’appareil d’un serveur n’affecte pas la confidentialité et est une information utile. Le nom de l’appareil d’un téléphone ou d’un ordinateur portable peut avoir des répercussions sur la confidentialité et être moins utile. Un SDK développé principalement pour les serveurs cibles collecte le nom de l’appareil par défaut. Cette fonctionnalité peut avoir besoin d’être remplacée dans les événements normaux et les exceptions.

Le reste de cet article traite plus en détail de ces points. Cet article est autonome. Vous pouvez donc le partager avec des collègues qui ne font pas partie de votre équipe.

Présentation d’Application Insights

Application Insights est un service de Microsoft qui vous aide à améliorer les performances et la convivialité de votre application dynamique. Il analyse votre application tout au long de son exécution, pendant les tests et une fois que vous avez l’avez publiée ou déployée. Application Insights crée des graphiques et des tableaux qui vous montrent des métriques informatives. Par exemple, vous pouvez voir les heures de la journée auxquelles vous avez le plus d’utilisateurs, la réactivité de l’application et comment elle est prise en charge par les services externes dont elle dépend. En cas d’incident ou de problèmes de performances, vous pouvez effectuer une recherche dans les données de télémétrie pour diagnostiquer la cause. Le service vous envoie des messages électroniques si des modifications sont apportées à la disponibilité et à la performance de votre application.

Pour obtenir cette fonctionnalité, vous devez installer un Kit SDK Application Insights dans votre application, il devient partie intégrante de son code. Lorsque votre application est en cours d’exécution, le Kit de développement logiciel (SDK) surveille son fonctionnement et envoie des données de télémétrie à Application Insights, qui est un service cloud hébergé par Microsoft Azure. Mais Application Insights fonctionne aussi pour toutes les applications, pas uniquement celles qui sont hébergées dans Azure.

Application Insights stocke et analyse les données de télémétrie. Pour afficher l’analyse ou effectuer une recherche dans la télémétrie stockée, connectez-vous à votre compte Azure et ouvrez la ressource Application Insights pour votre application. Vous pouvez également partager l’accès aux données avec d’autres membres de votre équipe, ou avec des abonnés Azure spécifiés.

Vous pouvez exporter des données à partir d’Application Insights vers une base de données ou des outils externes, par exemple. Vous devez attribuer une clé spéciale, que vous obtenez de la part du service, à chaque outil. La clé peut être révoquée si nécessaire.

Les kits SDK Application Insights sont disponibles pour toute une gamme d’applications :

  • Services web hébergés dans vos propres serveurs Java EE ou ASP.NET, ou dans Azure
  • Clients web, autrement dit, le code s’exécutant dans une page web
  • Applications et services de bureau
  • Applications d’appareils tels que Windows Phone, iOS et Android

Toutes envoient les données de télémétrie vers le même service.

Notes

Le support de l’ingestion de clé d’instrumentation prendra fin le 31 mars 2025. L’ingestion de clé d’instrumentation continuera de fonctionner, mais nous ne fournirons plus de mises à jour ni de support pour la fonctionnalité. Passez aux chaînes de connexion pour tirer parti des nouvelles fonctionnalités.

Quelles données collecte-t-il ?

Il existe trois sources de données :

  • Le SDK, que vous intégrez à votre application soit pendant le développement, soit au moment de l’exécution. Il existe différents Kits SDK pour différents types d’applications. Il existe également un Kit SDK pour les pages web, qui se charge dans le navigateur de l’utilisateur en même temps que la page.

    • Chaque Kit SDK comporte de nombreux modules, utilisant diverses techniques pour collecter différents types de données de télémétrie.
    • Si vous installez le Kit SDK pendant le développement, vous pouvez utiliser ses API pour envoyer votre propre télémétrie, ainsi que les modules standards. Ces données de télémétrie personnalisées peuvent inclure toutes les données que vous souhaitez envoyer.
  • Sur certains serveurs web, il existe également des agents qui s’exécutent en même temps que l’application et qui envoient des données de télémétrie concernant l’UC, la mémoire et l’occupation du réseau. Par exemple, les machines virtuelles Azure, les hôtes Docker et les serveurs d’applications Java peuvent disposer de ces agents.

  • Les tests de disponibilité sont des processus exécutés par Microsoft qui envoient des requêtes à votre application web à intervalles réguliers. Les résultats sont envoyés à Application Insights.

Quel est le type de données collecté ?

Les principales catégories sont :

  • La télémétrie du serveur web : requêtes HTTP. L’URI, le temps nécessaire pour traiter la demande, le code de réponse, l’adresse IP du client. Session id.
  • Les pages web : page, utilisateur et décomptes de sessions. Le temps de chargement de page. Les exceptions. Appels Ajax.
  • Les performances des compteurs : mémoire, UC, E/S et occupation du réseau.
  • Le contexte du client et du serveur : système d’exploitation, paramètres régionaux, type d’appareil, navigateur et résolution d’écran.
  • Les exceptions et les incidents : vidages de pile, build id et type d’UC.
  • Les dépendances : les appels aux services externes tels que REST, SQL et AJAX. L’URI ou la chaîne de connexion, la durée, la réussite et la commande.
  • Les tests de disponibilité : durée et étapes du test et réponses.
  • Les journaux d’activité de suivi et la télémétrie personnalisée : tout ce que vous codez dans vos journaux d’activité ou télémétrie.

Pour plus d’informations, consultez la section Données envoyées par Application Insights.

Comment puis-je vérifier ce qui a été collecté ?

Si vous développez une application à l’aide de Visual Studio, exécutez l’application en mode débogage (F5). Les données de télémétrie s’affichent dans la fenêtre Sortie. À partir de là, vous pouvez les copier et les mettre au format JSON pour une inspection facile.

Capture d’écran montrant l’exécution de l’application en mode débogage dans Visual Studio.

Il existe également une vue plus lisible dans la fenêtre Diagnostics.

Pour les pages web, ouvrez la fenêtre de débogage de votre navigateur. Appuyez sur F12 et ouvrez l’onglet Réseau.

Capture d’écran montrant l’onglet Réseau ouvert.

Puis-je écrire le code pour filtrer les données de télémétrie avant qu’elles soient envoyées ?

Vous devez écrire un plug-in de processeur de télémétrie.

Combien de temps sont conservées les données ?

Les points de données brutes (autrement dit, les éléments que vous pouvez interroger dans Analytics et inspecter dans Recherche) sont conservés pendant 730 jours maximum. Vous pouvez sélectionner une durée de rétention de 30, 60, 90, 120, 180, 270, 365, 550 ou 730 jours. Si vous voulez conserver les données plus longtemps, vous pouvez utiliser l’exportation continue pour les copier dans un compte de stockage durant l’ingestion des données.

Les données conservées plus de 90 jours entraînent des frais supplémentaires. Plus d’informations sur la tarification d’Application Insights, consultez la page de tarification Azure Monitor.

Les données agrégées (autrement dit, les nombres, moyennes et autres données statistiques que vous voyez dans Metrics Explorer) sont conservées avec une granularité de 1 minute pendant 90 jours.

Les captures instantanées de débogage sont stockées pendant 15 jours. Cette stratégie de rétention est définie application par application. Si vous devez augmenter cette valeur, faites-en la demande en ouvrant une demande de support dans le portail Azure.

Qui peut accéder aux données ?

Les données sont visibles par vous et, si vous disposez un compte d’organisation, par les membres de votre équipe.

Vous ou les membres de votre équipe pouvez les exporter et les copier à d’autres endroits, ou les transférer à d’autres personnes.

Que fait Microsoft des informations que mon application envoie à Application Insights ?

Microsoft n’utilise les données que pour vous fournir le service.

Où sont conservées les données ?

Vous pouvez sélectionner l’emplacement quand vous créez une ressource Application Insights. Pour plus d’informations sur la disponibilité d’Application Insights, consultez Produits disponibles par région.

Mes données sont-elles sécurisées ?

Application Insights est un service Azure. Les stratégies de sécurité sont décrites dans le livre blanc sur la sécurité, la confidentialité et la conformité Azure.

Les données sont stockées sur des serveurs Microsoft Azure. Pour les comptes du Portail Azure, les restrictions sont décrites dans le document relatif à la sécurité, la confidentialité et la conformité Azure.

L'accès à vos données par le personnel Microsoft est limité. Nous n’accédons à vos données qu’avec votre autorisation, et seulement pour vous aider à utiliser Application Insights.

Les données agrégées sur toutes les applications de nos clients, comme le débit des données et la taille moyenne des suivis, sont utilisées pour améliorer Application Insights.

Les données de télémétrie d’une autre personne peuvent-elles interférer avec mes données d’Application Insights ?

Une personne peut envoyer plus de données de télémétrie à votre compte à l’aide de la clé d’instrumentation. Cette clé se trouve dans le code de vos pages web. Avec suffisamment de données supplémentaires, vos mesures ne représentent pas correctement les performances et l’utilisation de votre application.

Si vous partagez le code avec d’autres projets, pensez à supprimer votre clé d’instrumentation.

Les données sont-elles chiffrées ?

Toutes les données sont chiffrées, aussi bien au repos que lors de leur déplacement entre les centres de données.

Les données sont-elles chiffrées lors de leur passage depuis mon application vers les serveurs Application Insights ?

Oui. Nous utilisons le protocole HTTPS pour envoyer les données au portail à partir de presque tous les Kits de développement logiciel (SDK), y compris les serveurs web, les appareils et les pages web HTTPS.

Le kit de développement logiciel (SDK) crée-t-il un stockage local temporaire ?

Oui. Certains canaux de télémétrie conservent les données localement si un point de terminaison est inaccessible. Les paragraphes suivants décrivent les infrastructures et les canaux de télémétrie affectés :

  • Les canaux de télémétrie qui utilisent le stockage local créent des fichiers temporaires dans les répertoires TEMP ou APPDATA, qui sont limités au compte exécutant votre application. Cette situation peut se produire lorsqu’un point de terminaison a été temporairement indisponible ou lorsque vous avez atteint la limite de bande passante. Une fois ce problème résolu, le canal de télémétrie reprend l’envoi de toutes les données nouvelles et conservées.
  • Ces données persistantes ne sont pas chiffrées en local. Si cela pose problème, passez en revue les données et limitez la collection de données privées. Pour plus d’informations, consultez Exporter et supprimer des données privées.
  • Si un client a besoin de configurer ce répertoire avec des exigences de sécurité spécifiques, il peut être configuré par infrastructure. Assurez-vous que le processus exécutant votre application dispose d’un accès en écriture à ce répertoire. Assurez-vous également que ce répertoire est protégé pour éviter que les données de télémétrie ne soient lues par des utilisateurs inattendus.

Java

Le dossier C:\Users\username\AppData\Local\Temp est utilisé pour les données persistantes. Cet emplacement n’est pas configurable à partir du répertoire de configuration et les autorisations pour accéder à ce dossier sont limitées à l’utilisateur qui possède les informations d’identification requises. Pour plus d’informations, consultez Implémentation.

.NET

Par défaut, ServerTelemetryChannel utilise le dossier de données d’application local %localAppData%\Microsoft\ApplicationInsights ou le dossier temp %TMP% de l’utilisateur actuel. Pour plus d’informations, consultez Implémentation.

Par le biais du fichier de configuration :

<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,   Microsoft.AI.ServerTelemetryChannel">
    <StorageFolder>D:\NewTestFolder</StorageFolder>
</TelemetryChannel>

Par le biais du code :

  • Supprimer ServerTelemetryChannel du fichier de configuration.

  • Ajoutez cet extrait de code à votre configuration :

    ServerTelemetryChannel channel = new ServerTelemetryChannel();
    channel.StorageFolder = @"D:\NewTestFolder";
    channel.Initialize(TelemetryConfiguration.Active);
    TelemetryConfiguration.Active.TelemetryChannel = channel;
    

NetCore

Par défaut, ServerTelemetryChannel utilise le dossier de données d’application local %localAppData%\Microsoft\ApplicationInsights ou le dossier temp %TMP% de l’utilisateur actuel. Pour plus d’informations, consultez Implémentation.

Dans un environnement Linux, le stockage local sera désactivé sauf si un dossier de stockage est spécifié.

Notes

Grâce à la version 2.15.0-beta3 et celles ultérieures, un stockage local est désormais automatiquement créé pour Linux, Mac et Windows. Pour les systèmes non Windows, le Kit de développement logiciel (SDK) crée automatiquement un dossier de stockage local selon la logique suivante :

  • ${TMPDIR} : Si la variable d’environnement ${TMPDIR} est définie, cet emplacement est utilisé.
  • /var/tmp : Si l’emplacement précédent n’existe pas, nous essayons /var/tmp.
  • /tmp : Si les deux emplacements précédents n’existent pas, nous essayons tmp.
  • Si aucun de ces emplacements n’existe, le stockage local n’est pas créé et la configuration manuelle est toujours requise.

Pour plus d’informations sur l’implémentation, consultez ServerTelemetryChannel stocke les données de télémétrie dans le dossier par défaut pendant les erreurs temporaires dans les environnements non Windows.

L’extrait de code suivant montre comment définir ServerTelemetryChannel.StorageFolder dans la méthode ConfigureServices() de votre classe Startup.cs :

services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});

Pour plus d’informations, consultez Configuration personnalisée d’AspNetCore.

Node.js

Par défaut, %TEMP%/appInsights-node{INSTRUMENTATION KEY} est utilisé pour les données persistantes. Les autorisations d’accès à ce dossier sont limitées à l’utilisateur actuel et aux administrateurs. Pour plus d’informations, consultez Implémentation.

Le préfixe du dossier appInsights-node peut être substitué en modifiant la valeur d’exécution de la variable statique Sender.TEMPDIR_PREFIX trouvée dans Sender.ts.

Javascript (navigateur)

Le stockage de session HTML5 est utilisé pour faire persister les données. Deux mémoires tampons distinctes sont utilisées : AI_buffer et AI_sent_buffer. Les données de télémétrie traitées par lots et en attente d’envoi sont stockées dans AI_buffer. Les données de télémétrie qui viennent d’être envoyées sont placées dans AI_sent_buffer jusqu’à ce que le serveur d’ingestion réponde qu’elles ont bien été reçues.

Une fois que les données de télémétrie ont bien été reçues, elles sont supprimées de toutes les mémoires tampons. En cas de défaillances temporaires (par exemple, perte de connectivité pour un utilisateur), les données de télémétrie restent dans AI_buffer jusqu’à ce qu’elles soient bien reçues ou que le serveur d’ingestion réponde que les données de télémétrie ne sont pas valides (schéma incorrect ou trop ancien, par exemple).

Les mémoires tampons de télémétrie peuvent être désactivées en définissant enableSessionStorageBuffer sur false. Quand le stockage de session est désactivé, une baie locale est utilisée comme stockage persistant. Comme le kit SDK JavaScript s’exécute sur un appareil client, l’utilisateur a accès à cet emplacement de stockage via les outils de développement de son navigateur.

OpenCensus Python

Par défaut, le SDK OpenCensus Python utilise le dossier de l’utilisateur actuel %username%/.opencensus/.azure/. Les autorisations d’accès à ce dossier sont limitées à l’utilisateur actuel et aux administrateurs. Pour plus d’informations, consultez Implémentation. Le dossier contenant vos données persistantes va porter le nom du fichier Python qui a généré les données de télémétrie.

Vous pouvez changer l’emplacement de votre fichier de stockage en passant le paramètre storage_path dans le constructeur de l’exportateur que vous utilisez.

AzureLogHandler(
  connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000',
  storage_path='<your-path-here>',
)

Comment envoyer des données à Application Insights à l’aide de TLS 1.2 ?

Pour garantir la sécurité des données en transit vers les points de terminaison Application Insights, nous encourageons vivement les clients à configurer leur application de façon à utiliser TLS version 1.2 minimum. Les versions antérieures de TLS/SSL (Secure Sockets Layer) se sont avérées vulnérables. Bien qu’elles fonctionnent toujours pour permettre la compatibilité descendante, elles ne sont pas recommandées. L’industrie évolue et abandonne rapidement la prise en charge de ces protocoles plus anciens.

Le PCI Security Standards Council a défini une échéance au 30 juin 30, 2018 pour désactiver les versions antérieures de TLS/SSL et effectuer une mise à niveau vers des protocoles plus sécurisés. Une fois qu’Azure arrêtera la prise en charge des versions héritées, si votre application ou vos clients ne peuvent pas communiquer via le protocole TLS version 1.2 minimum, vous ne serez plus en mesure d’envoyer des données à Application Insights. L’approche que vous adoptez pour tester et valider la prise en charge TLS de votre application varie selon le système d’exploitation ou la plateforme, ainsi que le langage ou l’infrastructure que votre application utilise.

Nous vous déconseillons de définir explicitement votre application pour qu’elle utilise uniquement TLS 1.2, sauf si nécessaire. Ce paramètre peut annuler les fonctionnalités de sécurité au niveau de la plateforme qui vous permettent de détecter automatiquement et de tirer parti des protocoles plus sécurisés et plus récents dès qu’ils sont disponibles, tels que TLS 1.3. Nous vous recommandons d’effectuer un audit complet du code de votre application pour vérifier le codage en dur des versions spécifiques de TLS/SSL.

Conseils spécifiques à la plateforme/au langage

Plateforme/Langage Support Informations complémentaires
Azure App Services Pris en charge, la configuration peut être nécessaire. La prise en charge a été annoncée en avril 2018. Lisez l’annonce pour connaître les détails de configuration.
Applications de fonction Azure Pris en charge, la configuration peut être nécessaire. La prise en charge a été annoncée en avril 2018. Lisez l’annonce pour connaître les détails de configuration.
.NET Pris en charge, support à long terme (LTS). Pour obtenir des informations de configuration détaillées, reportez-vous à ces instructions.
Status Monitor Pris en charge, configuration requise. Status Monitor s’appuie sur la configuration du système d’exploitation + la configuration .NET pour prendre en charge TLS 1.2.
Node.js Pris en charge, dans v10.5.0, la configuration peut être nécessaire. Utilisez la documentation officielle de Node.js TLS/SSL pour toute configuration spécifique à une application.
Java Pris en charge, prise en charge JDK pour TLS 1.2 ajoutée dans JDK 6 mise à jour 121 et JDK 7. JDK 8 utilise TLS 1.2 par défaut.
Linux Les distributions de Linux s’appuient généralement sur OpenSSL pour la prise en charge de TLS 1.2. Vérifiez OpenSSL Changelog pour vous assurer que votre version d’OpenSSL est prise en charge.
Windows 8.0 - 10 Pris en charge, activé par défaut. Pour confirmer que vous utilisez toujours les paramètres par défaut.
Windows Server 2012 - 2016 Pris en charge, activé par défaut. Pour confirmer que vous utilisez toujours les paramètres par défaut.
Windows 7 SP1 et Windows Server 2008 R2 SP1 Pris en charge, mais non activé par défaut. Consultez la page Paramètres de Registre de TLS pour plus d’informations sur l’activation.
Windows Server 2008 SP2 La prise en charge de TLS 1.2 nécessite une mise à jour. Consultez Mise à jour pour ajouter la prise en charge de TLS 1.2 dans Windows Server 2008 SP2.
Windows Vista Non pris en charge. N/A

Vérifier la version d’OpenSSL que votre distribution Linux exécute

Pour vérifier la version d’OpenSSL installée, ouvrez le terminal et exécutez :

openssl version -a

Exécuter un test de transaction de TLS 1.2 sur Linux

Pour exécuter un test préliminaire pour voir si votre système Linux peut communiquer via TLS 1.2, ouvrez le terminal et exécutez :

openssl s_client -connect bing.com:443 -tls1_2

Données personnelles stockées dans Application Insights

Pour une discussion approfondie sur ce problème, consultez Gestion des données personnelles dans Log Analytics et Application Insights.

Mes utilisateurs peuvent-ils désactiver Application Insights ?

Pas directement. Il n’existe pas de commutateur que vos utilisateurs peuvent utiliser pour désactiver Application Insights.

Vous pouvez implémenter cette fonctionnalité dans votre application. Tous les Kits de développement logiciel (SDK) comprennent un paramètre API qui désactive la collecte de télémétrie.

Données envoyées par Application Insights

Les kits de développement logiciel (SDK) varient en fonction des plateformes et vous pouvez installer plusieurs composants. Pour plus d’informations, consultez Vue d'ensemble d’Application Insights. Chaque composant envoie des données différentes.

Classes de données envoyées dans différents scénarios

Votre action Classes de données collectées (voir tableau suivant)
Ajouter le kit de développement logiciel (SDK) Application Insights à un projet web .NET ServerContext
Inferred
Perf counters
Demandes
Exceptions
session
users
Installer Status Monitor sur IIS Les dépendances
ServerContext
Inferred
Perf counters
Ajouter le kit de développement logiciel (SDK) Application Insights à une application web Java ServerContext
Inferred
Requête
session
users
Ajouter le kit de développement logiciel (SDK) JavaScript à une page web ClientContext
Inferred
Page
ClientPerf
Ajax
Définir les propriétés par défaut Propriétés sur tous les événements standard et personnalisés
Appeler TrackMetric Valeurs numériques
Propriétés
Appeler Track* Nom d'événement
Propriétés
Appeler TrackException Exceptions
Vidage de pile
Propriétés
Le Kit SDK ne peut pas collecter les données. Par exemple :
- Impossible d’accéder aux compteurs de performances
- Exception dans l’initialiseur de télémétrie
SDK diagnostics

Pour les Kits de développement logiciel (SDK) des autres plateformes, consultez les documents correspondants.

Les classes de données collectées

Classe des données collectées Comprend (liste non exhaustive)
Propriétés Toutes les données - en fonction de votre code
DeviceContext Id adresse IP, paramètres régionaux, modèle d’appareil, réseau, type de réseau, nom OEM, résolution d’écran, instance de rôle, nom du rôle, type d’appareil
ClientContext Système d’exploitation, paramètres régionaux, langue, réseau, résolution de la fenêtre
session session id
ServerContext Nom de l’ordinateur, paramètres régionaux, système d’exploitation, appareil, session utilisateur, contexte utilisateur, opération
Inferred Emplacement géographique à partir de l’adresse IP, horodatage, système d’exploitation, navigateur
Mesures Valeur et nom de la mesure
Événements Valeur et nom de l’événement
PageViews URL et nom de la page ou de l’écran
Client perf URL/nom de la page, temps de chargement du navigateur
Ajax Appels HTTP de la page web au serveur
Demandes URL, durée, code de réponse
Les dépendances Type (SQL, HTTP, ...), chaîne de connexion ou URI, synchronisation/désynchronisation, durée, réussite, instruction SQL (avec Status Monitor)
Exceptions Type, message, piles d’appels, fichier source, numéro ligne, thread id
Crashes Process id, parent process id, crash thread id ; correctif de l’application, id, version ; type d’exception, adresse, motif ; symboles et enregistrements obfusqués, adresses binaires de début et de fin, nom et chemin du fichier binaire, type de processeur
Trace Message et niveau de gravité
Perf counters Temps processeur, mémoire disponible, taux de demande, taux d’exception, octets privés du processus, taux d’E/S, durée de la demande, longueur de file d’attente de la demande
Disponibilité Code de réponse de test web, durée de chaque étape de test, nom de test, horodatage, réussite, temps de réponse, emplacement de test
SDK diagnostics Message de suivi ou exception

Vous pouvez désactiver certaines données en modifiant ApplicationInsights.config.

Notes

L’IP du client est utilisée pour déduire son emplacement géographique, mais par défaut, les données d’IP ne sont plus stockées et tous les zéros sont écrits dans le champ associé. Pour en savoir plus sur la gestion des données personnelles, consultez Gestion des données personnelles dans Log Analytics et Application Insights. Si vous avez besoin de stocker des données d’adresse IP, la gestion de la géolocalisation et des adresses IP vous présentera vos options.

Puis-je modifier ou mettre à jour les données une fois qu’elles ont été collectées ?

Non. Les données sont en lecture seule et ne peuvent être supprimées qu’à l’aide de la fonctionnalité de vidage. Pour en savoir plus, consultez Aide pour les données personnelles stockées dans Log Analytics et Application Insights.

Crédits

Ce produit contient des données GeoLite2 créées par MaxMind.