Améliorations des diagnostics dans .NET Core 3.0

Dans .NET Core 3.0, nous présentons un ensemble d'outils qui tirent parti des nouvelles fonctionnalités de l'environnement d'exécution .NET qui simplifient le diagnostic et la résolution des problèmes de performances.

Ces fonctionnalités vous aideront à répondre à certaines questions de diagnostic courantes que vous pourriez avoir:

1. Mon application est-elle opérationnelle?
2. Pourquoi mon application présente-t-elle un comportement anormal?
3. Pourquoi mon application plante-t-elle?

Mon application est-elle opérationnelle?

Au fil du temps, une fuite de mémoire peut se produire dans l'application, ce qui conduit finalement à une OutOfMemoryException. Dans d'autres cas, un code problématique peut entraîner une augmentation de la charge du processeur. Ce ne sont que quelques-uns des problèmes que vous pouvez identifier activement avec les mesures .

Mesures

Les métriques sont des données de mesure sur une période de temps. Ces mesures vous permettent de surveiller l'état de votre système à un niveau élevé. Contrairement à .NET Framework sous Windows, .NET Core ne génère pas de compteurs de performances. Au lieu de cela, nous avons introduit une nouvelle façon de générer des métriques dans .NET Core via l'API EventCounter .

EventCounters offre une amélioration par rapport aux compteurs de performances Windows, car ils sont désormais utilisés sur tous les systèmes d'exploitation qui prennent en charge .NET Core. De plus, contrairement aux compteurs de performances, ils peuvent également être utilisés dans des environnements à faibles privilèges (par exemple, lors du déploiement de xcopy). Malheureusement, l'absence d'un outil tel que l'Analyseur de performances (perfmon) rend difficile l'affichage de ces indicateurs en temps réel.

compteurs dotnet
Dans la version 3.0-preview5, nous présentons un nouvel outil en ligne de commande pour surveiller les métriques générées par les applications .NET Core en temps réel.

Vous pouvez installer cet outil en exécutant la commande suivante

dotnet tool install --global dotnet-counters --version 1.0.3-preview5.19251.2 

Dans l'exemple ci-dessous, nous voyons que la charge CPU et la mémoire de notre application augmentent lorsque nous commençons à charger sur notre application Web.



Pour des instructions détaillées sur l'utilisation de cet outil, consultez le fichier Lisezmoi du projet avec compteurs dotnet . Pour les limitations connues des compteurs dotnet, regardez les problèmes ouverts sur GitHub .

Pourquoi mon application présente-t-elle un comportement anormal?

Bien que les mesures aident à identifier la survenue d'un comportement anormal, elles offrent peu de compréhension de ce qui s'est mal passé. Pour répondre à la question de savoir pourquoi votre application présente un comportement anormal, vous devez collecter des informations supplémentaires via des traces. Par exemple, les profils d'UC collectés à l'aide de traces peuvent vous aider à déterminer le chemin d'accès rapide dans votre code.

Trace

Les traces sont des enregistrements d'événements discrets horodatés fixes. Les traces contiennent un contexte local qui vous permet de mieux déterminer le sort du système. Traditionnellement, le .NET Framework (et les frameworks tels que ASP.NET) ont généré des traces de diagnostic sur leurs composants internes à l'aide du suivi des événements pour Windows (ETW). Dans .NET Core, ces traces ont été enregistrées dans ETW pour Windows et LTTng pour Linux.

dotnet-trace

Dans la version 3.0-preview5, chaque application .NET Core ouvre un canal duplex nommé EventPipe (une socket de domaine Unix dans * nix ou un canal nommé dans Windows) à travers lequel elle peut envoyer des événements. Alors que nous travaillons toujours sur le protocole du contrôleur, dotnet-trace implémente une version préliminaire de ce protocole.

Vous pouvez installer cet outil en exécutant la commande suivante

 dotnet tool install --global dotnet-trace--version 1.0.3-preview5.19251.2 

Dans l'exemple ci-dessus, j'exécute une trace dotnet avec un profil par défaut qui inclut les événements du profileur de processeur et les événements .NET d'exécution.

En plus des événements par défaut, vous pouvez activer des fournisseurs supplémentaires en fonction de l'étude que vous essayez d'effectuer.

À la suite de l'exécution de la trace dotnet, vous obtenez un fichier .netperf. Ce fichier contient des événements d'extraction d'exécution et de pile CPU qui peuvent être visualisés dans perfview . La prochaine mise à jour de Visual Studio (16.1) ajoutera également la prise en charge de la visualisation de ces traces.



Si vous exécutez OS X ou Linux, vous pouvez convertir des fichiers .netperf en fichiers .speedscope.json qui peuvent être rendus à l'aide de Speedscope.app lors de l'enregistrement de traces .
Vous pouvez convertir une trace existante en exécutant la commande suivante:

 dotnet trace convert <input-netperf-file> 

L'image ci-dessous montre un diagramme qui visualise la trace que nous venons de recevoir.



Pour des instructions détaillées sur l'utilisation de cet outil, consultez le fichier Lisez - moi . Pour les limitations connues avec dotnet-trace, regardez les problèmes ouverts sur GitHub .

Pourquoi mon application plante-t-elle?

Dans certains cas, il n'est pas possible d'établir la cause du comportement anormal en surveillant simplement le processus. En cas de défaillance d'un processus ou de situations dans lesquelles nous pourrions avoir besoin d'informations supplémentaires, telles que l'accès à la totalité du segment de processus, un vidage de processus peut être plus adapté à l'analyse.

Analyse de vidage

Un vidage est un enregistrement de l'état de la mémoire virtuelle de travail d'un processus, généralement capturé lorsqu'il a été interrompu de manière inattendue. Les diagnostics de vidage du noyau sont couramment utilisés pour identifier les causes de plantages d'applications ou de comportements inattendus.

Traditionnellement, vous comptiez sur votre système d'exploitation pour recevoir un vidage lorsqu'une application se bloquait (par exemple, les rapports d'erreurs Windows) ou utilisiez un outil tel que procdump pour capturer un vidage lorsque certains critères de lancement étaient remplis.

Jusqu'à présent, le problème du vidage de vidage à l'aide de .NET sous Linux était que le vidage de vidage à l'aide de gcore ou du débogueur a conduit à de très gros vidages, car les outils existants ne savaient pas quelles pages de mémoire virtuelle couper dans le processus .NET Core.

De plus, il était difficile d'analyser ces vidages même après les avoir collectés, car vous deviez acheter un débogueur et le configurer pour charger sos, une extension de débogueur pour .NET.

dotnet-dump

Dans 3.0.0-preview5, nous présentons un nouvel outil qui vous permet de collecter et d'analyser les vidages de processus sous Windows et Linux.

dotnet-dump est toujours en cours de développement, et le tableau ci-dessous montre quelles fonctionnalités sont actuellement prises en charge sur quels systèmes d'exploitation.



Vous pouvez installer cet outil en exécutant la commande suivante

 dotnet tool install --global dotnet-dump --version 1.0.3-preview5.19251.2 

Après avoir installé dotnet-dump, vous pouvez capturer le vidage de processus en exécutant la commande suivante

 sudo $HOME/.dotnet/tools/dotnet-dump collect -p <pid> 

Sous Linux, le vidage résultant peut être analysé en chargeant le vidage résultant avec la commande suivante

 dotnet dump analyze <dump-name> 

Dans l'exemple suivant, j'essaie de définir un vidage de l'environnement d'hébergement ASP.NET Core



Pour des instructions détaillées sur l'utilisation de cet outil, consultez le fichier Lisez - moi. Pour les limitations connues avec dotnet-dump, regardez les problèmes ouverts sur GitHub .

Conclusion

Merci d'avoir testé les nouveaux outils de diagnostic dans .NET Core 3.0. Veuillez continuer à nous faire part de vos commentaires, soit dans les commentaires, soit sur GitHub . Nous écoutons attentivement et apporterons des modifications en fonction de vos commentaires.